What Is a Nonce in Security? A Plain English Guide (2026)

What is a Nonce in security? A nonce (number used once) is a value that must never repeat within a defined cryptographic context, such as one key or one login challenge. It blocks replay attacks, keeps encryption safe, and powers CSP, TLS and Bitcoin mining. Uniqueness is the rule. Randomness is only required when the protocol says so.

Okay, that's the one minute version.

Now let me show you why it matters.

What Is a Cryptographic Nonce?

I'll be honest: when I first saw the word, I assumed it was a typo. It isn't. In this section, I'll give you the definition, then clear up the nonce vs IV vs salt confusion that trips up almost everyone.

The NIST glossary says a nonce can be a fresh random value, a timestamp, a sequence number, or a mix of these.

So a counter counts.

A nonce is usually public, and it often travels right next to the ciphertext, as this glossary explains.

How a Nonce Stops Replay Attacks

Here's the problem. An attacker doesn't always need to crack anything. Sometimes they record a valid message and simply send it again. I'll show you how a nonce slams that door, and what happens when somebody leaves it open.

That trick is a replay attack.

In challenge response authentication, the server issues a fresh nonce, and your client answers using that exact value. The server accepts it once, and only once.

The Non Human Identity Management Group recommends a unique nonce, a short lifetime and server side state that marks it as used.

Now the scary example.

CVE-2024-11022 describes a web server whose login challenge could be reused several times. That is exactly the replay weakness a proper nonce prevents.

One honest caveat, though. A nonce stops replayed messages, but it can't stop malware like a keylogger from stealing what you type in the first place. Good security always works in layers.

Where Nonces Show Up in the Real World

You use nonces every day without noticing. Because the idea is so flexible, each protocol applies it differently. This table gives you the whole picture at a glance, and then I'll zoom in on the two that matter most for developers.

TLS and IPsec Nonces

Every time your browser opens a secure connection, the TLS handshake includes a fresh random value. If you want to see how that trust is built end to end, my guide on the SSL certificate chain walks through it.

VPN tunnels work the same way. Key exchange in IPsec also leans on fresh nonces, and you can learn the full picture in what is IPsec VPN.

CSP Nonces

Your server generates a new nonce for every response and stamps it on trusted scripts. MDN's CSP guide covers the syntax, and it's a strong defense against cross site scripting (XSS).

OneTrust's documentation advises at least 128 bits of entropy.

Here's a tiny Node.js example:

javascript

const crypto = require("crypto");
const nonce = crypto.randomBytes(16).toString("base64");
res.setHeader("Content-Security-Policy", `script-src 'nonce-${nonce}'`);

Then add nonce="${nonce}" to each trusted script tag. New request, new nonce.

Nonces in Bitcoin and Proof of Work

Miners change the nonce, hash the header, and repeat. LearnBitcoin notes the nonce is 4 bytes in an 80 byte header. That gives roughly 4 billion values, which modern ASICs exhaust in milliseconds. Miners then change an "extra nonce" in the coinbase transaction to keep searching.

What Changed Recently: Nonce Reuse and AES GCM

If you only read one section, read this one. Nonce reuse is the classic way good encryption fails, and the guidance is still moving. I'll give you the dated facts so you can judge for yourself.

• March 2024: NIST announced it would revise SP 800 38D, the GCM standard, and asked for public comment (due March 14, 2025).

• 2024: Researchers published collision attacks on GCM and urged NIST to forbid 96 bit random nonces.

• Why it hurts: reusing a key and nonce pair in AES GCM can reveal plaintext relationships and enable forgery.

• Proposed fixes: the IETF draft DNDK GCM uses 24 byte random nonces and derives a fresh key per nonce.

My take? If you can't guarantee uniqueness, use a counter or a misuse resistant mode.

How to Use a Nonce Correctly: Step by Step

Reading is easy. Implementing is where teams slip. So here's my exact checklist, in order. Follow it and you'll avoid the mistakes that keep showing up in breach reports.

1. Read your algorithm's rule. Some need only uniqueness. Others also need unpredictability.

2. Use a secure generator. Pick a cryptographically secure random number generator or a guaranteed unique counter.

3. Size it properly. Use 128 bits for CSP nonces.

4. Bind it to context. Tie it to the session, request or transaction.

5. Track state on the server. Mark each nonce consumed once answered.

6. Expire it fast. A short lifetime shrinks the attack window.

7. Reject all reuse. No exceptions.

Common Nonce Mistakes

Every mistake below is easy to make and easy to fix. Use this as a pre flight check before you ship.

• Reusing a nonce under one key. Use a counter or a vetted library.

• Predictable values. Switch to secure randomness.

• Client only state. Attackers control the client, so store state on the server.

• Treating it as a secret. Protect keys, not nonces.

• No expiry. A nonce that lives forever behaves like a password that never changes.

FAQ: Nonce in Security

What does nonce stand for?

It means "number used once." The word itself is old English for something used only for the occasion.

Is a nonce the same as an IV?

Not always. An IV starts a cipher mode and may have stricter unpredictability needs. In some schemes the IV is the nonce.

Does a nonce have to be random?

No. A counter works if uniqueness is guaranteed. Follow your algorithm's rules.

What happens if you reuse a nonce?

It depends on the scheme, but it can expose plaintext relationships, enable forgery, or break confidentiality entirely.

Is a nonce secret?

Usually not. It is normally sent or stored alongside the ciphertext.

Final Thoughts

A nonce is a tiny value with a huge job.

It blocks replays, hardens your CSP and keeps encryption honest.

Here's my challenge: audit one login flow, one inline script and one encrypted message today. Ask whether any value could repeat.

If the answer is "maybe," fix it now.