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

Popular posts from this blog

python - Scipy curvefit RuntimeError:Optimal parameters not found: Number of calls to function has reached maxfev = 1000 -

c# - How to add a new treeview at the selected node? -

java - netbeans "Please wait - classpath scanning in progress..." -