8
$\begingroup$

After having read the RFC 3610: Counter with CBC-MAC (CCM) and the Wikipedia article on CTR mode, I'm not sure how a nonce should be picked. The RFC says:

  1. A nonce N of 15-L octets. Within the scope of any encryption key K, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicate values. Using the same nonce for two different messages encrypted with the same key destroys the security properties of this mode.

If the nonce values must not contain any duplicate elements doesn't this imply that they should be known to all parties in a transaction. For instance if a client wishes to authenticate and communicate with a server, shouldn't they both have a predefined set of nonces. If not, how should they be exchanged, given that the context only allows for CTR-AES encrypted messages?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
6
$\begingroup$

Yes, if the client and the server use the same key to encrypt their messages (instead of having separate keys for client-to-server and server-to-client communication), then you need to ensure that they cannot ever use the same nonce.

One way to do that would be to, say, let the client use only even nonce values, and let the server use only odd nonce values. Of course, other ways of partitioning the nonce space are equally possible.

Improve this answer
$\endgroup$
4
  • $\begingroup$ I understand, but still the nonces, still need to be exchanged beforehand, no? Otherwise the server is unable to decrypt a message received from the client? $\endgroup$
    – Sebi
    Sep 16, 2015 at 17:01
  • $\begingroup$ Typically, you would either send the nonce along with the message, or derive it from other unique information associated with the message, such as a message ID. $\endgroup$
    – Ilmari Karonen
    Sep 16, 2015 at 17:28
  • $\begingroup$ Doesn't this create a chicken and egg problem: the nonce is encrypted and sent along with the message. But if it's sent in plain text then security is affected. $\endgroup$
    – Sebi
    Sep 16, 2015 at 17:38
  • 5
    $\begingroup$ There is no need to encrypt the nonce. $\endgroup$
    – Ilmari Karonen
    Sep 16, 2015 at 17:40
4
$\begingroup$

Like Ilmari Karonen wrote, you can ensure that nonces picked by two senders do not collide by reserving one bit (like the lowest) to differentiate them.

If you use random nonces this is not required, since the probability that a random nonce collides depends only on the total number of nonces generated, not who generates them. In fact, reserving a bit would make collisions more likely if one sends more messages than the other.

Random nonces can be a bit risky with AES CCM, however, since the nonce since is only $15-L$ bytes, where $L$ is the number of bytes used for the counter. With 32-bit counters you have only 11 bytes for the nonce, which is enough, though barely. The probability of collisions reaches $2^{-32}$ after only a couple of hundred million messages. With larger counters you would need to use non-random nonces.

Improve this answer
$\endgroup$
1
  • $\begingroup$ The thing I don't understand entirely is: how are nonces sent between the client and the server since sending encrypted messages using the same key and nonce breaks the security of the scheme. $\endgroup$
    – Sebi
    Sep 16, 2015 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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