Erzeugen cryptographic nonces correctly
Ein nonce (Zahl verwendet einmal) muss sein eindeutig per Verschlüsselung unter der gleich Schlüssel. Lernen wenn in verwenden random vs counter nonces und der consequences von 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 Zufallsbytes-Generator →
Erzeugen 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 Hash-Rechner →
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.
Häufige Fragen
- 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.