Search code examples
javaspringspring-bootencryptionaes

AES share only the key (no salt or IV)

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?

Solution

  • 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.