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;
}







1












$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?










share|improve this question











$endgroup$





















    1












    $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?










    share|improve this question











    $endgroup$

















      1












      1








      1


      1



      $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?










      share|improve this question











      $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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      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

























          1 Answer
          1






          active

          oldest

          votes


















          5













          $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:




          1. An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.


          2. 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!






          share|improve this answer











          $endgroup$


















            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
            });


            }
            });














            draft saved

            draft discarded


















            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









            5













            $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:




            1. An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.


            2. 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!






            share|improve this answer











            $endgroup$




















              5













              $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:




              1. An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.


              2. 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!






              share|improve this answer











              $endgroup$


















                5














                5










                5







                $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:




                1. An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.


                2. 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!






                share|improve this answer











                $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:




                1. An adversary who knows the first block of plaintext can solve for the GHASH authentication key and forge arbitrarily many additional messages.


                2. 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!







                share|improve this answer














                share|improve this answer



                share|improve this answer








                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

































                    draft saved

                    draft discarded




















































                    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.




                    draft saved


                    draft discarded














                    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





















































                    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







                    Popular posts from this blog

                    Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

                    Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

                    Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...