4

I'm decrypting some data using Java and Apache's most recent WSS4J library with 128-bit AES decryption.

I setup the the cipher which appears to be correct with the right padding, decryption algorithm, and cipher block mode.

I then make a call to doFinal() on the encrypted data bytes and it successfully returns a value.

My question is would it ever return a value that is only partially decrypted?

For example, let's say the first 16 bytes are still jumbled up after decryption, but the remainder of the data returned has been successfully decrypted, and is human-readable with the expected data there.

Would this mean that there could be an issue with my decryption process? Or would it not even be able to return a value from the doFinal() step if something was even slightly off with the decryption setup?

If I get a value returned from doFinal() would that mean that 100% the data returned is the original data before it was encrypted?

I'm decrypting data from a web service call and the owners of the web service are claiming that I must be doing something wrong during my decryption process and that they are sending the data correctly.

Improve this question
1
  • 4
    Depending on the block mode you are using, you can get partially decrypted data. For example, in CBC mode, if an incorrect IV is supplied, the first block of data will not decrypt properly. However, the rest of the data will decrypt successfully (assuming you are using the correct encryption key). This is because the IV of block (x + 1) is the ciphertext of block x. EDIT: Re-reading your description of the first 16 bytes being "jumbled" after decryption, this sounds like what is happening.
    – mittmemo
    Jan 13, 2016 at 16:24

2 Answers 2

Reset to default
5

Depending on the block mode you are using, you can get partially decrypted data. For example, in CBC mode, if an incorrect IV is supplied, the first block of data will not decrypt properly. However, the rest of the data will decrypt successfully (assuming you are using the correct encryption key). This is because the IV of block (x + 1) is the ciphertext of block x.

Wikipedia's diagram is pretty helpful in visualizing this.

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29

enter image description here

Improve this answer
0
2

Some encryption algorithms require padding to ensure that the content is a size that is a multiple of the block size that the encryption algorithm intends to use. If your decryption process does not handle this padding, then it is possible to see in the result of the decryption there still garbled bytes appended to your decrypted message. Typically this padding occurs on the left side of the message, and to get back the original plaintext you should follow a method that reverses how the padding was appended in the first place. Read more on cryptographic padding.

Improve this answer
3
  • Good suggestion but I'm using PKCS5 padding which the owner of the web service verified is correct.
    – Brian T Hannan
    Jan 13, 2016 at 16:18
  • @BrianTHannan My other suggestion would be that the 16 bytes you're seeing at the beginning is a random nonce value to ensure that similar messages don't end up having the same ciphertext in which case you can simply remove the first 16 bytes of every message.
    – sethmlarson
    Jan 13, 2016 at 16:20
  • 2
    It wasn't that. I figured it out thanks to StackOverflow. Yes, that is possible. A prime example would be if you try to decrypt something in CBC mode with the wrong Initialization Vector (IV). That would result in the first part decrypted to be invalid. This is due to how the IV is XORed to the first block of plaintext in CBC mode. My IV bytes were incorrect and they clued in on looking at that.
    – Brian T Hannan
    Jan 13, 2016 at 16:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .