0

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?

Ravindra HV
  • 204
  • 6
  • 13

1 Answers1

3

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.

Meir Maor
  • 11,835
  • 1
  • 23
  • 54
  • 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. – SAI Peregrinus May 14 '22 at 17:30
  • 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. – Ravindra HV May 14 '22 at 18:50
  • 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. – Meir Maor May 14 '22 at 19:13
  • 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. – Ravindra HV May 15 '22 at 15:47
  • Given the complications, I guess we could consider CBCas a known enemy and GCM as an unknown friend. – Ravindra HV May 15 '22 at 16:00
  • TLS1.3 ditched CBC, and I think it was a wise choice. – Meir Maor May 15 '22 at 16:33