Generating Keys, Nonces & IVs Safely

Three distinct cryptographic values need secure generation: (1) Keys — long-lived, must be unpredictable and secret. (2) IVs — per-message, may be public but must be unpredictable (CBC) or unique (GCM). (3) Nonces — must be unique per use, may or may not be random.

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 requires a uniformly random 16-byte IV per message. Never reuse an IV with the same key. Never use a counter as an IV in CBC mode. Generate: iv = os.urandom(16). Prepend the IV to the ciphertext — it need not be secret, only unpredictable.

AES-GCM requires a unique 96-bit nonce per (key, message) pair. Nonce reuse catastrophically breaks GCM: attacker recovers the authentication key and can forge messages. Use either a random 12-byte nonce (birthday bound at 2^32 messages) or a counter.

For high-volume encryption with a single key: maintain a persistent counter per key. nonce = counter.to_bytes(12, "big"). Increment counter after each encryption. Store counter to persistent storage — reset on restart causes reuse.

AES-GCM-SIV and Deoxys-II are nonce misuse-resistant: nonce reuse degrades security to that of deterministic encryption (no authentication key leak). Recommended when nonce uniqueness is difficult to guarantee (distributed systems, crash-restart scenarios).

Do not use raw key material directly for multiple purposes. Derive purpose-specific keys: from cryptography.hazmat.primitives.kdf.hkdf import HKDF. hkdf = HKDF(SHA256(), 32, salt, info=b"enc_key"). key = hkdf.derive(master_key). Use different info for each purpose.

Derive session-specific keys from a shared secret (e.g., ECDH output) using HKDF. TLS 1.3 derives separate client/server keys for handshake and application data. Session keys isolate compromise: learning one session key reveals nothing about others.

To store a key securely, wrap it with a Key Encryption Key (KEK) using AES-KW (RFC 3394) or AES-GCM. The wrapped key can be stored in a database or transmitted. The KEK is stored in an HSM or hardware-backed keystore (Android Keystore, Apple Secure Enclave).

Before deployment check: (1) all keys from os.urandom/secrets. (2) No hardcoded keys/IVs. (3) IVs never reused with same key. (4) GCM nonces unique per message. (5) Key rotation schedule defined. (6) Key derivation uses HKDF with distinct info strings.

What is the consequence of reusing a nonce in AES-GCM?

Keys need true random generation; CBC IVs need randomness; GCM nonces need uniqueness. Use os.urandom/secrets, derive with HKDF, and wrap with KEKs. Nonce misuse-resistant AEADs protect against accidental reuse. Next: Zero-Knowledge Proofs.