0
$\begingroup$

Is there any reason why CCM was created with encryption/decryption being done with a counter versus using CBC-then-MAC?

$\endgroup$
1
  • 3
    $\begingroup$ Melab, I don't see any accepts on any of your answers. Do you know you can upvote and accept answers? It's the SE way of saying thanks and - of course - to indicate that the question has been answered. If the question is not answered, then please indicate what is missing. $\endgroup$
    – Maarten Bodewes
    Jan 9, 2018 at 22:59

1 Answer 1

7
$\begingroup$

CTR mode was previously considered a relatively brittle scheme, and in a sense it is. Repeating the nonce will repeat the counter, and repeating the counter will repeat the key stream. This means that the security of the plaintext is broken rather spectacularly on nonce reuse.

However, using CTR has many advantages over CBC:

  • You can use a nonce instead of a randomized IV (deterministic vs random);
  • You don't need to bother with padding or ciphertext stealing (no expansion of ciphertext above plaintext size);
  • Because of above it is not vulnerable against padding oracle attacks (decryption before verification is not vulnerable);
  • You only need to use the block cipher in one direction (simplification of the encryption scheme, less hardware required);
  • Online encryption/decryption is perfectly possible (immediate encryption / decryption without caching);
  • Ciphertext streams may be cached for efficient, byte oriented encryption / decryption (low latency);
  • As the counter values can be generated in advance, pipelined AES implementations may offer (much) higher performance - see the comment from Yehuda for a description (speed).

So nowadays about every AEAD cipher uses CTR mode underneath. And that's fine, as long as you do indeed provide it with a nonce.

The fact that you can also search within the ciphertext (skip to a specific offset) is of little interest for AEAD ciphers as you would generally not use the data without first verifying the authentication tag. So although it is an advantage of CTR mode, it doesn't make much of a difference within an AEAD cipher such as CCM.

One problem with CTR is that the construction of the counter itself isn't well specified (location of the IV, additional data, etc.). But within an AEAD cipher this is not an issue as the AEAD algorithm itself will specify the precise construction of the counter.


The question is more why the archaic CBC mode is still used that much. It's not as brittle as CTR mode when it comes to the IV, but that comes at a very high price, including additional requirements for that same IV.


Also note that the use of a CBC mode together with a CBC based MAC may not be such a good idea if the same key is used for both; it is easy to introduce conflicts between the two, threatening the security of a scheme providing both confidentiality and integrity of messages.

$\endgroup$
4
  • 1
    $\begingroup$ One of the most important properties of CTR today vs CBC is that it can be pipelined. When using AES-NI this means that it is 4-7 times faster. Of course, with CCM you still get slowed down because of the CBC-MAC, but when comparing CBC to CTR it's worth stressing this. $\endgroup$ Jan 9, 2018 at 6:34
  • 1
    $\begingroup$ I guess this is similar to the caching point that I made? Where multiple blocks of the key stream can be generated at once? Or are you referring to a different property? $\endgroup$
    – Maarten Bodewes
    Jan 9, 2018 at 10:49
  • 3
    $\begingroup$ I am referring to something else. Caching means that I can compute the bitstream ahead of time. I am talking about the time that it takes to compute the bitstream. The AES-NI instruction set enables you to compute the first AES round of the first block, and then in the next cycle compute the second AES round of the first block together with the first AES round of the second block, and so on. So, if you know the blocks to be encrypted you can essentially do 4-7 blocks at the cost of one (depending on processor). This cannot be done with CBC since you don't know future blocks to encrypt. $\endgroup$ Jan 9, 2018 at 12:34
  • 1
    $\begingroup$ Ah, alright, I didn't know that. So it is kind of related to the possibility to cache the bitstream but it is certainly not the same. Interesting, thanks (I'll integrate it into the answer)! $\endgroup$
    – Maarten Bodewes
    Jan 9, 2018 at 12:42

Your Answer

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

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