Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sometimes I read that nonce have to be a random number but imho it's wrong, nonce just should not repeat itself. You could increase in by 1 every time if you are sure it would never repeat.

share|improve this question
en.wikipedia.org/wiki/Cryptographic_nonce - "In security engineering, nonce is an arbitrary number used only once in a cryptographic communication" –  Henrick Hellström May 30 '13 at 18:41
So defining it as a random number is wrong? Wikipedia is not a source. –  Smit Johnth May 30 '13 at 18:45
In this case Wikipedia is right. Nonce = number used once. It does not have to be generated at random, in fact, generating at random might cause repetitions, with a probability that is a function of the bit length of nonce. –  Henrick Hellström May 30 '13 at 18:55
Is there a real source for that? Our professor has given it as a random number on his lection. –  Smit Johnth May 30 '13 at 19:02
The link on the Wikipedia page is good: cs.ucdavis.edu/~rogaway/papers/nonce.pdf The example in the introduction of that paper is to use a counter as nonce. –  Henrick Hellström May 30 '13 at 19:07
add comment

3 Answers

Yes, a nonce is a number not used more than once. In its purest sense there should be no other requirements than this, i.e. randomness or unpredictability should not be necessary.

However, in certain settings stronger requirements are put on the nonces; like for instance in the CBC-mode of operation for block ciphers the IV (nonce) needs to be unpredictable (a requirement, when not followed, actually have led to real-life problems in the SSL/TLS-protocol: Why is CBC with predictable IV considered insecure against CPA).

See also: What's is the main difference between a key, an IV and a nonce? for a more comprehensive discussion of the properties of nonces and IV's.

share|improve this answer
I'm confused: does it mean "nonce actually don't have to be random, but sometimes yes"? –  Smit Johnth May 30 '13 at 19:11
A common way to generate an unpredictable IV for CBC is to simply encrypt the counter value before using it as IV. The IV doesn't have to be random; pseudo-random is fine. –  Henrick Hellström May 30 '13 at 19:15
You asked for a definition of a nonce, and I provided what I consider to be the "right" notion; namely a value which is simply not used more than once (that's it!). Unfortunately there's much ambiguity in how the terms nonce and IV's are used in practice. So you might see several sources calling the first input to CBC-mode a nonce, whereas I would have preferred calling it an IV. –  hakoja May 30 '13 at 19:16
...what I'm trying to say is that, I think that a definition of a nonce should not impose ANY other requirements other than that it should not be used more than once. This does not forbid you from putting additional constraints on it. –  hakoja May 30 '13 at 19:21
add comment

Definition 10.9 in Chapter 10 of Handbook of Applied Cryptography.

A nonce is a value used no more than once for the same purpose. It typically serves to prevent (undetectable) replay.

Continuing on, there is some additional info that you might find interesting.

The term nonce is most often used to refer to a “random” number in a challenge-response protocol, but the required randomness properties vary.

share|improve this answer
add comment

There may be some particular scenarios where an unpredictable nonce is better than just a unique nonce.

For example suppose you have access to an oracle that can generate the correct response to an authentication request that involves a nonce, but you don't have real time access; in particular by the time you get the response from the oracle, the challenge will have expired.

If you can predict what the nonce is going to be (e.g. prev nonce + 1), then you can use the oracle to establish the correct response in advance, then run the protocol against the victim and have the response ready.

An example where this could be realistic is if your challenge-response protocol is cryptographically weak and can be brute-forced, but it takes a long time (e.g. days with the attacker's resources) to do the brute-forcing. An unpredictable nonce would have prevented the vulnerability from being exploitable.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.