Padding oracles and the decline of CBC-mode cipher suites | Hacker News Reader

Padding oracles and the decline of CBC-mode cipher suites

blog.cloudflare.com

63 pointscarey9 comments

This is a good overview, worth reading. I have some nits.

* This isn't a legit criticism of the article, but: it drives me nuts when people suggest the big problem with ECB is that you can see penguins through it. The reason ECB penguins are see-through is that ECB isn't semantically secure. The bigger problem with this trait is that you can usually decrypt ECB altogether without a key!. A really thorough understanding of how ECB breaks down is hugely helpful to understanding the TLS flaws. Enough with the penguins!

http://cryptopals.com/sets/2/challenges/12/

* Timing-driven padding oracles predate Lucky 13; the person who more or less taught me crypto told me about them back in 2009. Again, not a super legit criticism of the article, but worth knowing.

* There are other error side channel attacks besides padding oracles, and some of them affect modes other than CBC.

* CBC mode is in decline, but the article is kind of incoherent about why, or whether that's a good thing. "CBC is OK for static content" is a recommendation that doesn't make any sense to me at all. CTR and derivatives will eat CBC entirely over the long run: CTR is simpler than CBC (it has minimal format constraints), only requires the encryption transform, and is marginally easier to implement faster.

* What's really in decline is generic composition cryptosystems, where encryption and authentication are specified independently. Most of the last 10 years of TLS bugs stem from TLS being specified before the industry understood the central role of authentication in secure cryptosystems. For a good example of this, look at POODLE, which is an attack made possible by an idiosyncratic CBC that uses nondeterministic padding that can't be reliably authenticated.

He said "the first padding oracle attack was demonstrated in 2002". Do you mean he's wrong about that?

How is this about CBC and not exclusively about MAC-then-encrypt? Wouldn't CBC be fine in a MAC'd ciphertext protocol?

You still need to ensure that the IV is unpredictable, even if the ciphertext is authenticated, but then you still need to make sure CTR (or GCM) nonces are unique, so that nets out.

I do not know of any attacks against encrypt-then-MAC CBC-mode but I believe at least part of the rationale behind the migration away from CBC-mode is due to increased complexity of decryption. With CBC-mode decryption I have at least one extra step (validating padding), which as the blog post mentions has been troublesome.

I wonder about SSLv2's MAC which is basically MAC-then-encrypt with secret prefix MD5 with the CBC padding included in the MD5.

This is a fantastic writeup covering a large amount of cryptography, both in and outside the context of the web. Reading about all of this summarized in a practical context including all of the real-world nasties like ARP spoofing is both great, and double-great for getting a feel about why utterances like "hm, this should be okay given this circumstance" should always put fear in your heart when talking about security.

Also, wow, I'd never seen that link to The Cryptographic Doom principle before, despite trying to elucidate that concept before myself (badly). That's a fantastic bookmark to keep for inclusion in explanations on tickets filed against dubious crypto.

Likewise, this link is going in my bookmarks for immediate deployment when I need a litany of padding oracles and timing attacks to explain why indistinguishability is essential to a friend. Thanks, author!

I wonder who's still using browsers that only accept 3DES?

Companies. Unfortunately, there are still plenty of corporate environments with machines using XP, and 3DES is usually kept on to support those.

Reply on news.ycombinator.com