You encrypt the message “Bring biscuits.” Then you encrypt it again, using the same secret key. The two encrypted results look different.
If your calculator gave different answers to the same calculation, you would return it. In modern encryption, this kind of variation can be exactly what you want. The missing ingredient is a nonce: a small input with an unusually strict job description.
It need not be secret. It may not even need to be random. But use it incorrectly, and formidable mathematics can lose its protection surprisingly quickly.
Why Can the Same Message Produce Different Ciphertext?
For a nonce-based encryption scheme, “same message, same key” leaves out an input. Change the nonce, and the encryption process can produce a different ciphertext while preserving the ability to decrypt it correctly.
A useful simplified model is:
Encrypt(key, nonce A, message) → ciphertext A
Encrypt(key, nonce B, message) → ciphertext BThink of a kaleidoscope: the same colored pieces produce different patterns when its configuration changes. The analogy stops there; a real cipher has precise security requirements, rather than a particularly attractive collection of mirrors.
Varying the encryption helps prevent identical messages from becoming recognizable matching ciphertexts. Encryption still generally reveals length unless the surrounding system adds padding; hiding content does not automatically hide every observable detail.
What Is a Nonce in Cryptography?
The word is commonly explained as “number used once.” For common schemes such as AES-GCM and IETF ChaCha20-Poly1305, the crucial requirement is to avoid repeating a nonce with the same key. A key may protect many messages within the scheme’s usage limits; each encryption needs suitable nonce management.
| Component | Its job | Must it be secret? |
|---|---|---|
| Key | Controls encryption and decryption. | Yes, for the symmetric schemes discussed here. |
| Nonce | Distinguishes encryption operations under that key. | No; uniqueness requirements still matter. |
| Authentication tag | Helps the receiver detect tampering with authenticated inputs. | No. |
The nonce can be stored alongside the ciphertext or reconstructed according to a protocol. The receiver uses the appropriate nonce and key; it does not guess which version of “Bring biscuits” you meant.
An authentication tag adds another important protection. Schemes described as AEAD combine encryption with authentication and can also authenticate selected unencrypted information, called associated data. The AEAD interface in RFC 5116 distinguishes these inputs. A tag is not a digital signature identifying a particular person.
You can decrypt the same stored file again tomorrow; that is not the dangerous reuse. The problem is encrypting new data with a key–nonce pair that has already been used.
The Repeated Input That Makes a Secret Disappear
Our ChaCha20 explanation introduces the keystream: pseudorandom-looking bytes combined with the message using XOR. XOR returns 1 where two input bits differ and 0 where they match.
Here is a deliberately tiny example using one invented keystream byte. This is arithmetic to explain reuse, not a real encryption scheme:
Message A: 01000001
Message B: 01000010
Reused keystream: 00101100
Ciphertext A: 01101101
Ciphertext B: 01101110Now XOR the two ciphertexts:
01101101 XOR 01101110 = 00000011
01000001 XOR 01000010 = 00000011The keystream cancels out. An observer learns the XOR of the original messages without knowing the secret key. If one message is known, the overlapping part of the other can be recovered.
This is why repeating the same key and nonce in ChaCha20-Poly1305 is serious: RFC 8439 describes the repeated keystream and authentication key. It does not magically reveal every message ever encrypted, but it breaks protections you were relying on. AES-GCM nonce reuse can also undermine confidentiality and enable forgeries.
Random Is Not the Same as Never Repeated
Imagine a ticket machine choosing randomly from 4,096 numbers. After just 76 independent draws, the probability of at least one duplicate is about 50%. You have used fewer than 2% of the possible tickets. The birthday effect is doing its usual party trick.
That is a toy calculation, not a recommendation for nonce size. Real schemes use much larger spaces, and their limits must account for message counts, message sizes, and the nonce-generation method. Random selection makes collisions unlikely; it does not make them impossible.
A carefully managed counter can provide uniqueness without unpredictability. But “carefully managed” matters: two servers starting at zero under the same key, or a restored backup rolling a counter backward, can repeat values. Libsodium’s AEAD documentation discusses nonce strategies and the need to choose them for the construction being used.
A clock is not automatically a safe substitute. Concurrent messages can share a timestamp, and clocks can move backward. A unique-looking value needs a uniqueness argument.
Your Browser Already Handles a Version of This
In TLS 1.3, the protocol derives a per-record nonce by combining a padded record sequence number with an initialization value derived for the traffic key. RFC 8446 specifies the construction; the sender does not improvise a fresh nonce recipe for every packet.
This is one reason established protocols matter. They organize key derivation, record numbering, authentication, and usage limits together. The cipher is part of the security design, not the entire design.
Nonce uniqueness during encryption also does not, by itself, prevent replay. A captured valid message may still have a valid tag when resent; the receiving protocol needs appropriate state or replay checks.
Two Exceptions That Keep the Explanation Honest
IV requirements depend on the mode. Initialization vector is a related term, but it is not a universal promise that a counter will work. For example, NIST requires an unpredictable IV for CBC encryption. Follow the specific construction’s rules.
Some encryption is intentionally deterministic. AES-SIV supports deterministic authenticated encryption: the same plaintext and associated data under the same key can produce matching outputs, revealing equality. That is a deliberate trade-off, not evidence that every repeated ciphertext indicates broken cryptography.
What to Check in a Real Application
- Use an established authenticated-encryption API and follow its nonce requirements; the cryptography library’s documentation makes those requirements explicit.
- Establish how uniqueness survives restarts, parallel workers, cloning, and backup restoration.
- Respect the construction’s key, nonce, message-size, and usage limits; a longer key does not repair nonce reuse.
- Verify authentication before accepting data, using the library’s supported decryption interface.
Different ciphertexts are not proof that an application is secure. But understanding why they can differ reveals something essential: modern encryption protects messages through a combination of sound mathematics and disciplined handling of its inputs. Even a tiny nonce has a job that cannot be delegated to wishful thinking.