Generación segura de claves, nonces e IV

Hay tres valores criptográficos distintos que requieren una generación segura: (1) Claves: tienen una larga duración y deben ser impredecibles y secretas. (2) IV: son por mensaje, pueden ser públicos, pero deben ser impredecibles (CBC) o únicos (GCM). (3) Nonces: deben ser únicos en cada uso, aunque pueden ser aleatorios o no.

AES-128: secrets.token_bytes(16). AES-256: secrets.token_bytes(32). ChaCha20: secrets.token_bytes(32). Never derive keys from passwords without KDF (PBKDF2/Argon2). Never reuse keys across different algorithms or purposes.

from cryptography.hazmat.primitives.asymmetric import ec, rsa rsa_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) ec_key = ec.generate_private_key(ec.SECP256R1()) # The library handles entropy sourcing internally

AES-CBC requiere un IV de 16 bytes uniformemente aleatorio para cada mensaje. No reutilice nunca un IV con la misma clave. No utilice nunca un contador como IV en modo CBC. Genere: iv = os.urandom(16). Anteonga el IV al texto cifrado: no tiene que ser secreto, solo impredecible.

AES-GCM requiere un nonce único de 96 bits para cada par (clave, mensaje). La reutilización de un nonce rompe catastróficamente GCM: el atacante recupera la clave de autenticación y puede falsificar mensajes. Utilice un nonce aleatorio de 12 bytes (límite del cumpleaños en 2^32 mensajes) o un contador.

Para cifrado de gran volumen con una sola clave: mantenga un contador persistente por clave. nonce = counter.to_bytes(12, "big"). Incremente el contador después de cada cifrado. Guarde el contador en un almacenamiento persistente: un reinicio provoca su reutilización.

AES-GCM-SIV y Deoxys-II son resistentes al uso indebido de nonces: la reutilización de un nonce degrada la seguridad hasta la de un cifrado determinista (sin filtrar la clave de autenticación). Se recomiendan cuando resulta difícil garantizar la unicidad de los nonces (sistemas distribuidos y situaciones de recuperación tras un fallo y reinicio).

No utilice directamente material de clave sin procesar para varios fines. Derive claves específicas para cada propósito: from cryptography.hazmat.primitives.kdf.hkdf import HKDF. hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key"). key = hkdf.derive(master_key). Utilice un valor de info diferente para cada propósito.

Derive claves específicas de la sesión a partir de un secreto compartido (por ejemplo, la salida de ECDH) mediante HKDF. TLS 1.3 deriva claves separadas de cliente y servidor para el handshake y los datos de aplicación. Las claves de sesión aíslan los compromisos: conocer una clave de sesión no revela nada sobre las demás.

Para almacenar una clave de forma segura, envuélvala con una clave de cifrado de claves (KEK) mediante AES-KW (RFC 3394) o AES-GCM. La clave envuelta puede almacenarse en una base de datos o transmitirse. La KEK se almacena en un HSM o en un almacén de claves respaldado por hardware (Android Keystore, Apple Secure Enclave).

Antes de la implementación, compruebe: (1) que todas las claves procedan de os.urandom/secrets; (2) que no haya claves ni IV codificados directamente; (3) que los IV nunca se reutilicen con la misma clave; (4) que los nonces de GCM sean únicos para cada mensaje; (5) que se haya definido un calendario de rotación de claves; (6) que la derivación de claves utilice HKDF con cadenas de info distintas.

¿Cuál es la consecuencia de reutilizar un nonce en AES-GCM?

Las claves necesitan una generación verdaderamente aleatoria; los IV de CBC necesitan aleatoriedad; los nonces de GCM necesitan unicidad. Utilice os.urandom/secrets, derive claves con HKDF y envuélvalas con KEK. Las AEAD resistentes al uso indebido de nonces protegen frente a la reutilización accidental. Siguiente: pruebas de conocimiento cero.