1
votes

I'm working on a problem with encrypted data transfer, where we get a "corrupted pad block" failure on decryption approx 1 in 200 times. The scheme is quite similar to encrypted emails (and designed for rather large amounts of data: up to one GB per unit):

  1. Generate random 256 bytes to use as session key.
  2. Encrypt the session key using the receiver's public key
  3. Encrypt data with CBC AES PKCS#7 padding, using the session key as key parameter for AES.

The receiver will then

  1. Decrypt the session key using his private key.
  2. Decrypt the data using the session key.

Now, on average approx 1 in 200 times, the random bytes will cause the data to be un-decryptable: we get "pad block corrupted" at the end of the decryption. The same byte sequence will either always work or always cause failure. It seems like the contents of the data to encrypt does not make any difference (but I still have some testing left in this area).

Any suggestions on how to avoid failure ?

1
We had similar randomly appearing "pad block corrupted" and the issue, as far as I can remember, was caused by generated keys starting with leading zeroes which were discarded by decryption process. Your case may be similar.Victor Sorokin
good suggestion. thanks. I'll find some failing keys and take a look.eirikma
Yup, check the IV as well, if you have any, and make sure your encoding is correct. Finally, make sure you receive all the data.Maarten Bodewes

1 Answers

1
votes

Yes, Victor Sorokin is right. Leading zeros in the session keys were dropped in the transfer.

The RSA encryption is a purely mathematical function, that will drop any leading zeros. When the session key is decrypted, one has to pad leading zeros back in so the key gets it original length and value back. There are padding schemes available, but they have to be employed on both sides.

The Bouncycastle FAQ adds some details, see question number 4 here: http://www.bouncycastle.org/wiki/display/JA1/Frequently+Asked+Questions