2
$\begingroup$

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.

Improve this question
$\endgroup$
6
  • 2
    $\begingroup$ 1) I'd use a deterministic padding scheme 2) It's essential to apply a MAC after encryption. Else active attacks, like padding oracles will break it. $\endgroup$
    – CodesInChaos
    Commented Sep 20, 2013 at 16:32
  • $\begingroup$ @CodesInChaos Umm I think this padding itself is somewhat resistant to padding oracles - gzip itself is not deterministic and the padding is totally random. (gzip have some internal structure to determine the end of file, so appending bytes after it does not break it.) $\endgroup$
    – Maxthon Chan
    Commented Sep 20, 2013 at 17:33
  • $\begingroup$ If you simply ignore the padding then you may as well just append zeros. No need to use a random generator, unless you want to protect against other developers that would add padding checks at a later timeframe (document!). But check my answer before you do this. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 22, 2013 at 15:50
  • 1
    $\begingroup$ Doubt any comments from CodesInChaos at your own peril. Personally I would think thrice before doing so. They are more or less compressed answers. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 22, 2013 at 15:54
  • 3
    $\begingroup$ @MaxthonChan: the gzip format supports for generic concatenation: if you take two gzip-encrypted files and concatenate then, then you obtain a valid gzip stream which decompresses to the concatenation of both uncompressed files. Therefore it is not really true that gzip "automatically discards the appended random bytes". Maybe you think of zlib, which uses the same compression algorithm (Deflate) but does not support concatenation ? $\endgroup$
    – Thomas Pornin
    Commented Sep 24, 2013 at 17:29

1 Answer 1

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ I do have MAC (SHA512-HMAC of ciphertext) but it is implemented on a container level. (I cannot let the cipher text out simply) $\endgroup$
    – Maxthon Chan
    Commented Sep 22, 2013 at 16:01
  • 1
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 22, 2013 at 16:04
  • 1
    $\begingroup$ 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. $\endgroup$
    – CodesInChaos
    Commented Sep 23, 2013 at 8:46
  • $\begingroup$ @CodesInChaos Um I covered the magic numbers in fixed locations with random numbers. $\endgroup$
    – Maxthon Chan
    Commented Sep 26, 2013 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.