Picking a nonce in the context of CCM (CTR with CBC-MAC) mode

Question

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:

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?

score 6 · Accepted Answer · answered Sep 16 '15 at 14:05

6

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.

answered Sep 16 '15 at 14:05

Ilmari Karonen

46,120
5
105
181

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? – Sebi Sep 16 '15 at 17:01
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. – Ilmari Karonen Sep 16 '15 at 17:28
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. – Sebi Sep 16 '15 at 17:38
5

There is no need to encrypt the nonce. – Ilmari Karonen Sep 16 '15 at 17:40

score 4 · Answer 2 · answered Sep 16 '15 at 14:20

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.

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. — Sebi, Sep 16 '15 at 17:02

Picking a nonce in the context of CCM (CTR with CBC-MAC) mode

2 Answers2

Linked