2

The following question is about a specific protocol that uses a modified version of the CCM mode. Since I'm not a cryptographer, the protocol specification provides no reasoning for this change to CCM or proof of security, I'd like to know if this might have any practical or theoretical implication for the security of the encryption and authentication.

In NIST 800-38C and RFC 3610 the CCM mode creates the $S_0, ..., S_m$ by encrypting the counter blocks in the following way:

  • For $j=0$ to $m$, do $S_j=CIPH_K(Ctr_j)$

Then the $S_1$ to $S_m$ are concatenated to form $S$. Note this doesn't use $S_0$:

  • $S = S_1 || S_2 || ... || S_m$.

The encryption of the plaintext $P$ is done by xoring it with the $Plen$ most significant bits of $S$ and the MAC $T$ is xored with the $Tlen$ most significant bits of $S_0$:

  • $C = (P \oplus MSB_{Plen}(S)) || (T \oplus MSB_{Tlen}(S_0))$

The step where the protocol in question deviates from the standard CCM is in the construction of $S$. It includes $S_0len - Tlen$ of the least significant bits of $S_0$ into $S$.

  • $S = LSB_{S_0len - Tlen}(S_0) || S_1 || S_2 || ... || S_m$

The ciphertext is still created through:

  • $C = (P \oplus MSB_{Plen}(S)) || (T \oplus MSB_{Tlen}(S_0))$

It is ensured that the $MSB_{Tlen}(S_0)$ and $LSB_{S_0len - Tlen}(S_0)$ never overlap.

In my layman's eyes it seems like a strange change. However, since the $Ctr_0$ is constructed in the same fashion as the other counter blocks and the particular bytes used for xoring aren't that same between the encryption and authentication, it might not degrade security? Is there any obvious reason why someone would want to include parts of $S_0$ into the encryption?

Community
  • 1
DobTheBard
  • 45
  • 4

1 Answers1

1

The reason why $S_0$ is not used by the encryption is because it is already used by the final calculation of the authentication tag:

The authentication value U is computed by encrypting T with the key stream block S_0 and truncating it to the desired length.

 U := T XOR first-M-bytes( S_0 )

So yeah, the protocol simply uses the leftover bits of the first block of the key stream. These should be unpredictable to the adversary, so I don't see any issue using them.

It obviously is slightly more efficient when it comes to the amount of block operations for some messages. This makes most sense for small messages on limited machines where the block operation takes more time than all the rest of the calculations and 16 byte alignment doesn't matter. If the messages are all of a specific size then it might remove one block operation for each message.

All in all, using bits from the keystream that are otherwise not used is fine. For me, I would wonder if it is worth deviating from a standard for it, but that isn't a question of security but of interoperability. You'd have to start by writing or adjusting an algorithm, so that in itself may be enough reason to discard it.

It of course also assumes that the tag size is smaller than 128 bits, and undercutting the tag size in itself is dangerous as well (although it doesn't have the same security implications as for e.g. GCM). If the tag size is 128 bits then the entire block is used and the scheme is just normal CCM again.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • The increased efficiency would only apply for a $P$ with $Plen \leq S_0len - Tlen$, since otherwise you need to calculate all $S_0$ to $S_n$ as usual, correct? – DobTheBard Feb 18 '20 at 10:15
  • 1
    No, it would be if $Plen \bmod N \leq N - Tlen$ where indeed $N$ is the blocksize so $N \equiv S_{0}len$. If you need one counter block less to encrypt... – Maarten Bodewes Feb 18 '20 at 10:18
  • Right, my bad. Had an off by one error in my head :) – DobTheBard Feb 18 '20 at 10:23