Cryptography
aes cbc padding compression padding-oracle
Updated Wed, 01 Jun 2022 08:00:40 GMT

Is it safe to use GZIP to avoid padding related attacks


I am designing a library that supports encrypting some in-memory data using AES in CBC mode. Now I need a padding but it seemed to me that Apple's CommonCrypto library and OpenSSL have different padding schemes but I want to retain interoperability even when mixing CommonCrypto implementation and OpenSSL ones. (My library should work under Linux which have only OpenSSL, iOS which have only CommonCrypto and OS X which have both.)

Given that my library already have gzip and gzip archives can still be unarchived with any byte string concatenated after it, I am considering this padding scheme:

  1. Gzip the incoming data.
  2. Concatenate this archive with random bytes to bring the length up to AES block boundary.

When decrypting, the gzip algorithm will automatically discard the appended random bytes.

Solution

You are basically using gzip to convey the length of the given message. As long as your implementation of AES-CBC is secure (e.g. by using a random IV) then the given scheme should be secure against padding oracle attacks. This is easy to prove as there is nothing that removes the padding from the plaintext.

CBC padding in general does not add any security to the block cipher mode. You could just pad with zero bytes if you already know the size of the plaintext. In that sense the scheme is safe as long as no information is leaked to an attacker after decryption. Note that using gzip may influence the size of the plaintext so you need to make sure an attacker cannot learn too much from the size of the ciphertext.

Your scheme is therefore safe if the attacker only has access to the ciphertext. In that case it does provide confidentiality.

So now for the bad news...

This does not mean that the data within the ciphertext container cannot be altered. As there is no cryptographically secure authentication tag present, an attacker could very well be able to change the ciphertext in a way that cannot be detected. So the application code that processes the decrypted data could still be fooled to leak information about the plain text.

In other words, although you have now successfully protected against padding oracle attacks, you haven't protected yourself against similar, active attacks on the ciphertext. Please add some kind of secure authentication tag. It is by far the best way to protect yourself against these kinds of active attacks.

Comments (4)

  • +0 – I do have MAC (SHA512-HMAC of ciphertext) but it is implemented on a container level. (I cannot let the cipher text out simply) — Sep 22, 2013 at 16:01  
  • +1 – OK, but the simple fact is that if you want to protect against active attacks (such as padding oracle attacks) then you need to add an authentication tag. If you don't want to protect against those, then there is no need to protect against padding oracle attacks and your scheme would not have any security benefits. It would not be less secure than CBC with a normal padding mode either. It could influence attacks that use the ciphertext size. — Sep 22, 2013 at 16:04  
  • +1 – Padding oracles are just one example of a larger class of attacks where the decrypter leaks information about the plaintext. I bet that gzip by itself is already enough of an oracle, with similar capabilities as a padding oracle. — Sep 23, 2013 at 08:46  
  • +0 – @CodesInChaos Um I covered the magic numbers in fixed locations with random numbers. — Sep 26, 2013 at 14:31  

References