Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
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
show 4 more comments

3 Answers

up vote 3 down vote accepted

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.

share|improve this answer
I'll add some links after this answer has been reviewed by the community... –  owlstead Aug 19 '13 at 20:55
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
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
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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