Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As you all know, the SSL/TLS protocol requires both client and server to exchange (in clear text) a random number or nonce. This is presumably used to prevent replay attacks.

It is not clear to me what the server-side nonce requirement is. Must it simply be unique? Or must it also be unpredictable? What would be the implications if an attacker could predict the nonces generated on the server side, if any?

I welcome any source of serious work around replay attacks that could help better understand the server side nonce requirements.



share|improve this question
up vote 11 down vote accepted

Within SSL/TLS, the nonces are used for generating symmetric keys, and as part of the signatures and checks during the handshake. For all those usages, the nonces are simply concatenated (with some other data) and hashed. Assuming that the hash functions behave like "random oracles" (the mythical perfect hash function), then unique nonces are sufficient.

However, SSL/TLS up to (and including) TLS 1.1 uses MD5 and SHA-1 as hash function, for which weaknesses have been demonstrated. They are not random oracles. I am not aware of any result about turning these weaknesses into attacks on SSL/TLS itself; however, better be safe than sorry: use unpredictable nonces. This will not harm, and both client and servers must already have access to a cryptographically secure source of alea, hence unpredictable nonces should not be a too heavy requirement.

share|improve this answer
Thank you Thomas. This was indeed the kind of answer I was looking for. Louis. – Louis Mar 6 '11 at 12:48

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.