5
$\begingroup$

I have two questions regarding the Block Cipher Modes:

  1. Which one of the modes is considered the best?
    I know CBC has a problem of IV since the next block of the plain text is XORed with the result of cipher text of the last block and the same with OFB. Is CTR the best one or not?
  2. In "SSL with blockciphers in CBC-mode", does TLS 1.2 use CBC or is there any other modes that is used with TLS 1.2 (SSL 3.0)?
Improve this question
$\endgroup$
3

3 Answers 3

Reset to default
8
$\begingroup$

Personally I like the modes that support integrity checking and authentication, e.g. GCM, as they only require one key, and are not vulnerable to changes in the cipher text. One particular important problem area is padding oracle attacks, which are much more common than people seem to admit.

Note that GCM/AES is - just like CTR - a block cipher in stream cipher mode; Basically GCM consists of a GMAC and CTR combination.

GCM is supported by XML encryption v1.1 (XML encryption by itself is very vulnerable to padding oracle attacks). There is also https://www.rfc-editor.org/rfc/rfc5288 which describes the use in TLS and https://www.rfc-editor.org/rfc/rfc5084 which describes the use in CMS.

GCM seems to have some support, e.g. Java 8 introduces GCM in the standard Java Runtime. For Java 7 and below it is required to use an external provider such as Bouncy Castle.

Improve this answer
$\endgroup$
3
  • $\begingroup$ GCM is not really usable in Java 7 because actual cipher-suites are not present in that JCE. Most people use IAIK or BouncyCastle for that purpose. Java 8 should also have GCM by default. $\endgroup$
    – kravietz
    May 30, 2014 at 21:14
  • 1
    $\begingroup$ @kravietz Tested against Java 7 update 60 and - although I thought it was backported - didn't find GCM. Thanks, updated answer. $\endgroup$
    – Maarten Bodewes ♦
    May 31, 2014 at 8:06
  • $\begingroup$ Yes, it's quite misleading - I have done exactly the same a while ago. When you see implementation of GCM params you expect the GCM is there too, but then I get these NoSuchAlgorithmExceptions... $\endgroup$
    – kravietz
    May 31, 2014 at 12:48
6
$\begingroup$

There is no "best" mode of operation, just modes more or less useful in different situations.

CBC-mode requires an initialization vector which is unpredictable by the adversary (preferably random), especially if this adversary can mount a chosen plaintext attack. Up to TLS 1.0 (i.e. also in SSL 2.0 and 3.0), CBC was used with a "use last block of previous message as IV", and this is obviously not unpredictable if there is some time between the messages. TLS 1.1 fixes this by using a random per-message IV.

This problem can be avoided by implementations (without violating the protocol) by sending an empty message (which still gets padded to at least a full block) directly before any real message (i.e. after the application decided the content of the real message), and this is what OpenSSL does for quite some time. (It helps only on the sending side, not the receiving one, though.)

CTR mode requires that the initialization vector is non-repeating for all uses of the same key, as identical IVs give an identical key stream (which is then XORed with the message) - the same is valid for OFB mode.

