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?
java spring spring-boot encryption aes
asked Nov 21 '18 at 9:43
idipousidipous
2,18011929
|
show 2 more comments
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?
java spring spring-boot encryption aes
asked Nov 21 '18 at 9:43
idipousidipous
2,18011929
The IV does not have to be secret so you can share it along with the ciphertext. For more info check here: security.stackexchange.com/questions/17044/…
– iakovos Gurulian
Nov 21 '18 at 9: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
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.
– James K Polk
Nov 21 '18 at 14:51
|
show 2 more comments
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?
java spring spring-boot encryption aes
asked Nov 21 '18 at 9:43
idipousidipous
2,18011929
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?
java spring spring-boot encryption aes
java spring spring-boot encryption aes
asked Nov 21 '18 at 9:43
idipousidipous
2,18011929
asked Nov 21 '18 at 9:43
idipousidipous
2,18011929
asked Nov 21 '18 at 9:43
idipousidipous
2,18011929
asked Nov 21 '18 at 9:43
idipousidipous
2,18011929
asked Nov 21 '18 at 9:43
idipousidipous
2,18011929
2,18011929
The IV does not have to be secret so you can share it along with the ciphertext. For more info check here: security.stackexchange.com/questions/17044/…
– iakovos Gurulian
Nov 21 '18 at 9: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
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.
– James K Polk
Nov 21 '18 at 14:51
|
show 2 more comments
The IV does not have to be secret so you can share it along with the ciphertext. For more info check here: security.stackexchange.com/questions/17044/…
– iakovos Gurulian
Nov 21 '18 at 9: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
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.
– James K Polk
Nov 21 '18 at 14:51
The IV does not have to be secret so you can share it along with the ciphertext. For more info check here: security.stackexchange.com/questions/17044/…
– iakovos Gurulian
Nov 21 '18 at 9:58
The IV does not have to be secret so you can share it along with the ciphertext. For more info check here: security.stackexchange.com/questions/17044/…
– iakovos Gurulian
Nov 21 '18 at 9: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
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
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
Because the client is a big company that cannot handle anything other than what they are expecting...
– idipous
Nov 21 '18 at 14:08
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.
– James K Polk
Nov 21 '18 at 14:51
The client never has to handle or know of the existence of the IV -- only your software does.
– James K Polk
Nov 21 '18 at 14:51
|
show 2 more comments
2 Answers
2
active
oldest
votes
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.
answered Nov 21 '18 at 14:45
kelalakakelalaka
1,59021225
add a comment |
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.
answered Nov 21 '18 at 15:14
Saptarshi BasuSaptarshi Basu
2,04421627
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53409163%2faes-share-only-the-key-no-salt-or-iv%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Nov 21 '18 at 14:45
kelalakakelalaka
1,59021225
add a comment |
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.
answered Nov 21 '18 at 14:45
kelalakakelalaka
1,59021225
add a comment |
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.
answered Nov 21 '18 at 14:45
kelalakakelalaka
1,59021225
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.
answered Nov 21 '18 at 14:45
kelalakakelalaka
1,59021225
answered Nov 21 '18 at 14:45
kelalakakelalaka
1,59021225
answered Nov 21 '18 at 14:45
kelalakakelalaka
1,59021225
answered Nov 21 '18 at 14:45
kelalakakelalaka
1,59021225
1,59021225
add a comment |
add a comment |
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.
answered Nov 21 '18 at 15:14
Saptarshi BasuSaptarshi Basu
2,04421627
add a comment |
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.
answered Nov 21 '18 at 15:14
Saptarshi BasuSaptarshi Basu
2,04421627
add a comment |
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.
answered Nov 21 '18 at 15:14
Saptarshi BasuSaptarshi Basu
2,04421627
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.
answered Nov 21 '18 at 15:14
Saptarshi BasuSaptarshi Basu
2,04421627
edited Nov 22 '18 at 14:56
answered Nov 21 '18 at 15:14
Saptarshi BasuSaptarshi Basu
2,04421627
answered Nov 21 '18 at 15:14
Saptarshi BasuSaptarshi Basu
2,04421627
answered Nov 21 '18 at 15:14
Saptarshi BasuSaptarshi Basu
2,04421627
2,04421627
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53409163%2faes-share-only-the-key-no-salt-or-iv%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The IV does not have to be secret so you can share it along with the ciphertext. For more info check here: security.stackexchange.com/questions/17044/…
– iakovos Gurulian
Nov 21 '18 at 9: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
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.
– James K Polk
Nov 21 '18 at 14:51