5
$\begingroup$

For the CTR mode, the design is good for parallelization, yes, it seems the benchmark of the program downloaded from crypto++ proves that on an Intel I7 CPU.

My question is that as most of CPU on the computers today are multicore and designed good for multithread calculation, why not all people use the CTR mode as it is much faster than the CFB mode (about 4 times faster on Intel I7-4770K, 3.5GHz CPU)?

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ One problem with CTR mode is that there isn't just a single way of turning counter and nonce into input for the block cipher core. $\endgroup$
    – CodesInChaos
    Jan 28, 2015 at 11:26
  • $\begingroup$ People are known for not using best choice, but instead most popular/simple one: RC4, DES, 3DES, AES. Same with modes: ECB, CBC. List goes on: MD5, RSA... $\endgroup$
    – axapaxa
    Oct 29, 2017 at 21:11

3 Answers 3

Reset to default
9
$\begingroup$

There are probably quite a few good reasons for this, although I don't expect that a scientific answer can be composed (as you would need to use a survey, and I've never heard of such a thing for modes of operation).

Let me list a few possible reasons:

  1. Developers don't know about CTR mode of operation; most questions on StackOverflow are about ECB and CBC (I really hope that SO doesn't reflect corporate practices everywhere);
  2. Even today it is possible that CTR mode is not available for some runtimes (only ECB and CBC mode are practically guaranteed on most lower level libraries);
  3. (Older) protocols may simply specify other modes of operation.

With regards to the parallelism provided:

  1. AES is already pretty fast, doubly so if AES instructions are present within the chip - for instance AES-NI within Intel/AMD CPU's - so the parallelism provided by CTR mode are not often required;
  2. Many problems that require fast crypto are embarrassingly parallelizable by themselves (e.g. multiple file encryption and TLS sessions to a server);
  3. Multi-threading is hard to get right, and may be hard to use (for instance, you may not want all your cores to be just encrypting data);

You think in CPU terms. Loads of people however don't use C/C++ but use higher level languages. These may have a totally different level of operation and may not have good support for modes of operation, let alone multi-threading support for these modes of operation.

If you want to create a protocol that is supported on lots of devices you may need to standardize on CBC as highest common denominator. C/C++ may be fast, but software created in those languages is also notoriously hard to secure, leaving you exposed to all kinds of attack. Speed is nice, but it is useless if you lose your data because of a buffer overflow.

In the cryptographic community CTR is probably the hottest mode in town. It is for instance used in GCM, CCM and EAX (authenticated modes of operation) as underlying mode to provide confidentiality. It has one particular cryptographic property that is not nice: nonce (IV) reuse is catastrophic to the confidentiality of messages send with CTR. The IV in CBC mode is harder to get right, but it doesn't fail as badly if you don't.

In the end, CTR mode is often simply not required. But with the advance of AEAD modes that use it for encryption / message confidentiality, it may be that it makes a stealthy comeback; many developers will be using it without even knowing that it is there.

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ @Anthony Good point, I only gave that answer for his other question. Thanks! $\endgroup$
    – Maarten Bodewes ♦
    Jan 28, 2015 at 15:33
  • 2
    $\begingroup$ @Anthony Luckily implementing CTR on top of ECB is pretty easy. Perhaps 10 lines of code. $\endgroup$
    – CodesInChaos
    Jan 28, 2015 at 17:04
  • 2
    $\begingroup$ Nice answer, but maybe a (too) basic point is missing: It doesn't pay off to parallelize encryption of a single message with multiple blocks (multiple messages is trivial) - maybe except for file encryption. Often encryption makes up a tiny portion of overall processing time or the time until finished is not that important. Supporting more modes in common languages/libraries would be nice - but there is little reason, if it doesn't help anyone. $\endgroup$
    – tylo
    Jan 28, 2015 at 20:05
  • 1
    $\begingroup$ @MaartenBodewes In that case I couldn't use what Microsoft built into .NET either. In fact whenever I needed raw CTR (not authenticated encryption like GCM), I needed random read access, which the .NET API doesn't provide. $\endgroup$
    – CodesInChaos
    Jan 28, 2015 at 20:43
  • 2
    $\begingroup$ A detailed scientific analysis of block cipher modes of operation can be found in Phillip Rogaways Paper Evaluation of Some Blockcipher Modes of Operation from 2011. $\endgroup$
    – rob
    Jan 29, 2015 at 7:17
2
$\begingroup$

My own two cents on this is that it started with a psychological bias, due to the illusion that AES-ciphering consecutive numbers in CTR mode is a weakness compared to the recursive AES-ciphering in CBC. Actually, I think I remember it was more of less told during that course on Coursera, that a consensus about the inoffensiveness of that counter with regard to possible attack angles was not reached at the beginning.

The bias might yet be lingering, among those who choose for the first time and are still fresh about cryptography concepts. But even without it, I guess CTR mode adoption was belated.

Improve this answer
$\endgroup$
0
$\begingroup$

Old question but I'd like to chip in with something that has not been mentioned.

Note that CTR, OFB (and partly, CFB) are idempotent modes of operation, because encryption and decryption algorithms use the same (or similar) algorithms. This means that, for a given IV, key, and message, we have $$ E_{key}(IV, E_{key}(IV, message)) = message $$

This is per design and efficiency, however, for some applications, it may lead to unauthorized decryption (or encryption).

Improve this answer
$\endgroup$

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.