Improve this answer
$\endgroup$
9
  • $\begingroup$ Is there a link to the security analysis that lead to the decision to let OpenSSL send empty messages the way you describe? The security of CBC does not require the IV to be "unpredictable" but only that it is generated in such way that its distribution is uniform. Then again, there are adaptive timing attacks that can exploit the AtE scheme of SSL 3/TLS 1 in case of IV collisions, but such attacks would still be possible unless the other peer actually verifies that every other message is empty. $\endgroup$
    – Henrick Hellström
    Feb 20, 2012 at 9:57
  • $\begingroup$ What I understood about CTR is that the IV is a combination of nonce and counter; the nonce does not change every time but the counter increases every time, so that means the IV is not identical and it is changed with other blocks. But the real question is why don't they use CTR with SSL? What I think is that CTR is better than CBC in terms of the attack against IV $\endgroup$
    – MR.NASS
    Feb 20, 2012 at 13:51
  • 4
    $\begingroup$ @HenrickHellström: Actually, there are known attacks against CBC with predictable (but well distributed) IVs. The recently published "Beast" attack on SSL/TLS 1.0 is such an example. The empty message that OpenSSL sends disrupts this attack because the IV used to encrypt the real message (record) is the last ciphertext block of the empty record, and that cannot be predicted. $\endgroup$
    – poncho
    Feb 20, 2012 at 15:06
  • $\begingroup$ @poncho: Thanks for the reference. BEAST is a chosen plain text attack, which means it is a concern for e.g. browsers and other software where the attacker might get to choose the plain text without first compromising the whole system. For better or worse, in most other cases (such as C/S business software without scripting capabilities) an attacker who is able to choose the plain text would imply an even worse security breach. $\endgroup$
    – Henrick Hellström
    Feb 20, 2012 at 15:33
  • $\begingroup$ @Paŭlo Ebermann The SSL vulnerability you describe is present in TLS 1.0 and lower, not only in SSL 3.0. $\endgroup$
    – Chris Smith
    Feb 22, 2012 at 21:17
2
$\begingroup$

I think the attack on CBC that you're referring to is a known-plaintext attack where an attacker can manipulate a plaintext by adjusting the previous block of ciphertext. But this same sort of attack also applies to CTR.

[edit] I misinterpreted the OP's referenced to a CBC attack. The one I describe here allows intelligently modifying plaintext by modifying the ciphertext. This is a valid attack to be concerned about and applies to both CBC and CTR, so I will leave it as a part of the analysis of the modes of operation, but it is not the attack mentioned by the OP. [/edit]

CTR is a good mode overall, but it must be used in the right context given that it is a stream cipher. You should not use it in a case where you will be re-encrypting the same data with the same key and IV (for example if you're doing disk encryption). In practice, this often means that you should only use it if you're willing to completely re-encrypt data every time it's edited/saved/transmitted.

The newer block mode XTS is an interesting mode because it does away with the ability to modify the plaintext by altering the ciphertext (like mentioned above), and it also allows for single-block encrypt/decrypt access like ECB and CTR. The disadvantage to it is that it has the same information leakage that ECB and CTR have, namely editing/re-saving ciphertext leaks exactly which blocks were modified. In practice, however, I don't think many people are concerned by that.

Right now there is no official "best" mode, but it seems like there is a heavy favoring of XTS due to the fact that plaintext is not malleable and that it is well-suited for many uses, both of CBC's and CTR's domains. Disk encryption products have switched en masse to XTS recently. I don't think network communications has, though.

For what it's worth, in the book Practical Cryptography (first edition) by Niels Ferguson and Bruce Schneier they made a comment that CTR was "their personal favorite" (paraphrased quote) mode of operation at the time. That was written in about '03, though, and I don't know if that comment was preserved for the second edition of the book; it was made long before XTS came around.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Could you elaborate how one would apply these CBC attacks to CTR? $\endgroup$
    – Paŭlo Ebermann
    Feb 21, 2012 at 20:47
  • $\begingroup$ The confusion was on my part about which CBC attack the OP referenced. I thought it was the attack where an attack can XOR against ciphertext[n-1] to modify plaintext[n], but I was mistaken. Your comment prompted me to re-read the OP, and I've edited my post for clarification. To be clear, it is the attack of XORing against the ciphertext to intelligently modify the plaintext that I was referring to, and that type of attack applies to both CBC and CTR without a MAC. $\endgroup$
    – B-Con
    Feb 21, 2012 at 21:31
  • $\begingroup$ Ah, yes. CTR is even more malleable than CBC (since changing arbitrary ciphertext bits in CTR change the corresponding plaintext bits, and nothing else, while in CBC you'll also get a "random" block as the result, if you are not just attacking the first block by changing the IV). $\endgroup$
    – Paŭlo Ebermann
    Feb 22, 2012 at 8:36

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.