What if an AES GCM nonce overflows and collides with the GHASH nonce (0^128)?Relationship between AES GCM and...
Unlock your Lock
rationalizing sieges in a modern/near-future setting
When was the tzitz lost?
Weighted smooth histogram
Should open strings on guitar be tuned to the key of the song played?
Book featuring a child learning from a crowdsourced AI book
Read file contents to variable and iterate over each character in file
Thought experiment and possible contradiction between electromagnetism and special relativity
To what extent should we fear giving offense?
Does a Mace of Disruption's Frightened effect override some undead's immunity to the Frightened condition?
Why is getting a PhD considered "financially irresponsible" by some people?
What is the name of this plot that has rows with two connected dots?
Why does matter stays collapsed in the core, following a supernova explosion?
If I said I had $100 when asked, but I actually had $200, would I be lying by omission?
3D cryptic featuring Mao, Stalin and Simba's uncle
What is the appropriate way to store arrays of information with configuration API?
Do sharpies or markers damage soft gear?
How does the OS tell whether an "Address is already in use"?
tcbset behaves differently in preamble and main body
What stops you from using fixed income in developing countries?
Reusing studs to hang shoe bins
What is Soda Fountain Etiquette?
Is a Centaur considered an animal when calculating carrying capacity for vehicles?
Stuck on a puzzle
What if an AES GCM nonce overflows and collides with the GHASH nonce (0^128)?
Relationship between AES GCM and AES CTRIs AES-GCM with static key and dynamic salt safe to reuse IV/nonceDeterministic Encryption with AES GCM - how to choose the IV (nonce)AES 128 GCM - dynamic key with static IV/nonceWhat does GHASH really do?Which is slower, AES or GCM hash (GHASH), if CPU has no special instructions?GCM mode of operation and IV size less 96 bitsAES-GCM GHASH calculation;AES GCM mode and the message is the same as the passwordemulating AES GCM with AES CTRWhat Are the Risks of AES-GCM [Key, Nonce, Message] where Nonce = Message
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
$begingroup$
When using AES in GCM mode, the GHASH function uses E(0^128) as the initial value for H, the authentication key. The IV, for the underlaying CTR mode, is initialized with:
[prefix (application nonce)] [initial_counter (4 byte counter)]
This initial counter starts at ...02, like explained here. I'm guessing this is done to prevent a collision with the GHASH function.
It's known that letting a nonce overflow is very, very bad, because repeating a nonce completely breaks GCM mode. But what if the prefix is all zeroes, and the counter overflows only to 0xffffff+1 (0^128)? You'd have one block that's xor'ed with the same value as the authentication key. Would this break GCM?
aes-gcm
$endgroup$
add a comment |
$begingroup$
When using AES in GCM mode, the GHASH function uses E(0^128) as the initial value for H, the authentication key. The IV, for the underlaying CTR mode, is initialized with:
[prefix (application nonce)] [initial_counter (4 byte counter)]
This initial counter starts at ...02, like explained here. I'm guessing this is done to prevent a collision with the GHASH function.
It's known that letting a nonce overflow is very, very bad, because repeating a nonce completely breaks GCM mode. But what if the prefix is all zeroes, and the counter overflows only to 0xffffff+1 (0^128)? You'd have one block that's xor'ed with the same value as the authentication key. Would this break GCM?
aes-gcm
$endgroup$
add a comment |
$begingroup$
When using AES in GCM mode, the GHASH function uses E(0^128) as the initial value for H, the authentication key. The IV, for the underlaying CTR mode, is initialized with:
[prefix (application nonce)] [initial_counter (4 byte counter)]
This initial counter starts at ...02, like explained here. I'm guessing this is done to prevent a collision with the GHASH function.
It's known that letting a nonce overflow is very, very bad, because repeating a nonce completely breaks GCM mode. But what if the prefix is all zeroes, and the counter overflows only to 0xffffff+1 (0^128)? You'd have one block that's xor'ed with the same value as the authentication key. Would this break GCM?
aes-gcm
$endgroup$
When using AES in GCM mode, the GHASH function uses E(0^128) as the initial value for H, the authentication key. The IV, for the underlaying CTR mode, is initialized with:
[prefix (application nonce)] [initial_counter (4 byte counter)]
This initial counter starts at ...02, like explained here. I'm guessing this is done to prevent a collision with the GHASH function.
It's known that letting a nonce overflow is very, very bad, because repeating a nonce completely breaks GCM mode. But what if the prefix is all zeroes, and the counter overflows only to 0xffffff+1 (0^128)? You'd have one block that's xor'ed with the same value as the authentication key. Would this break GCM?
aes-gcm
aes-gcm
edited 13 hours ago
Squeamish Ossifrage
31k1 gold badge52 silver badges133 bronze badges
31k1 gold badge52 silver badges133 bronze badges
asked 13 hours ago
GraaGraa
1692 silver badges6 bronze badges
1692 silver badges6 bronze badges
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
This is not allowed. An AES-GCM implementation that accepts messages longer than $2^{39} - 256$ bits, i.e. $2^{32} - 2$ blocks, is broken. A protocol that is defined in terms of AES-GCM on messages longer than $2^{39} - 256$ bits is nonsensical.
Protocols shouldn't be defined in terms of messages that long anyway because an adversary can waste the receiver's resources by sending an obscenely long message. If you allow terabyte-long messages, an adversary can waste a terabyte of memory before you realize it's a forgery and drop it on the floor.
Instead, you should break messages up into units no longer than you want to have to buffer in memory before you can decide to drop forgeries on the floor, like 1500 bytes for an IP packet, or 64 KB for a TCP segment, or maybe a megabyte if appropriate for your application.
But let's suppose you did have a broken protocol that violated the rules of AES-GCM and a broken implementation that let it happen. What happens if you do this—encrypt a message of ${>}2^{32} - 2$ blocks, with the counter truncated at 32 bits and wrapping around? Then:
An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.
An adversary who knows the third block of plaintext can decrypt block number $2^{32}$ of the plaintext.
If the counter carries into the nonce, rather than being truncated at 32 bits, then it is a slightly different known-plaintext attack—e.g., enabling decryption of the first block of the next message, assuming sequential message numbers for the nonce, rather than block $2^{32}$ of the same message.
In brief, don't do it!
$endgroup$
add a comment |
Your Answer
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%2f72830%2fwhat-if-an-aes-gcm-nonce-overflows-and-collides-with-the-ghash-nonce-0128%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
$begingroup$
This is not allowed. An AES-GCM implementation that accepts messages longer than $2^{39} - 256$ bits, i.e. $2^{32} - 2$ blocks, is broken. A protocol that is defined in terms of AES-GCM on messages longer than $2^{39} - 256$ bits is nonsensical.
Protocols shouldn't be defined in terms of messages that long anyway because an adversary can waste the receiver's resources by sending an obscenely long message. If you allow terabyte-long messages, an adversary can waste a terabyte of memory before you realize it's a forgery and drop it on the floor.
Instead, you should break messages up into units no longer than you want to have to buffer in memory before you can decide to drop forgeries on the floor, like 1500 bytes for an IP packet, or 64 KB for a TCP segment, or maybe a megabyte if appropriate for your application.
But let's suppose you did have a broken protocol that violated the rules of AES-GCM and a broken implementation that let it happen. What happens if you do this—encrypt a message of ${>}2^{32} - 2$ blocks, with the counter truncated at 32 bits and wrapping around? Then:
An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.
An adversary who knows the third block of plaintext can decrypt block number $2^{32}$ of the plaintext.
If the counter carries into the nonce, rather than being truncated at 32 bits, then it is a slightly different known-plaintext attack—e.g., enabling decryption of the first block of the next message, assuming sequential message numbers for the nonce, rather than block $2^{32}$ of the same message.
In brief, don't do it!
$endgroup$
add a comment |
$begingroup$
This is not allowed. An AES-GCM implementation that accepts messages longer than $2^{39} - 256$ bits, i.e. $2^{32} - 2$ blocks, is broken. A protocol that is defined in terms of AES-GCM on messages longer than $2^{39} - 256$ bits is nonsensical.
Protocols shouldn't be defined in terms of messages that long anyway because an adversary can waste the receiver's resources by sending an obscenely long message. If you allow terabyte-long messages, an adversary can waste a terabyte of memory before you realize it's a forgery and drop it on the floor.
Instead, you should break messages up into units no longer than you want to have to buffer in memory before you can decide to drop forgeries on the floor, like 1500 bytes for an IP packet, or 64 KB for a TCP segment, or maybe a megabyte if appropriate for your application.
But let's suppose you did have a broken protocol that violated the rules of AES-GCM and a broken implementation that let it happen. What happens if you do this—encrypt a message of ${>}2^{32} - 2$ blocks, with the counter truncated at 32 bits and wrapping around? Then:
An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.
An adversary who knows the third block of plaintext can decrypt block number $2^{32}$ of the plaintext.
If the counter carries into the nonce, rather than being truncated at 32 bits, then it is a slightly different known-plaintext attack—e.g., enabling decryption of the first block of the next message, assuming sequential message numbers for the nonce, rather than block $2^{32}$ of the same message.
In brief, don't do it!
$endgroup$
add a comment |
$begingroup$
This is not allowed. An AES-GCM implementation that accepts messages longer than $2^{39} - 256$ bits, i.e. $2^{32} - 2$ blocks, is broken. A protocol that is defined in terms of AES-GCM on messages longer than $2^{39} - 256$ bits is nonsensical.
Protocols shouldn't be defined in terms of messages that long anyway because an adversary can waste the receiver's resources by sending an obscenely long message. If you allow terabyte-long messages, an adversary can waste a terabyte of memory before you realize it's a forgery and drop it on the floor.
Instead, you should break messages up into units no longer than you want to have to buffer in memory before you can decide to drop forgeries on the floor, like 1500 bytes for an IP packet, or 64 KB for a TCP segment, or maybe a megabyte if appropriate for your application.
But let's suppose you did have a broken protocol that violated the rules of AES-GCM and a broken implementation that let it happen. What happens if you do this—encrypt a message of ${>}2^{32} - 2$ blocks, with the counter truncated at 32 bits and wrapping around? Then:
An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.
An adversary who knows the third block of plaintext can decrypt block number $2^{32}$ of the plaintext.
If the counter carries into the nonce, rather than being truncated at 32 bits, then it is a slightly different known-plaintext attack—e.g., enabling decryption of the first block of the next message, assuming sequential message numbers for the nonce, rather than block $2^{32}$ of the same message.
In brief, don't do it!
$endgroup$
This is not allowed. An AES-GCM implementation that accepts messages longer than $2^{39} - 256$ bits, i.e. $2^{32} - 2$ blocks, is broken. A protocol that is defined in terms of AES-GCM on messages longer than $2^{39} - 256$ bits is nonsensical.
Protocols shouldn't be defined in terms of messages that long anyway because an adversary can waste the receiver's resources by sending an obscenely long message. If you allow terabyte-long messages, an adversary can waste a terabyte of memory before you realize it's a forgery and drop it on the floor.
Instead, you should break messages up into units no longer than you want to have to buffer in memory before you can decide to drop forgeries on the floor, like 1500 bytes for an IP packet, or 64 KB for a TCP segment, or maybe a megabyte if appropriate for your application.
But let's suppose you did have a broken protocol that violated the rules of AES-GCM and a broken implementation that let it happen. What happens if you do this—encrypt a message of ${>}2^{32} - 2$ blocks, with the counter truncated at 32 bits and wrapping around? Then:
An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.
An adversary who knows the third block of plaintext can decrypt block number $2^{32}$ of the plaintext.
If the counter carries into the nonce, rather than being truncated at 32 bits, then it is a slightly different known-plaintext attack—e.g., enabling decryption of the first block of the next message, assuming sequential message numbers for the nonce, rather than block $2^{32}$ of the same message.
In brief, don't do it!
edited 10 hours ago
answered 13 hours ago
Squeamish OssifrageSqueamish Ossifrage
31k1 gold badge52 silver badges133 bronze badges
31k1 gold badge52 silver badges133 bronze badges
add a comment |
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%2f72830%2fwhat-if-an-aes-gcm-nonce-overflows-and-collides-with-the-ghash-nonce-0128%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