0
$\begingroup$

Given that CBC mode encryption is vulnerable to padding oracle attacks, what is the next best alternative ?

a) Include a hash check in the API scheme, validate the hash and then proceed with CBC. If hash check fails then return error indicating same. Eg: Include HMACSHA256(AES256(plaintext)) checksum that is required to be validated as part of message.

b) Implement a custom CBC mode that include a hmac/equivalent checksum at the end of each encryption block (on the lines of padding). Eg: Create own scheme on the lines of - "AES/CBC/PKCS5Padding/HMACSHA256". Are there any plans drafted by NIST / W3C to incorporate such a scheme?

c) Switch to GCM mode encryption. How does it compare to CBC in terms of cryptographic strength?

Improve this question
$\endgroup$
1

1 Answer 1

Reset to default
3
$\begingroup$

GCM is a very good alternative, it provides built in message authentication, so encrypted messages can not be manipulated by an attacker.

The encryption itself is based on CTR mode which is well understood and is secure when used correctly.

Main thing to notice is the severity of nonce reuse, reusing a counter value with the same key is catastrophic, be sure you use GCM correctly and you will be fine.

Improve this answer
$\endgroup$
6
  • $\begingroup$ GCM-SIV (or just SIV) mode doesn't lose security catastrophicly when a nonce is re-used with the same key, but it's 2-pass. OCB is now patent-free and faster than GCM. $\endgroup$
    – SAI Peregrinus
    May 14, 2022 at 17:30
  • $\begingroup$ Believe had come across the 'nonce' requirement once before (although could not recollect while framing the question) and consequently hesitant to adopt GCM. Having NIST come up with a mode that involves CBC with checksum still seems the better option. But guess until then we'll have to trust the GCM implementations in libraries. $\endgroup$
    – Ravindra HV
    May 14, 2022 at 18:50
  • $\begingroup$ After multiple padding attacks, people are simply mooving away from CBC, though we have some CBC based implemntaitions we don't currently know how to attack effectively moving away from where we burned multiple times seems safer. $\endgroup$
    – Meir Maor
    May 14, 2022 at 19:13
  • $\begingroup$ Guess moving away from CBC is natural. But adopting GCM with the terms-and-conditions involves appears just as risky (in the long-run). Guarding CBC with an integrity check (eg: application-layer / extended-cbc-scheme-with-integrity-check) seems to be more straightforward than have the possibility of some reused nonce based vulnerability show up in some library every now and then. Source code may not always be available for scrutiny in case of GCM or it could be overlooked. $\endgroup$
    – Ravindra HV
    May 15, 2022 at 15:47
  • $\begingroup$ Given the complications, I guess we could consider CBCas a known enemy and GCM as an unknown friend. $\endgroup$
    – Ravindra HV
    May 15, 2022 at 16:00

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.