1

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
  • 3,925
  • 18
  • 56
  • 96
  • depending on the actual setup, it's possible to get partially readable plaintext, especially if the cyphertext got corrupted. e.g. a bit gets flipped somewhere at random, and anything after that flipped bit will come out as garbage, but everything before would be readable as expected. – Marc B Jan 13 '16 at 15:26
  • @MarcB So you're saying maybe the data was partially corrupted but I still don't understand how the decryption algorithm would be able to do anything with the data if it was not the original data. – Brian T Hannan Jan 13 '16 at 15:29
  • 1
    encryption/decryption is just a mathematical transform. numbers go in, numbers come out. they may not be the CORRECT numbers, but you still get a result. in fact, for arbitrary data the only way to detect if decryption was successful is to look for a known plaintext. if that plaintext doesn't show up in the decrypted text, you either have the wrong key, the ciphertext is corrupt, or the ciphertext isn't what you think it is. – Marc B Jan 13 '16 at 16:42

1 Answers1

1

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.

Ebbe M. Pedersen
  • 7,250
  • 3
  • 27
  • 47
  • Aha, this might be the clue into my issue. I'm using CBC mode so I will now check to make sure that the IV is set properly. – Brian T Hannan Jan 13 '16 at 15:55
  • And this clued me into my issue. There was extra \r \n characters from the original MTOM message that I was clearing out before decrypting the data but I wasn't taking that into account for the iv bytes. Once I made that adjustment then it worked like a charm. Thank you for cluing me in on the IV bytes!! – Brian T Hannan Jan 13 '16 at 16:48