6

For Encryption in Java... the article at http://cwe.mitre.org/data/definitions/329.html states that the Initialization Vector should be different each time, but if I use a different IV to decrypt than the one I used to encrypt, I get garbage characters instead of the data I expected.

What is the proper way to encrypt on one server and decrypt on another without having to communicate the IV back and forth in between servers?

The common technique seems to be to hardcode a byte array, but supposedly that's insecure???

Michael Akerman
  • 309
  • 2
  • 7
  • 1
    You misunderstood the article. The IV should be different for each encrypted message, but you must use the same IV to decrypt a given message that was used to encrypt it. See Jon Skeet's answer below. – President James K. Polk Sep 01 '11 at 21:02

2 Answers2

12

I believe an IV is like a salt - it's not a secret, it's just used to introduce an extra element of randomness so that the same message encrypted with the same key still comes out differently each time.

So you can transmit the IV used to encrypt as part of the encrypted value, just like you'd store the salt along with a hash for a hashed value.

Of course, I could be completely incorrect...

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 4
    This is correct, the IV is XOR'd with the first block of plain text, then encrypted with the key. The remaining blocks are XOR'd with the previous block. This is called Cipher Block Chaining (CBC). You must decrypt with the same IV you used to encrypt. It is not a secret, and can be sent/stored plain. You should randomly generate a new IV each time you encrypt data. Its purpose is to add randomness to the encrypted data, so the same data, encrypted with the same key, will produce a different cipher text. – Petey B Sep 01 '11 at 20:38
  • suppose if the server encrypt the plaintext, the server has to send the encrypted text along with the IV to the client? And can IV be sent as it is, as a plain text? – OnePunchMan Jan 28 '15 at 07:46
  • 1
    @kaze: It's not clear what scenario you're talking about - but yes, you can send the IV as plain text. – Jon Skeet Jan 28 '15 at 08:17
  • 1
    Since IV is used during encryption(at server side) and the same IV is again used for decryption of that message(at the client side). So, the server need to send both the encrypted message and the IV used to encrypt that message to the client. If my understanding is correct, is there any harm in security by sending IV as a plain text to the client (as we know how CBC is done)? – OnePunchMan Jan 28 '15 at 09:28
  • @kaze: Again, no, that's fine. – Jon Skeet Jan 28 '15 at 09:41
0

you have to add the information that you want to avoid, inside the encrypted data, which is an array of bytes, and then removing during the conversation.

the IvParameterSpec is based on fixed array, so you know the length of the part to add and to remove. The removed part is used to recreate the parameters you pass during the chypher initialization.

please have a look at this class I created:

https://github.com/spannozzo/tk-integration/blob/master/tk-integration-util/src/main/java/org/acme/util/AESUtil.java

Salvatore Pannozzo Capodiferro
  • 1,121
  • 12
  • 20
  • The linked utility doesn't handle the password securely. An accepted password-based key derivation algorithm like PBKDF2 uses a work factor, a significant computational cost, when generating a key from a password. – erickson Aug 25 '22 at 21:22
  • Hi, thanks for your comment. Actually using the same password it will allow you to decrypt, otherwise could you suggest another method? I'm agree with you about the password handling, but that can be done with env. variable at runtime. Here I was more focused on solving the problem of the iv parameter spec – Salvatore Pannozzo Capodiferro Aug 27 '22 at 10:45