PRNGs criptograficamente seguros

Um CSPRNG deve satisfazer: (1) imprevisibilidade do próximo bit — mesmo conhecendo todos os bits anteriores, o próximo bit não pode ser previsto com probabilidade > 1/2 + desprezível; (2) resistência à extensão após comprometimento do estado — conhecer o estado atual não revela nada sobre a saída passada.

O Linux /dev/urandom usa um CSPRNG inicializado a partir do reservatório de entropia. Após a inicialização inicial (128 bits de entropia), é seguro usá-lo mesmo quando o reservatório está "vazio" — o CSPRNG mantém seu próprio estado interno. getrandom() é o equivalente moderno à chamada de sistema.

O kernel do Linux 5.17+ substituiu seu CSPRNG por um projeto baseado em ChaCha20. ChaCha20 é rápido (não requer aceleração de hardware), oferece segurança de 256 bits e tem uma prova de segurança bem estabelecida. O nonce é o contador; a chave vem do reservatório de entropia.

Fortuna (Ferguson e Schneier, 2003) é um projeto de CSPRNG que mantém 32 reservatórios de entropia e acumula entropia continuamente. O gerador recebe uma nova semente dos reservatórios à medida que eles se enchem. É resistente a ataques de redefinição do RNG e de comprometimento parcial do estado.

O NIST SP 800-90A originalmente incluía o DUAL_EC_DRBG, baseado em curvas elípticas. Documentos de Snowden revelaram que a NSA inseriu uma porta dos fundos: os pontos EC foram escolhidos de modo que a NSA pudesse prever a saída a partir de qualquer semente. Nunca use DUAL_EC_DRBG. O NIST o removeu em 2014.

O CTR_DRBG (NIST SP 800-90A) usa AES no modo contador como CSPRNG. Semente = chave de 256 bits + nonce de 128 bits. Cada chamada avança o contador. É amplamente implementado no OpenSSL, no BoringSSL e no BCrypt do Windows. Há aceleração de hardware em CPUs com AES-NI.

O HASH_DRBG usa uma função de hash (SHA-256) iterativamente com um valor de semente. O HMAC_DRBG usa HMAC para realizar a mistura. O HMAC_DRBG é mais simples de implementar corretamente e é usado em muitos sistemas embarcados (mbedTLS, WolfSSL).

Até mesmo os CSPRNGs precisam ser re-semeados periodicamente. O CTR_DRBG tem um intervalo de re-semeadura de 2^48 solicitações. O Fortuna recebe novas sementes de seus reservatórios de entropia. Re-semeadura manual: adicione entropia nova (bytes obtidos com getrandom) ao estado do CSPRNG na inicialização e após fork().

Quando um processo executa um fork, o processo pai e o processo filho herdam o mesmo estado do CSPRNG — eles produzirão uma saída idêntica. Correção: chame getrandom() para re-semear imediatamente após fork(). O OpenSSL faz isso automaticamente por meio de pthread_atfork() nas versões recentes.

import secrets key = secrets.token_bytes(32) # chave de 256 bits nonce = secrets.token_bytes(12) # nonce de 96 bits para AES-GCM pin = secrets.randbelow(10**6) # PIN de 6 dígitos # Nunca use o módulo random para criptografia

window.crypto.getRandomValues(typedArray) é o CSPRNG do navegador. Ele chama a fonte de entropia do OS. É usado pela API WebCrypto para a geração de chaves. Nunca use Math.random() para segurança — ele é um PRNG não criptográfico inicializado a partir do horário do sistema.

Qual módulo do Python você deve usar para gerar bytes aleatórios criptográficos?

CSPRNGs como ChaCha20, CTR_DRBG e Fortuna geram saídas imprevisíveis a partir de sementes de entropia. Evite DUAL_EC_DRBG, random.random() e Math.random(). Use secrets (Python) ou window.crypto (navegador). A seguir: falhas de entropia no mundo real.