Do AEADs also authenticate the nonce?
Clash Royale CLAN TAG#URR8PPP
I'd like to include an authenticated timestamp in my messages. I'm wondering if I can save a little space by putting the timestamp in the nonce.
Concrete example:
- Let's say I'm using XChaCha20-Poly1305 with a shared secret key.
- I generate the nonce/IV by concatenating an 8-byte timestamp and a 16-byte random value.
- I send
concat(nonce, ciphertext, auth_tag) - The receiver runs the decrypt+verify procedure and it succeeds.
Can the receiver then extract the timestamp part of the nonce and trust that it is authentic?
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated. Is that still the case for these newer AEADs?
authenticated-encryption
asked Dec 29 '18 at 5:02
Kannan GoundanKannan Goundan
1384
add a comment |
I'd like to include an authenticated timestamp in my messages. I'm wondering if I can save a little space by putting the timestamp in the nonce.
Concrete example:
- Let's say I'm using XChaCha20-Poly1305 with a shared secret key.
- I generate the nonce/IV by concatenating an 8-byte timestamp and a 16-byte random value.
- I send
concat(nonce, ciphertext, auth_tag) - The receiver runs the decrypt+verify procedure and it succeeds.
Can the receiver then extract the timestamp part of the nonce and trust that it is authentic?
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated. Is that still the case for these newer AEADs?
authenticated-encryption
asked Dec 29 '18 at 5:02
Kannan GoundanKannan Goundan
1384
add a comment |
I'd like to include an authenticated timestamp in my messages. I'm wondering if I can save a little space by putting the timestamp in the nonce.
Concrete example:
- Let's say I'm using XChaCha20-Poly1305 with a shared secret key.
- I generate the nonce/IV by concatenating an 8-byte timestamp and a 16-byte random value.
- I send
concat(nonce, ciphertext, auth_tag) - The receiver runs the decrypt+verify procedure and it succeeds.
Can the receiver then extract the timestamp part of the nonce and trust that it is authentic?
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated. Is that still the case for these newer AEADs?
authenticated-encryption
asked Dec 29 '18 at 5:02
Kannan GoundanKannan Goundan
1384
I'd like to include an authenticated timestamp in my messages. I'm wondering if I can save a little space by putting the timestamp in the nonce.
Concrete example:
- Let's say I'm using XChaCha20-Poly1305 with a shared secret key.
- I generate the nonce/IV by concatenating an 8-byte timestamp and a 16-byte random value.
- I send
concat(nonce, ciphertext, auth_tag) - The receiver runs the decrypt+verify procedure and it succeeds.
Can the receiver then extract the timestamp part of the nonce and trust that it is authentic?
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated. Is that still the case for these newer AEADs?
authenticated-encryption
authenticated-encryption
asked Dec 29 '18 at 5:02
Kannan GoundanKannan Goundan
1384
asked Dec 29 '18 at 5:02
Kannan GoundanKannan Goundan
1384
asked Dec 29 '18 at 5:02
Kannan GoundanKannan Goundan
1384
asked Dec 29 '18 at 5:02
Kannan GoundanKannan Goundan
1384
asked Dec 29 '18 at 5:02
Kannan GoundanKannan Goundan
1384
1384
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Yes, AEAD constructions always authenticate the nonce. If they didn't then the integrity and authentication of the resulting plaintext after decryption would not be ensured.
You can see the definition in RFC 5116: An Interface and Algorithms for Authenticated Encryption, section 2.1. Authenticated Encryption:
The nonce is authenticated internally to the algorithm, and it is not
necessary to include it in the AD input. The nonce MAY be included
in P or A if it is convenient to the application.
Not all AEAD ciphers may necessarily keep to the letter of this RFC (the inclusion of the authentication tag in the ciphertext is debatable if you ask me - I consider it a separate field). However, I haven't seen any AEAD cipher that doesn't authenticate the nonce by design.
You're writing that
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated.
This is obviously not true. Yes, it is possible to design such a scheme and any competent cryptographer would not for get to authenticate the IV. There are even tries to standardize such a scheme, see e.g this scheme based on CBC with HMAC-SHA-1.
Less competent protocol designers are however free to shoot themselves in the foot when designing or implementing such a scheme. When using a well designed / reviewed / tested library and an AEAD scheme such mistakes are avoided.
answered Dec 29 '18 at 5:42
Maarten Bodewes♦Maarten Bodewes
53.4k677192
Oh you're right -- someone might do AES-then-HMAC without HMAC'ing the nonce. I just meant that when I read AES-then-HMAC code, I can see whether the nonce is authenticated. With an AEAD it's a black box so I wasn't sure.
– Kannan Goundan
Dec 29 '18 at 6:11
Ah, OK, in other words, you meant that it needs to be explicitly authenticated rather than relying on implicit authentication and that validating that the nonce is authenticated is easier for CBC-HMAC because of that. Just trying to show the right terms here :)
– Maarten Bodewes♦
Dec 29 '18 at 6:57
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
);
);
, "mathjax-editing");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
,
noCode: 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%2fcrypto.stackexchange.com%2fquestions%2f66143%2fdo-aeads-also-authenticate-the-nonce%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, AEAD constructions always authenticate the nonce. If they didn't then the integrity and authentication of the resulting plaintext after decryption would not be ensured.
You can see the definition in RFC 5116: An Interface and Algorithms for Authenticated Encryption, section 2.1. Authenticated Encryption:
The nonce is authenticated internally to the algorithm, and it is not
necessary to include it in the AD input. The nonce MAY be included
in P or A if it is convenient to the application.
Not all AEAD ciphers may necessarily keep to the letter of this RFC (the inclusion of the authentication tag in the ciphertext is debatable if you ask me - I consider it a separate field). However, I haven't seen any AEAD cipher that doesn't authenticate the nonce by design.
You're writing that
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated.
This is obviously not true. Yes, it is possible to design such a scheme and any competent cryptographer would not for get to authenticate the IV. There are even tries to standardize such a scheme, see e.g this scheme based on CBC with HMAC-SHA-1.
Less competent protocol designers are however free to shoot themselves in the foot when designing or implementing such a scheme. When using a well designed / reviewed / tested library and an AEAD scheme such mistakes are avoided.
answered Dec 29 '18 at 5:42
Maarten Bodewes♦Maarten Bodewes
53.4k677192
Oh you're right -- someone might do AES-then-HMAC without HMAC'ing the nonce. I just meant that when I read AES-then-HMAC code, I can see whether the nonce is authenticated. With an AEAD it's a black box so I wasn't sure.
– Kannan Goundan
Dec 29 '18 at 6:11
Ah, OK, in other words, you meant that it needs to be explicitly authenticated rather than relying on implicit authentication and that validating that the nonce is authenticated is easier for CBC-HMAC because of that. Just trying to show the right terms here :)
– Maarten Bodewes♦
Dec 29 '18 at 6:57
add a comment |
Yes, AEAD constructions always authenticate the nonce. If they didn't then the integrity and authentication of the resulting plaintext after decryption would not be ensured.
You can see the definition in RFC 5116: An Interface and Algorithms for Authenticated Encryption, section 2.1. Authenticated Encryption:
The nonce is authenticated internally to the algorithm, and it is not
necessary to include it in the AD input. The nonce MAY be included
in P or A if it is convenient to the application.
Not all AEAD ciphers may necessarily keep to the letter of this RFC (the inclusion of the authentication tag in the ciphertext is debatable if you ask me - I consider it a separate field). However, I haven't seen any AEAD cipher that doesn't authenticate the nonce by design.
You're writing that
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated.
This is obviously not true. Yes, it is possible to design such a scheme and any competent cryptographer would not for get to authenticate the IV. There are even tries to standardize such a scheme, see e.g this scheme based on CBC with HMAC-SHA-1.
Less competent protocol designers are however free to shoot themselves in the foot when designing or implementing such a scheme. When using a well designed / reviewed / tested library and an AEAD scheme such mistakes are avoided.
answered Dec 29 '18 at 5:42
Maarten Bodewes♦Maarten Bodewes
53.4k677192
Oh you're right -- someone might do AES-then-HMAC without HMAC'ing the nonce. I just meant that when I read AES-then-HMAC code, I can see whether the nonce is authenticated. With an AEAD it's a black box so I wasn't sure.
– Kannan Goundan
Dec 29 '18 at 6:11
Ah, OK, in other words, you meant that it needs to be explicitly authenticated rather than relying on implicit authentication and that validating that the nonce is authenticated is easier for CBC-HMAC because of that. Just trying to show the right terms here :)
– Maarten Bodewes♦
Dec 29 '18 at 6:57
add a comment |
Yes, AEAD constructions always authenticate the nonce. If they didn't then the integrity and authentication of the resulting plaintext after decryption would not be ensured.
You can see the definition in RFC 5116: An Interface and Algorithms for Authenticated Encryption, section 2.1. Authenticated Encryption:
The nonce is authenticated internally to the algorithm, and it is not
necessary to include it in the AD input. The nonce MAY be included
in P or A if it is convenient to the application.
Not all AEAD ciphers may necessarily keep to the letter of this RFC (the inclusion of the authentication tag in the ciphertext is debatable if you ask me - I consider it a separate field). However, I haven't seen any AEAD cipher that doesn't authenticate the nonce by design.
You're writing that
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated.
This is obviously not true. Yes, it is possible to design such a scheme and any competent cryptographer would not for get to authenticate the IV. There are even tries to standardize such a scheme, see e.g this scheme based on CBC with HMAC-SHA-1.
Less competent protocol designers are however free to shoot themselves in the foot when designing or implementing such a scheme. When using a well designed / reviewed / tested library and an AEAD scheme such mistakes are avoided.
answered Dec 29 '18 at 5:42
Maarten Bodewes♦Maarten Bodewes
53.4k677192
Yes, AEAD constructions always authenticate the nonce. If they didn't then the integrity and authentication of the resulting plaintext after decryption would not be ensured.
You can see the definition in RFC 5116: An Interface and Algorithms for Authenticated Encryption, section 2.1. Authenticated Encryption:
The nonce is authenticated internally to the algorithm, and it is not
necessary to include it in the AD input. The nonce MAY be included
in P or A if it is convenient to the application.
Not all AEAD ciphers may necessarily keep to the letter of this RFC (the inclusion of the authentication tag in the ciphertext is debatable if you ask me - I consider it a separate field). However, I haven't seen any AEAD cipher that doesn't authenticate the nonce by design.
You're writing that
With a more "traditional" composition, like AES-CBC-then-HMAC, the nonce is obviously authenticated.
This is obviously not true. Yes, it is possible to design such a scheme and any competent cryptographer would not for get to authenticate the IV. There are even tries to standardize such a scheme, see e.g this scheme based on CBC with HMAC-SHA-1.
Less competent protocol designers are however free to shoot themselves in the foot when designing or implementing such a scheme. When using a well designed / reviewed / tested library and an AEAD scheme such mistakes are avoided.
answered Dec 29 '18 at 5:42
Maarten Bodewes♦Maarten Bodewes
53.4k677192
edited Dec 29 '18 at 7:25
answered Dec 29 '18 at 5:42
Maarten Bodewes♦Maarten Bodewes
53.4k677192
answered Dec 29 '18 at 5:42
Maarten Bodewes♦Maarten Bodewes
53.4k677192
answered Dec 29 '18 at 5:42
Maarten Bodewes♦Maarten Bodewes
53.4k677192
53.4k677192
Oh you're right -- someone might do AES-then-HMAC without HMAC'ing the nonce. I just meant that when I read AES-then-HMAC code, I can see whether the nonce is authenticated. With an AEAD it's a black box so I wasn't sure.
– Kannan Goundan
Dec 29 '18 at 6:11
Ah, OK, in other words, you meant that it needs to be explicitly authenticated rather than relying on implicit authentication and that validating that the nonce is authenticated is easier for CBC-HMAC because of that. Just trying to show the right terms here :)
– Maarten Bodewes♦
Dec 29 '18 at 6:57
add a comment |
Oh you're right -- someone might do AES-then-HMAC without HMAC'ing the nonce. I just meant that when I read AES-then-HMAC code, I can see whether the nonce is authenticated. With an AEAD it's a black box so I wasn't sure.
– Kannan Goundan
Dec 29 '18 at 6:11
Ah, OK, in other words, you meant that it needs to be explicitly authenticated rather than relying on implicit authentication and that validating that the nonce is authenticated is easier for CBC-HMAC because of that. Just trying to show the right terms here :)
– Maarten Bodewes♦
Dec 29 '18 at 6:57
Oh you're right -- someone might do AES-then-HMAC without HMAC'ing the nonce. I just meant that when I read AES-then-HMAC code, I can see whether the nonce is authenticated. With an AEAD it's a black box so I wasn't sure.
– Kannan Goundan
Dec 29 '18 at 6:11
Oh you're right -- someone might do AES-then-HMAC without HMAC'ing the nonce. I just meant that when I read AES-then-HMAC code, I can see whether the nonce is authenticated. With an AEAD it's a black box so I wasn't sure.
– Kannan Goundan
Dec 29 '18 at 6:11
Ah, OK, in other words, you meant that it needs to be explicitly authenticated rather than relying on implicit authentication and that validating that the nonce is authenticated is easier for CBC-HMAC because of that. Just trying to show the right terms here :)
– Maarten Bodewes♦
Dec 29 '18 at 6:57
Ah, OK, in other words, you meant that it needs to be explicitly authenticated rather than relying on implicit authentication and that validating that the nonce is authenticated is easier for CBC-HMAC because of that. Just trying to show the right terms here :)
– Maarten Bodewes♦
Dec 29 '18 at 6:57
add a comment |
Thanks for contributing an answer to Cryptography Stack Exchange!
- 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.
Use MathJax to format equations. MathJax reference.
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%2fcrypto.stackexchange.com%2fquestions%2f66143%2fdo-aeads-also-authenticate-the-nonce%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