Do AEADs also authenticate the nonce?
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 3 hours ago
Kannan Goundan
1284
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 3 hours ago
Kannan Goundan
1284
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 3 hours ago
Kannan Goundan
1284
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 3 hours ago
Kannan Goundan
1284
asked 3 hours ago
Kannan Goundan
1284
asked 3 hours ago
Kannan Goundan
1284
asked 3 hours ago
Kannan Goundan
1284
asked 3 hours ago
Kannan Goundan
1284
1284
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 2 hours ago
Maarten Bodewes♦
52.7k677191
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
2 hours ago
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♦
1 hour ago
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 2 hours ago
Maarten Bodewes♦
52.7k677191
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
2 hours ago
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♦
1 hour ago
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 2 hours ago
Maarten Bodewes♦
52.7k677191
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
2 hours ago
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♦
1 hour ago
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 2 hours ago
Maarten Bodewes♦
52.7k677191
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 2 hours ago
Maarten Bodewes♦
52.7k677191
edited 1 hour ago
answered 2 hours ago
Maarten Bodewes♦
52.7k677191
answered 2 hours ago
Maarten Bodewes♦
52.7k677191
answered 2 hours ago
Maarten Bodewes♦
52.7k677191
52.7k677191
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
2 hours ago
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♦
1 hour ago
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
2 hours ago
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♦
1 hour ago
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
2 hours ago
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
2 hours ago
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♦
1 hour ago
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♦
1 hour ago
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%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
