Score:0

Crypto

Alternative to CBC mode encryption?

Ravindra HV

9/14/23, 11:31 AM

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?

0 + 0

encryption

cbc

padding-oracle

nist

kelalaka

9/14/23, 9:41 PM

The guide to GCM is here; [What are the rules for using AES-GCM correctly?](https://crypto.stackexchange.com/q/84357/18298)

Score:3

Crypto

Meir Maor

9/14/23, 11:53 AM

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.

0 + 0

SAI Peregrinus

9/14/23, 5:30 PM

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.

Ravindra HV

9/14/23, 6:50 PM

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.

Meir Maor

9/14/23, 7:13 PM

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.

Ravindra HV

9/15/23, 3:47 PM

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

9/15/23, 4:00 PM

Given the complications, I guess we could consider `CBC`as a known enemy and `GCM` as an unknown friend.

Meir Maor

9/15/23, 4:33 PM