4

I have a requirement to encrypt with AES -symmetric- a string and then share the encrypted string with a client.

They know the key (we have communicated over the phone) and they should be able to decipher the encrypted string.

However the Java implementations I have found all require to share the salt (or IV) along with the encrypted document. This defeats the purpose of sharing only the cipher text and a symmetric key (before hand) if I somehow have to send the salt every time.

Am I understanding something wrong? Is there a way to share only the cipher text and the symmetric key?

idipous
  • 2,868
  • 3
  • 30
  • 45
  • The IV does not have to be secret so you can share it along with the ciphertext. For more info check here: https://security.stackexchange.com/questions/17044/when-using-aes-and-cbc-is-it-necessary-to-keep-the-iv-secret – Iakovos Nov 21 '18 at 09:58
  • Can you explain why sending an IV is such an issue to you? It's not a secret value. – Luke Joshua Park Nov 21 '18 at 10:00
  • The IV is unique for each message, and thus logically follows the message. Usually you would incorporate the IV in the message, eg prefixing the encrypted message with it. The IV don't need to be secret, but it do need to be random. – Ebbe M. Pedersen Nov 21 '18 at 11:09
  • 1
    Because the client is a big company that cannot handle anything other than what they are expecting... – idipous Nov 21 '18 at 14:08
  • The client never has to handle or know of the existence of the IV -- only your software does. – President James K. Polk Nov 21 '18 at 14:51
  • @JamesKPolk if they need to decrypt the cipher text using the key we have shared won't they need the IV – idipous Nov 22 '18 at 06:57
  • I think what @JamesKPolk meant is you don't share the IV the way you share the key. The key is a secret, IV is not. Key remains same for many encrypted messages, IV changes for every encrypted message. Hence the IV is shared as a part of the cipher text. To a common man your encrypted output is just a single string, but to your decryption logic that string contains both IV and the cipher text. – Saptarshi Basu Nov 22 '18 at 10:58

2 Answers2

2

The purpose of the IV in encryption is randomization. If you use ECB mode of operation, it can leak information about the ciphertexts that are encrypted under the same key. See the famous penguin in Wikipedia mode of operations.

E(k,m) = E(k,m') iff m=m'

The modern modes of operation use IV, as AES-GCM which is in TLS 1.3 cipher suites.

You should tell the big company about the danger. I'm pretty sure that they can easily adapt to your case very easily.

Note: ECB mode can only be safe, if

  • your data is always different (no pattern)
  • you generate a new key for every encryption with a key agreement protocol as Diffie-Hellman key exchange, and this is not your case.
kelalaka
  • 5,064
  • 5
  • 27
  • 44
2

Usually the IV is shared by appending it to the cipher text. So, eventually you are sending a single Base64 encoded string.

So, if you are worried about breaking a contract by sending two fields (one IV and one cipher text) instead of sending just one field, let me assure you that you're going to send a single field only. And the decryption logic knows how to extract the IV from the received string and use it in the decryption process.

Note that there are some key distinctions between IV and key:

  • Key is a secret, IV is not
  • Many messages can be encrypted with the same key, but IV is different for every new message. The key and IV combination has to be unique for every message and the IV also has to be random

Therefore, you do not share IV the same way as key. Since IV changes for every message, it is actually appended with the cipher text to form a single string which is then sent as the encrypted output. So, the decryption logic takes as input only the key and your encrypted output; it knows how to extract the IV and the cipher text from the encrypted output.

On today's date if anyone needs to encrypt something using AES, the usual choice is an authenticated encryption mode like GCM which provides not only confidentiality but also integrity in a secured way.

Unless the recipient (in your case) is rigidly specifying a particular mode for AES, the default choice would always be AES with GCM. And even if the recipient proposes some mode that is not an authenticated encryption mode, you may consider explaining to them the benefits of using authenticated encryption mode.

You'll find a complete java implementation with detailed explanation here.

You may also want to read this along with the comments to understand it better.

Saptarshi Basu
  • 8,640
  • 4
  • 39
  • 58