Cryptographic nonce

A cryptographic nonce, short for “number used once”, is a value that must never repeat within a given key or protocol context, used to make each encryption, signature or protocol run unique. In cryptography it prevents replay attacks and stops identical inputs from producing identical outputs, and in modern authenticated encryption it is a hard security requirement: reusing a nonce with the same key can destroy both confidentiality and integrity.

A nonce is not necessarily secret. Depending on the algorithm, it may be sent in the clear, generated by a simple counter or drawn at random. What matters is that it meets the exact property the algorithm demands, usually uniqueness and sometimes unpredictability.

Why cryptographic algorithms need a nonce

Deterministic algorithms turn equal inputs into equal outputs. Without a nonce, encrypting the same message twice under one key would produce the same ciphertext, revealing to an observer that the messages match. A nonce adds a unique ingredient to every operation, so repeated plaintexts look unrelated.

In protocols, nonces provide freshness. A server that issues a random challenge and expects it back inside a signed or encrypted response can be sure that the response was created now, not recorded earlier and replayed. Authentication schemes such as Kerberos, HTTP Digest authentication and OpenID Connect all rely on this idea.

Nonce sizes and generation methods

Each algorithm defines its nonce length, and that length determines whether random generation is safe. With a random nonce, the risk of a repeat grows with the number of messages under one key, following the birthday bound; short nonces therefore need counters or strict message limits.

For random 96-bit nonces under one AES-GCM key, NIST guidance limits use to about 2 to the power of 32 messages, keeping the collision probability negligible. Counter-based nonces avoid that limit but require reliable state: a counter that resets after a crash, a restored virtual machine snapshot or two servers sharing one key will silently repeat values.

Because a nonce is usually not secret, applications commonly store or transmit it next to the ciphertext, for example as a 12-byte prefix. Protocols can also derive nonces implicitly: TLS 1.3 combines a per-connection static IV with the 64-bit record sequence number, so each record gets a unique nonce without sending any extra bytes, and both sides stay in step as long as records arrive in order.

What happens when a nonce is reused

Nonce reuse is one of the most damaging implementation errors in applied cryptography, because it breaks algorithms that are otherwise sound. The consequences depend on the construction, as the table shows.

Real incidents show the pattern. A game console signing system used a constant ECDSA per-signature value, which allowed its private signing key to be calculated from public signatures. The KRACK attacks on WPA2 in 2017 forced Wi-Fi clients to reinstall keys and reset nonce counters, enabling decryption and packet injection. In both cases the cipher was strong; nonce handling was not.

Nonce compared with IV, salt and challenge

Several cryptographic inputs look similar but carry different requirements, and mixing them up causes errors. A nonce emphasizes uniqueness, while an IV in some modes must also be unpredictable, and a salt protects stored secrets rather than messages.

In cryptocurrency mining, the word nonce describes a field miners vary while searching for a block hash below a target. That use shares the name but not the security role discussed here, since a mining nonce may repeat across blocks without harm.

Good practice for nonce handling

• Use high-level libraries that generate and attach nonces automatically, rather than managing them by hand.
• Prefer extended or misuse-resistant constructions, such as XChaCha20-Poly1305 or AES-GCM-SIV, when nonce state is hard to guarantee.
• Rotate keys before message limits are reached, especially with random 96-bit nonces.
• Use deterministic signatures, such as RFC 6979 ECDSA or Ed25519, to avoid weak per-signature randomness.
• Never derive nonces from timestamps alone, since clocks repeat, drift and collide across servers.
• Generate protocol challenges with a secure random generator, never with general-purpose pseudo-random functions.

A useful review question for any design is simple: under which events could this value repeat with the same key? Crashes, backups, cloning and parallel workers are the usual answers.

The simple explanation

A cryptographic nonce works like a ticket number that may never be issued twice. Each time a system locks a message, it adds a fresh number, so even two identical letters end up looking completely different once sealed.

If the same number is ever used twice with the same key, the protection can fall apart surprisingly badly, sometimes revealing the messages themselves. That is why careful systems treat nonces like serial numbers in a bank: always new and never repeated.

How it is used in practice

A messaging service encrypts stored chat history with AES-GCM. Each record originally received a nonce from a per-server counter kept in memory. After an outage, operators restored two application servers from the same snapshot, and both began issuing the same counter values with the same key.

A security review spots the duplicated nonces before an attacker does. The team re-encrypts the affected records under a fresh key and switches to XChaCha20-Poly1305 with random 192-bit nonces, which needs no shared counter. The new design survives restores, scaling and crashes, and the review checklist now asks how every nonce stays unique across all servers.