PRNG criptográficamente seguros

Un CSPRNG debe cumplir: (1) impredecibilidad del siguiente bit: aunque se conozcan todos los bits anteriores, el siguiente no se puede predecir con una probabilidad superior a 1/2 + una cantidad despreciable. (2) resistencia a la extensión tras el compromiso del estado: conocer el estado actual no revela nada sobre la salida pasada.

Linux /dev/urandom utiliza un CSPRNG sembrado a partir del pool de entropía. Tras la siembra inicial (128 bits de entropía), es seguro utilizarlo incluso cuando el pool está "vacío": el CSPRNG mantiene su propio estado interno. getrandom() es el equivalente moderno mediante una llamada al sistema.

El kernel de Linux 5.17+ sustituyó su CSPRNG por un diseño basado en ChaCha20. ChaCha20 es rápido (no necesita aceleración por hardware), proporciona una seguridad de 256 bits y cuenta con una demostración de seguridad bien estudiada. El nonce es el contador; la clave procede del pool de entropía.

Fortuna (Ferguson & Schneier, 2003) es un diseño de CSPRNG que mantiene 32 pools de entropía y acumula entropía continuamente. El generador se vuelve a sembrar a partir de los pools a medida que se llenan. Es resistente a los ataques de reinicio del RNG y de compromiso parcial del estado.

NIST SP 800-90A incluía originalmente DUAL_EC_DRBG, basado en curvas elípticas. Los documentos de Snowden revelaron que la NSA insertó una puerta trasera: los puntos de la curva elíptica se eligieron de modo que la NSA pudiera predecir la salida a partir de cualquier semilla. No utilice nunca DUAL_EC_DRBG. NIST lo retiró en 2014.

CTR_DRBG (NIST SP 800-90A) utiliza AES en modo contador como CSPRNG. La semilla = clave de 256 bits + nonce de 128 bits. Cada llamada avanza el contador. Está ampliamente implementado en OpenSSL, BoringSSL y Windows BCrypt. Cuenta con aceleración por hardware en CPU con AES-NI.

HASH_DRBG utiliza una función hash (SHA-256) de forma iterativa con un valor de semilla. HMAC_DRBG utiliza HMAC para realizar la mezcla. HMAC_DRBG es más sencillo de implementar correctamente y se utiliza en muchos sistemas embebidos (mbedTLS, WolfSSL).

Incluso los CSPRNG deben resembrarse periódicamente. CTR_DRBG tiene un intervalo de resiembra de 2^48 solicitudes. Fortuna se vuelve a sembrar a partir de sus pools de entropía. Resiembra manual: añada entropía nueva (bytes de getrandom) al estado del CSPRNG durante el arranque y después de fork().

Cuando un proceso ejecuta fork, tanto el proceso padre como el hijo heredan el mismo estado del CSPRNG, por lo que producirán una salida idéntica. Solución: llame a getrandom() para volver a sembrar inmediatamente después de fork(). OpenSSL lo gestiona automáticamente mediante pthread_atfork() en versiones recientes.

import secrets key = secrets.token_bytes(32) # 256-bit key nonce = secrets.token_bytes(12) # 96-bit nonce for AES-GCM pin = secrets.randbelow(10**6) # 6-digit PIN # Never use random module for cryptography

window.crypto.getRandomValues(typedArray) es el CSPRNG del navegador. Utiliza la fuente de entropía del sistema operativo. La API WebCrypto lo utiliza para generar claves. No utilice nunca Math.random() con fines de seguridad: es un PRNG no criptográfico sembrado a partir de la hora del sistema.

¿Qué módulo de Python debe utilizar para generar bytes aleatorios criptográficos?

Los CSPRNG como ChaCha20, CTR_DRBG y Fortuna generan salidas impredecibles a partir de semillas de entropía. Evite DUAL_EC_DRBG, random.random() y Math.random(). Utilice secrets (Python) o window.crypto (navegador). Siguiente: fallos de entropía en el mundo real.