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.

Brian T Hannan
  • 155
  • 4
  • 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 '16 at 16:24

2 Answers2

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

mittmemo
  • 163
  • 5
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.

sethmlarson
  • 1,479
  • 10
  • 17
  • Good suggestion but I'm using PKCS5 padding which the owner of the web service verified is correct. – Brian T Hannan Jan 13 '16 at 16:18
  • @BrianTHannan My other suggestion would be that the 16 bytes you're seeing at the beginning is a random [nonce](https://en.wikipedia.org/wiki/Cryptographic_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 '16 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 '16 at 16:49