Hacker News Reader

Comment by schizoidboy | Hacker News Reader

In the Symmetric ciphers section, it ends with "This leaves 5-9 and 15" but why are 2-4 bad (aes128-cbc, aes192-cbc, aes256-cbc)? It seems the argument is that GCM is better than CBC, and CTR is okay. My general impression is that CBC is preferred (for example, Rails uses AES-256-CBC by default in its MessageEncryptor class).

View on HN

My understanding is that, in general, AEAD (such as GCM) > CTR >= CBC > [ a lot of modes ] > ECB

CBC requires unpredictable IVs. CTR works with an integer starting at 0, so long as you never repeat.

The author's motive for not eliminating CTR was stated as compatibility. If you ask me, just use chacha20-poly1305 if you can. If you can't, there are probably more important problems for you to deal with (i.e. upgrading your legacy systems).

When you are reusing symmetric keys, both CBC and CTR require unique IV (as do all reasonable block cipher modes).

    When you are reusing symmetric keys, both CBC and CTR require unique IV (as do all reasonable block cipher modes).

Contrast to:

    CBC requires unpredictable IVs.

and

    CTR works with an integer starting at 0, so long as you never repeat.

http://dictionary.reference.com/browse/unique?s=t&path=/

http://dictionary.reference.com/browse/unpredictable?s=t&pat...

At no point did my statement make an error that was addressed by your reply.

CBC IV does not in general have to be unpredictable.

But my main point is that there is no significant difference between block cipher modes in regards to requirement for IV as even CTR mode requires IV when used with repeated keys (and arguably repeated IV is more severe concern for CTR mode than for CBC) and conversely, you can just use constant IV for CBC when you can guarantee that used keys are unique.

> CBC IV does not in general have to be unpredictable.

Yes, it does. If not, you lose IND-CPA. That is, if it is predictable the attacker gets to test guesses for the plaintext of other blocks.

Read Duong and Rizzo, "Here come the XOR Ninjas", 2011. http://www.hpcc.ecs.soton.ac.uk/~dan/talks/bullrun/Beast.pdf

The impact of a repeated CBC IV is less significant than that of a repeated CTR nonce, so in that respect CBC is more conservative. CTR is the better choice for modern code, but the security implications are a coinflip difference.

CBC in TLS is bad and deprecated in (not yet released) TLS 1.3. AFAIK, CBC in general is not broken if you pad it properly and authenticate it properly, especially if you authenticate before decryption (which TLS does not do).

Apparently implementing CBC correctly is too complex to do right:

https://www.imperialviolet.org/2013/10/07/chacha20.html

No, that's not what he's saying. He's saying that making the TLS CBC constructions secure is hard. They were designed in the 1990s. Making a CBC implementation secure today is much easier.

Indeed, just about every brand of SSL load balancer was doing it wrong:

https://www.imperialviolet.org/2014/12/08/poodleagain.html

I think he eliminated them out of performance considerations. CBC is unparallelizeable by nature.

Reply on news.ycombinator.com