Générer cryptographic nonces correctly
Un nonce (nombre utilisé une fois) doit être unique per chiffrement sous le même clé. Apprendre quand en utiliser random vs counter nonces et le consequences de reuse.
- 1
A nonce must never repeat under the same key. Two approaches: (1) random nonce — generate 96 bits from a CSPRNG, collision probability is negligible with a 96-bit space; (2) counter nonce — maintain a monotonic counter, guaranteed unique but requires persistent state. Random is simpler; counter is deterministic.
- 2 Générateur d'octets aléatoires →
Générer a 96-bit (12-byte) random nonce. This is the standard size for AES-GCM. With 96 bits, the probability of collision after 2^32 encryptions is less than 2^-32 (birthday bound) — safe for most applications.
- 3 Calculatrice de hash →
If you need a deterministic nonce from a message identifier, use a hash: nonce = H(message_id). This is useful when the same message must produce the same ciphertext (deterministic encryption), but be careful — it reveals if two messages are identical.
- 4
Never use: timestamps (can repeat on fast machines), Math.random() (not cryptographic), a hardcoded constant, or a counter that wraps around. For AES-GCM specifically, 96-bit nonces are optimal — other sizes require additional processing and may weaken security.
Questions fréquentes
- Random or counter nonce?
- Random is simpler and stateless — use it for most applications. Counter is deterministic and avoids birthday-bound concerns, but requires persistent state and fails if the counter resets (e.g., server restart). For AES-GCM, NIST recommends 96-bit random nonces.
- What if I accidentally reuse a nonce?
- For GCM, nonce reuse is catastrophic — it leaks the authentication key and allows forgery. For CTR, it leaks the XOR of two plaintexts. If you suspect reuse, immediately rotate the encryption key and re-encrypt all data with new nonces.