Based on a lot of reading here on crypto.stackexchange.com and around the web, it seems like AES in CBC Mode is totally unsecure if no defense is provided for oracle padding attack. And it’s not just AES, any crypto algorithm that uses CBC mode is totally unsecure if no defense is provided for padding oracle attacks. There are even step by step videos of how to recover plain text from CBC mode ciphers. https://www.youtube.com/watch?v=aH4DENMN_O4

All of this kinda blows my mind though given that Wikipedia says that the original padding oracle attack was published in 2002 https://en.wikipedia.org/wiki/Padding_oracle_attack If that is the case, how can it be that AES256CBC is often touted as strong modern encryption without mentioning that implementations lacking proper HMAC validation (Encrypt-Then-MAC), or some other padding oracle defense, are actually not secure at all? It kinda blows my mind if I’m understanding this correctly. Am I understanding this correctly?

  • 2
    $\begingroup$ Because in principle AES-256-CBC can be implemented securely if you know what you have to look out for? $\endgroup$
    – SEJPM
    Feb 21, 2017 at 15:36
  • 5
    $\begingroup$ @SEJPM I don't agree with you. By default, encryption should be authenticated encryption, unless you are sure that you don't need it. $\endgroup$ Feb 21, 2017 at 16:16
  • 2
    $\begingroup$ I would say that somebody is doing their research very wrong if they take @MaartenBodewes' narrow answer to that narrow question you link, and extrapolate therefrom that unauthenticated CBC is safe to use in all or even most applications. When people ask narrow questions about how to use CBC correctly to achieve the security properties that it does offer (confidentiality, but not authenticity), the answers will often be narrow, because we just cannot turn every Q&A into a fresh reminder of the perils of unauthenticated encryption. $\endgroup$ Feb 21, 2017 at 22:42
  • 3
    $\begingroup$ Ron, CBC is secure against chosen plaintext attacks but neither against chosen ciphertexts nor padding oracles. This is the problem with your absolutist assertion that CBC is "insecure"—the fact of the matter is that it's secure against some attacks but not others, and to evaluate the security of protocols that use CBC we need to state those properties precisely. "CBC is totally insecure" can be read charitably as an informal (and wise!) recommendation not to use CBC, but it's false if taken as a precise technical statement like we often prefer around here. $\endgroup$ Feb 22, 2017 at 1:23
  • 2
    $\begingroup$ @RonC But we can add a comment to warn unsuspecting users. Unsuspecting users of CBC mode for transport security (and similar use cases) probably have a lot of other things to think about though (and just choosing an authenticated cipher wont result in a secure system, an uninformed user has about a 0% chance of getting transport security right - with or without authentication tag) $\endgroup$ Feb 22, 2017 at 1:51

1 Answer 1


The cryptographic community moves very slowly. Take MD5 security for example. A design flaw was first published in 1996 and a collision (with more design flaws) found in 2004. Yet in 2012, authors of the Flame malware were able to use an MD5 collision to forge a Windows code-signing certificate. And we still hear of password-hash dumps that use MD5 today.

how can it be that AES256CBC is often touted as strong modern encryption without mentioning that implementations lacking proper HMAC validation (Encrypt-Then-MAC), or some other padding oracle defense, are actually not secure at all?

This is definitely the way the community is going. I haven't done the analysis, but I'd guess that most TLS/SSL connections these days are using integrity protection (either HMAC or an AEAD mode). Integrity protection is one of the first things that gets mentioned to people on Crypto.SE too when they propose something that doesn't use it.

Something to remember is that padding-oracle attack is an online attack and very noisy. So there are a lot of use cases of cryptography where it simply does not apply. I agree with your sentiment, however. Authenticated encryption should be the default. We are getting there, but it is taking time.

  • 1
    $\begingroup$ Evaluating new cryptographic algorithms is a hard process that is best done by a community over a long time period, so moving slowly is very understandable. Still, given the number of web developers out there that depend on encryption, and have access to modern development libraries that provide CBC based encryption objects that don't include MAC validation, it seems like there is an important message that needs to reach web developers: CBC Mode Encryption is totally unsecure if not paired with a MAC of some kind, preferably HMAC via an Encrypt-Then-Mac approach. $\endgroup$
    – RonC
    Feb 21, 2017 at 16:29
  • 3
    $\begingroup$ @RonC, agreed. But how many of those web developers are also using SHA-1 (hopefully none are still on MD5)? We'll get there eventually. $\endgroup$
    – mikeazo
    Feb 21, 2017 at 16: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.