We are trying to decrypt a file sent to us that is using a newer key cipher and hash AES-256 & SHA2-256 and our public key.
When we get a small file of a few KB, we are able to decrypt, but when they send a larger file of few hundred KB, the file fails. they claim they are not doing anything different, and we have not had problems with others.
Using McAfee EBusiness Server on Unix..
Decoding data....
event 1: initial
event 13: BeginLex
event 8: Analyze
File is encrypted. event 9: Recipients
Secret key is required to read it.
Key for user ID "Dev Co. <[email protected]>"
event 6: Passphrase
event 23: Decryption
symmetric cipher used: 3DES
event 11: Output options
typecode: 0062
suggested name:
tempfile: created 'pgptemp.$0000'
event 11: Output options
typecode: 1000
suggested name:
tempfile: created 'pgptemp.$0001'
event 3: error -11443
event 2: final
Error decrypting file '.../processing/973160_IDRIN.txt.pgp'.
Corrupt data.
error decompressing data
exitcode = 32
Thoughts?
Do you have a more specific specifier for the cipher. E.g. AES256-CBC? And what is sha256 being used for, hmac? What Kind of padding are they using ?
The largest thing AES takes as input for an individual chunk is (other than the key) the block of data and thats 128bits. If your small amount of data was less than that, I'd say you had an issue with your chaining mode ( which is how you actually use a function which only deals with 128 bit chunks to encrypt something else). However, if a file of a few KB decrypts fine, this is not your issue.
What kind of padding are you using ? Its possible it encodes the length somewhere and they are overflowing it. However, off the top of my head I can think of no padding scheme that would do that. Certain message authentication codes (MACs) will encode length ( .e.g CBC mac).
My best guess, though, is that there is a bug in how you are handling the files, not the crypto it self, and something somewhere is getting truncated. Without any details on what they are using for encryption though, its hard to say .