What Is a Cryptographic Nonce? (And Why Reusing One Breaks Everything)

Sony reused a random number in their PS3 code signing. Hackers extracted the master private key. The entire PS3 security model collapsed because one number was used twice.

A nonce is a number used once. That is the entire definition. The word is literally "number used once." When you reuse it in a cryptographic operation, the security proof falls apart. In AES-GCM, nonce reuse leaks plaintext. In ECDSA, nonce reuse leaks the private key. In both cases, the damage is permanent and irrecoverable.

The block cipher tool lets you experiment with AES in GCM mode, where nonce handling is the difference between secure encryption and a catastrophic break.

A nonce is a value that must be unique for each invocation of a cryptographic operation under a given key. It does not need to be secret. It does not need to be random. It needs to be unique.

The word "nonce" comes from "number used once." Some protocols use the term "IV" (initialization vector) for a similar concept, but there is a distinction. An IV in CBC mode must be unpredictable to an attacker before the plaintext is known. A nonce in CTR or GCM mode only needs to be unique, not unpredictable. If you use a simple counter as a nonce in AES-GCM, that is fine, as long as the counter never repeats under the same key.

NIST SP 800-38D, which defines GCM, requires that the nonce (called an "IV" in the standard) be unique for each invocation. The standard allows three approaches: a deterministic counter, a randomly generated value (with a collision probability calculation), or the combination of a fixed field and an invocation field. The NIST SP 800-38D specification covers the requirements in detail.

A salt is different from a nonce. A salt is used in password hashing to prevent rainbow table attacks. It does not need to be unique per invocation under the same key, it needs to be unique per password. Salts can be stored alongside the hash and are not secret.

AES-GCM nonce reuse: GCM generates a keystream by encrypting a counter with AES. The counter starts at the nonce value. If two messages are encrypted with the same nonce, they share the same keystream. XORing the two ciphertexts cancels the keystream and produces the XOR of the two plaintexts. This is the same two-time pad attack that breaks any stream cipher with key reuse.

But GCM is worse. The authentication tag in GCM is computed using a polynomial evaluated over the ciphertext blocks, with a key derived from AES(0, nonce). If the nonce repeats, the authentication key is the same, and an attacker can recover it by solving a system of polynomial equations. Once the authentication key is known, the attacker can forge valid tags for arbitrary messages. This means nonce reuse in GCM breaks both confidentiality and integrity, permanently, for that key.

ECDSA nonce reuse: ECDSA signatures use a random nonce k in each signature. The signature is (r, s) where r is derived from k and s is computed using k, the private key, and the message hash. If the same k is used for two different messages, you can set up two equations with two unknowns (k and the private key) and solve for the private key algebraically. No brute force needed. The math is simple:

`` s1 = k^(-1) (h1 + r d) mod n s2 = k^(-1) (h2 + r d) mod n s1 - s2 = k^(-1) * (h1 - h2) mod n k = (h1 - h2) / (s1 - s2) mod n d = (s1 * k - h1) / r mod n ``

Where d is the private key, h1 and h2 are the message hashes, and n is the curve order. Two signatures with the same nonce reveal the private key completely.

Sony PS3 (2010): Sony used ECDSA to sign PS3 firmware. Their implementation used a static nonce, the same value for every signature. The hacker group fail0verflow noticed that the signatures had identical r values, which means identical k values. They solved the equations and extracted Sony's master private key. Anyone could then sign firmware that the PS3 would accept as legitimate. Sony could not revoke the key without replacing hardware. The fail0verflow presentation at 27C3 (Chaos Communication Congress) demonstrated the break live.

Bitcoin Android wallet (2013): A bug in the Java SecureRandom implementation on Android produced predictable ECDSA nonces for Bitcoin wallet transactions. Attackers observed transactions with repeated or predictable nonces and extracted private keys, stealing bitcoins worth several thousand dollars. The fix was to switch to deterministic nonces (RFC 6979), which derive k from the private key and message hash, eliminating the need for a random number generator.

PuTTY CVE-2024-31497: In April 2024, researchers at Ruhr-Universitat Bochum disclosed that PuTTY versions 0.68 through 0.80 generated biased ECDSA nonces for NIST P-521 keys. The first 9 bits of each nonce were always zero. This bias allowed full private key recovery from approximately 60 signatures. Since SSH client signatures are transmitted within the encrypted channel, a malicious server could harvest signatures by prompting authentication attempts. All NIST P-521 keys used with affected PuTTY versions were considered compromised. The fix was PuTTY 0.81.

WPA2 KRACK (2017): Mathy Vanhoef's KRACK attack exploited nonce reuse in WPA2's 4-way handshake. By forcing a client to reinstall an already-installed key, the attacker caused the client to reset its nonce counter to zero. This produced keystream reuse, allowing the attacker to decrypt and forge packets. The vulnerability was in the protocol, not in RC4 specifically, but it demonstrates how nonce management failures break even well-designed systems.

Use a counter: The simplest correct approach is a monotonically increasing counter stored alongside the key. Each encryption increments the counter. This is deterministic and guaranteed unique as long as the counter never wraps around. The downside is that the counter must be persisted, and if the key is copied to another system, the counter must be copied too.

Use random nonces with collision checking: Generate a 96-bit random nonce for each encryption. The birthday bound for 96 bits is 2^48, meaning you can encrypt approximately 2^48 messages before the probability of a collision exceeds 50%. For most applications, this is more than sufficient. NIST SP 800-38D limits AES-GCM to 2^32 invocations per key when using random 96-bit nonces, which keeps the collision probability below 2^(-32).

Use deterministic ECDSA (RFC 6979): For ECDSA, the best practice is to use RFC 6979 deterministic nonces. Instead of generating a random k, derive k from the private key and the message hash using HMAC. This eliminates the random number generator entirely and guarantees that the same message always produces the same signature under the same key. EdDSA (Ed25519, Ed448) uses deterministic nonces by design.

Never use a general-purpose PRNG for nonces: Use a cryptographically secure random number generator (CSPRNG). In the browser, use crypto.getRandomValues(). In Node.js, use crypto.randomBytes(). In Go, use crypto/rand. General-purpose PRNGs like Math.random() or rand() are predictable and have led to real-world key compromises.

Nonce management is one of the hardest problems in applied cryptography because the failure mode is silent. There is no error message when a nonce repeats. The encryption succeeds, the ciphertext is valid, and the security is gone. The attacker can exploit the reuse without the user ever knowing.

The XOR calculator demonstrates the underlying operation that makes nonce reuse dangerous. XORing two ciphertexts encrypted with the same keystream produces the XOR of the plaintexts, which is readable with crib dragging.

AES-GCM's nonce space is 96 bits (the recommended size). This gives a practical limit of about 4 billion encryptions per key before the collision probability becomes non-negligible. For high-throughput systems, this means key rotation is mandatory. TLS 1.3 handles this by deriving a new key for every connection using HKDF, so each connection has its own nonce space.