AES decryption in iOS: PKCS5 padding and CBC -
i implementing ios decryption code message originating on server on have no control. previous implementation on platform documents decryption requirements aes256, specifies key , initialization vector, , says:
* cipher mode: cbc * padding: pkcs5padding
the options creation of cccryptor object include kccoptionpkcs7padding , kccoptionecbmode, noting cbc default. what understand padding encryption, don't understand how 1 might use both; thought mutually exclusive. in creating cccryptor decryption, have tried using both 0 options , kccoptionpkcs7padding, both give me gibberish after decryption.
i have compared dump of decryption dump of decoded byte buffer on other platform , confirmed different. there doing different in implementation different, don't know what... , don't have clue how handle on it. platforms different enough difficult infer previous implementation because based on different platform. , of course, author of previous implementation has since departed.
any guesses else incompatible or how troubleshoot thing?
pkcs#5 padding , pkcs#7 padding practically same (adding bytes 01, or 0202, or 0303 etc length of block size of algorithm, 16 bytes in case). officially pkcs#5 padding should used 8 byte blocks, in many runtimes 2 can interchanged without issue. padding occurs @ end of ciphertext, if gibberish it's not padding. ecb block mode of operation (that should not used encrypt data can distinguished random numbers) : require padding, 2 not mutually exclusive.
finally, if perform decryption (not mac'ing or other forms of integrity control), , return result of unpadding server (decryption failed), plain text data not safe because of padding oracle attacks.
Comments
Post a Comment