# Can padding length, and thus plaintext length, be considered public information when using aes-cbc?

Right now I'm using a simple padding system that takes the plaintext, hashes it with SHA512, and appends $x$ bytes of the hash as padding where $x$ is the delta between the plaintext and nearest blocksize multiple.

Is this considered a secure method of padding the message? I am also authenticating the encrypted data using HMAC-SHA512, would this effect the security?

-
Are you also sending the value 'x' to the receiver? Is that what you're asking? – poncho Aug 13 '13 at 20:32
Yes, I am. I should've mentioned that padding length is a single byte in a ciphertext that looks like this:nonce | iv | cipherText | paddingeLegnth | HMAC – Everlag Aug 13 '13 at 20:39
Why not make $x$ part of the plaintext? By sending it in the clear you reveal information about your plaintext when it can be avoided. – rath Aug 13 '13 at 22:09
Whether or not this introduces a vulnerability, you should instead use a standard, vetted padding scheme for CBC mode. PKCS7 is widely-used and considered secure. – pg1989 Aug 13 '13 at 23:28
What's really important is that you compute a MAC over the whole ciphertext (not plaintext), including padding and IV. Attempting to authenticate the plaintext is a bad idea with CBC mode, you really need to authenticate the ciphertext with a proper MAC. – CodesInChaos Aug 14 '13 at 7:33

The size of the padding could be made public, if you don't mind leaking some additional information about the plaintext size. Using a hash as padding bytes however does not make sense; you can not use the hash as authentication tag or to check the integrity, so the hash calculation becomes spurious. It may even leak data through a side channel. In the best case it simply eats CPU resources without accomplishing anything.

It is better to use a vetted padding method such as PKCS#7 or bit padding. They may use a block of ciphertext more, but otherwise the implementation light on resources. Both padding methods are however vulnerable to padding oracle attacks. So you should generate a MAC or HMAC (using a second key) over the ciphertext. You should include all public information in the MAC calculation as well.

Alternatively you could use zero byte padding and a padding or plain text length indicator byte as this may save you a block of bytes to encrypt. In that case you should definitely include the length indicator in the MAC calculation as an attacker could otherwise fool you into adding or removing bytes from the plain text by simply changing the length indicator.

Finally you could of course use a block cipher in counter mode, possibly using an authenticated scheme such as GCM. This would rid you of padding altogether (the plaintext size is the ciphertext size) and would generate a message authentication tag without having to resort to two separate keys. As in the MAC calculation you should include all public data as additional authenticated data (AAD). Furthermore, you should be sure never to repeat the nonce/IV. You would not need a separate nonce and IV either.

-
I'll add some links after this answer has been reviewed by the community... – Maarten Bodewes Aug 19 '13 at 20:55

For AES CBC i would suggest you stick to the standards.

The PKCS7 padding scheme is pretty easy to implement and has been tested extensively now that its been out in the public for a while. I had implemented PKCS7 padding for my AES CBC cipher a few weeks ago and you can see the code here if it helps.

Note that hashing by itself does not provide you with authentication, you will need a MAC (Message Authentication Code) for that. If you like using the SHA family, you can use something like HMAC-SHA256.

Is there any particular reason why you wish to use hashed data as a pad? If you are looking for authenticated encryption, you should stick to the standards like GCM for AES.

-

You should use a vetted padding scheme. Unfortunately PKCS#7 is not the right one (search for "pkcs7 vulnerability").

It seems that ISO.2FIEC_7816-4 isn't vulnerable.

-
A reference would be more helpful than “you figure out what I'm talking about”. Are you refering to the Bleichenbacher attack? Could you explain why ISO.2FIEC_7816-4 is better than PKCS#7? – Gilles Sep 27 '13 at 12:09
Colin Percival recommends using AES in CTR mode, completely bypassing the padding issues with CBC. – Teris Riel Sep 27 '13 at 13:08
Kenneth G. Paterson; Gaven J. Watson (2008). "Immunising CBC Mode Against Padding Oracle Attacks: A Formal Security Treatment". Security and Cryptography for Networks – SCN 2008, Lecture Notes in Computer Science (Springer Verlag) (5229): 340–357. cited in Wikipedia:Block cipher No, I haven't read the paper. I am (perhaps foolishly) assuming the Wikipedia article is correct. – Teris Riel Sep 27 '13 at 13:16