Can a zero nonce be safely used with AES-GCM if the key is random and never used again? Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Multi-target attacks on AES-CTR with a random nonceAES-GCM and its IV/nonce valuenonce of AES-GCM in SSLCan we use the authentication tag as Nonce / IV for the next message?Is it acceptable to write the nonce to the encrypted file during AES-256 GCM?Using AES-CTR to generate AES subkeys from a master key and nonceNonce for AES GCM to prevent replay attacksSafety of random nonce with AES-GCM?Can I use a deterministic NONCE for AES-GCM file encryption if I generate “fresh” keys for each encrypted fileIs AES-GCM with static key and dynamic salt safe to reuse IV/nonceWhat Are the Risks of AES-GCM [Key, Nonce, Message] where Nonce = Message

AppleTVs create a chatty alternate WiFi network

Should there be a hyphen in the construction "IT affin"?

How do living politicians protect their readily obtainable signatures from misuse?

An adverb for when you're not exaggerating

Do I really need to have a message in a novel to appeal to readers?

What initially awakened the Balrog?

What order were files/directories outputted in dir?

How to run automated tests after each commit?

If Windows 7 doesn't support WSL, then what does Linux subsystem option mean?

Putting class ranking in CV, but against dept guidelines

How to draw/optimize this graph with tikz

Would it be easier to apply for a UK visa if there is a host family to sponsor for you in going there?

Why limits give us the exact value of the slope of the tangent line?

Most bit efficient text communication method?

Hangman Game with C++

Amount of permutations on an NxNxN Rubik's Cube

Did any compiler fully use 80-bit floating point?

How come Sam didn't become Lord of Horn Hill?

What is the meaning of 'breadth' in breadth first search?

How would a mousetrap for use in space work?

How to compare two different files line by line in unix?

Trademark violation for app?

How often does castling occur in grandmaster games?

One-one communication



Can a zero nonce be safely used with AES-GCM if the key is random and never used again?



Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?Multi-target attacks on AES-CTR with a random nonceAES-GCM and its IV/nonce valuenonce of AES-GCM in SSLCan we use the authentication tag as Nonce / IV for the next message?Is it acceptable to write the nonce to the encrypted file during AES-256 GCM?Using AES-CTR to generate AES subkeys from a master key and nonceNonce for AES GCM to prevent replay attacksSafety of random nonce with AES-GCM?Can I use a deterministic NONCE for AES-GCM file encryption if I generate “fresh” keys for each encrypted fileIs AES-GCM with static key and dynamic salt safe to reuse IV/nonceWhat Are the Risks of AES-GCM [Key, Nonce, Message] where Nonce = Message










8












$begingroup$


I could generate a random nonce and prepend it to the ciphertext, but storage space is at a premium and the only constraint AES-GCM has on the nonce (if I'm reading correctly) is that the same nonce must never be paired with the same key for a second encryption.



The encryption key is randomly generated, used for a single encryption, split using Shamir's Secret Sharing Scheme, and discarded. When the key is reconstructed for decryption, there is no chance that it can be fed back through to encrypt again; a new random key is always generated for each encryption.



If that's the only constraint, then twelve zero bytes are as safe as twelve random bytes prepended to the ciphertext. I'm reading that the AES-GCM nonce is used as the IV for AES in CTR mode. It's okay to use a zero IV for AES-CTR as long as the key is never reused, but I don't want to assume without confirmation that AES-GCM does nothing relevant with the nonce besides passing it to AES CTR. Am I missing anything?










share|improve this question









$endgroup$
















    8












    $begingroup$


    I could generate a random nonce and prepend it to the ciphertext, but storage space is at a premium and the only constraint AES-GCM has on the nonce (if I'm reading correctly) is that the same nonce must never be paired with the same key for a second encryption.



    The encryption key is randomly generated, used for a single encryption, split using Shamir's Secret Sharing Scheme, and discarded. When the key is reconstructed for decryption, there is no chance that it can be fed back through to encrypt again; a new random key is always generated for each encryption.



    If that's the only constraint, then twelve zero bytes are as safe as twelve random bytes prepended to the ciphertext. I'm reading that the AES-GCM nonce is used as the IV for AES in CTR mode. It's okay to use a zero IV for AES-CTR as long as the key is never reused, but I don't want to assume without confirmation that AES-GCM does nothing relevant with the nonce besides passing it to AES CTR. Am I missing anything?










    share|improve this question









    $endgroup$














      8












      8








      8


      2



      $begingroup$


      I could generate a random nonce and prepend it to the ciphertext, but storage space is at a premium and the only constraint AES-GCM has on the nonce (if I'm reading correctly) is that the same nonce must never be paired with the same key for a second encryption.



      The encryption key is randomly generated, used for a single encryption, split using Shamir's Secret Sharing Scheme, and discarded. When the key is reconstructed for decryption, there is no chance that it can be fed back through to encrypt again; a new random key is always generated for each encryption.



      If that's the only constraint, then twelve zero bytes are as safe as twelve random bytes prepended to the ciphertext. I'm reading that the AES-GCM nonce is used as the IV for AES in CTR mode. It's okay to use a zero IV for AES-CTR as long as the key is never reused, but I don't want to assume without confirmation that AES-GCM does nothing relevant with the nonce besides passing it to AES CTR. Am I missing anything?










      share|improve this question









      $endgroup$




      I could generate a random nonce and prepend it to the ciphertext, but storage space is at a premium and the only constraint AES-GCM has on the nonce (if I'm reading correctly) is that the same nonce must never be paired with the same key for a second encryption.



      The encryption key is randomly generated, used for a single encryption, split using Shamir's Secret Sharing Scheme, and discarded. When the key is reconstructed for decryption, there is no chance that it can be fed back through to encrypt again; a new random key is always generated for each encryption.



      If that's the only constraint, then twelve zero bytes are as safe as twelve random bytes prepended to the ciphertext. I'm reading that the AES-GCM nonce is used as the IV for AES in CTR mode. It's okay to use a zero IV for AES-CTR as long as the key is never reused, but I don't want to assume without confirmation that AES-GCM does nothing relevant with the nonce besides passing it to AES CTR. Am I missing anything?







      aes initialization-vector gcm nonce aes-gcm






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Apr 14 at 22:52









      jnm2jnm2

      322310




      322310




















          3 Answers
          3






          active

          oldest

          votes


















          8












          $begingroup$

          Usually. However, if you are using 128-bit AES in CTR mode (remember that GCM is essentially just CTR with authentication), then a kind of attack called a multi-target attack can become possible. This attack is realistic when an attacker has a huge amount of stored ciphertext, each with a random key. While breaking a specific key requires performing up to 2128 operations, breaking any key is significantly easier. This attack can be mitigated either by using a larger key size, or by using a random nonce.



          From the above-linked blog post by DJB:




          What the attacker hopes to find inside the AES attack is a key collision. This means that a key guessed by the attack matches a key chosen by a user. Any particular guessed key has chance only 1/2128 of matching any particular user key, but the attack ends up merging costs across a batch of 240 user keys, amplifying the effectiveness of each guess by a factor 240.







          share|improve this answer









          $endgroup$












          • $begingroup$
            Good to know! I'm using a 256-bit key and there is not much ciphertext per key (a few kilobytes). It sounds like my particular situation is safe, but can you quantify "huge" to shed light on the decision-making process if I find myself in a similar but different scenario?
            $endgroup$
            – jnm2
            Apr 15 at 13:48











          • $begingroup$
            And the sole benefit of a random IV is that it avoids collisions using 256+96 random bits rather than just 256 random bits (or 128+96 instead of 128)?
            $endgroup$
            – jnm2
            Apr 15 at 14:09











          • $begingroup$
            @jnm2 How huge depends on how much advantage you are OK with the attacker getting. The attack starts to become significantly easier than brute force after around $2^40$ keys. And if you are using a 256-bit key, then there is no reason to use a random nonce, as long as the key is unique and always random.
            $endgroup$
            – forest
            Apr 16 at 1:46



















          5












          $begingroup$


          Am I missing anything?




          No, you are not; if you use a key only once, that is, to encrypt a single message, and never use it to encrypt anything else, then it doesn't matter what nonce you use. An implicit 'all-00' nonce is as good as any.



          BTW: AES-GCM also uses the nonce as a part of the transform that generates the integrity tag; however, that addition does not complicate the fact that an all-00 nonce is fine, as long as you use the key once.






          share|improve this answer









          $endgroup$












          • $begingroup$
            I'm not sure that this is entirely correct, due to the risk of multi-target attacks on AES128.
            $endgroup$
            – forest
            Apr 15 at 8:04



















          1












          $begingroup$

          Does your random generator guarantee (with sufficient confidence) that it won't generate the same random key a second time?



          As you correctly stated, as long as the same nonce and key are never re-used, everything is fine. But a randomly generated key does not by itself have such an assurance.



          There are two simple ways you can take:



          a) accept the risk. Make a quick calculation based on your RNG what the probability is that a key will be repeated and then decide that this chance is acceptable (or not).



          b) instead of using a zero nonce, use a simple counter. That's what many implementations actually do. The nonce can be predictable, that's ok.



          The decision in a) largely depends on the number of messages you are going to send. If the number is low, the risk is most likely acceptable. If we're talking millions-plus messages, you might find the probability of an identical key (remember the birthday paradox!) too high for comfort.






          share|improve this answer









          $endgroup$












          • $begingroup$
            The advantage of using a fixed nonce, is that you don't need to transmit it or store it. I presume this is enough of an advantage for the OP.
            $endgroup$
            – Martin Bonner
            Apr 15 at 9:52










          • $begingroup$
            @MartinBonner You can usually derive the nonce from the same master secret that the key is derived from.
            $endgroup$
            – forest
            Apr 15 at 9:53










          • $begingroup$
            @MartinBonner - as written: weigh the advantage against the risk and make a decision. The OP doesn't specify his use case, which makes it difficult to be specific on the threat level.
            $endgroup$
            – Tom
            Apr 15 at 9:56










          • $begingroup$
            Good reminder. I can't use a counter since there is no context saved from one encryption to the next. This is a standalone tool with no central server to house a counter. The only options I know of are fixed nonce (e.g. zeros) and random nonce. The key is 256 bits and encryption will be occasional. The generator is BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG on Windows and OpenSSL on Unix.
            $endgroup$
            – jnm2
            Apr 15 at 14:01











          • $begingroup$
            @jnm2 you could use a trivial counter, such as the timestamp (rounded to full seconds or even minutes, if both systems are time-synchronized) or even just the day-of-year (if not and the edge case of one message being not decryptable because it was sent at just the right second doesn't matter). This would already dramatically reduce the chances of a chance repetition.
            $endgroup$
            – Tom
            Apr 15 at 18:44











          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%2f68774%2fcan-a-zero-nonce-be-safely-used-with-aes-gcm-if-the-key-is-random-and-never-used%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          3 Answers
          3






          active

          oldest

          votes








          3 Answers
          3






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          8












          $begingroup$

          Usually. However, if you are using 128-bit AES in CTR mode (remember that GCM is essentially just CTR with authentication), then a kind of attack called a multi-target attack can become possible. This attack is realistic when an attacker has a huge amount of stored ciphertext, each with a random key. While breaking a specific key requires performing up to 2128 operations, breaking any key is significantly easier. This attack can be mitigated either by using a larger key size, or by using a random nonce.



          From the above-linked blog post by DJB:




          What the attacker hopes to find inside the AES attack is a key collision. This means that a key guessed by the attack matches a key chosen by a user. Any particular guessed key has chance only 1/2128 of matching any particular user key, but the attack ends up merging costs across a batch of 240 user keys, amplifying the effectiveness of each guess by a factor 240.







          share|improve this answer









          $endgroup$












          • $begingroup$
            Good to know! I'm using a 256-bit key and there is not much ciphertext per key (a few kilobytes). It sounds like my particular situation is safe, but can you quantify "huge" to shed light on the decision-making process if I find myself in a similar but different scenario?
            $endgroup$
            – jnm2
            Apr 15 at 13:48











          • $begingroup$
            And the sole benefit of a random IV is that it avoids collisions using 256+96 random bits rather than just 256 random bits (or 128+96 instead of 128)?
            $endgroup$
            – jnm2
            Apr 15 at 14:09











          • $begingroup$
            @jnm2 How huge depends on how much advantage you are OK with the attacker getting. The attack starts to become significantly easier than brute force after around $2^40$ keys. And if you are using a 256-bit key, then there is no reason to use a random nonce, as long as the key is unique and always random.
            $endgroup$
            – forest
            Apr 16 at 1:46
















          8












          $begingroup$

          Usually. However, if you are using 128-bit AES in CTR mode (remember that GCM is essentially just CTR with authentication), then a kind of attack called a multi-target attack can become possible. This attack is realistic when an attacker has a huge amount of stored ciphertext, each with a random key. While breaking a specific key requires performing up to 2128 operations, breaking any key is significantly easier. This attack can be mitigated either by using a larger key size, or by using a random nonce.



          From the above-linked blog post by DJB:




          What the attacker hopes to find inside the AES attack is a key collision. This means that a key guessed by the attack matches a key chosen by a user. Any particular guessed key has chance only 1/2128 of matching any particular user key, but the attack ends up merging costs across a batch of 240 user keys, amplifying the effectiveness of each guess by a factor 240.







          share|improve this answer









          $endgroup$












          • $begingroup$
            Good to know! I'm using a 256-bit key and there is not much ciphertext per key (a few kilobytes). It sounds like my particular situation is safe, but can you quantify "huge" to shed light on the decision-making process if I find myself in a similar but different scenario?
            $endgroup$
            – jnm2
            Apr 15 at 13:48











          • $begingroup$
            And the sole benefit of a random IV is that it avoids collisions using 256+96 random bits rather than just 256 random bits (or 128+96 instead of 128)?
            $endgroup$
            – jnm2
            Apr 15 at 14:09











          • $begingroup$
            @jnm2 How huge depends on how much advantage you are OK with the attacker getting. The attack starts to become significantly easier than brute force after around $2^40$ keys. And if you are using a 256-bit key, then there is no reason to use a random nonce, as long as the key is unique and always random.
            $endgroup$
            – forest
            Apr 16 at 1:46














          8












          8








          8





          $begingroup$

          Usually. However, if you are using 128-bit AES in CTR mode (remember that GCM is essentially just CTR with authentication), then a kind of attack called a multi-target attack can become possible. This attack is realistic when an attacker has a huge amount of stored ciphertext, each with a random key. While breaking a specific key requires performing up to 2128 operations, breaking any key is significantly easier. This attack can be mitigated either by using a larger key size, or by using a random nonce.



          From the above-linked blog post by DJB:




          What the attacker hopes to find inside the AES attack is a key collision. This means that a key guessed by the attack matches a key chosen by a user. Any particular guessed key has chance only 1/2128 of matching any particular user key, but the attack ends up merging costs across a batch of 240 user keys, amplifying the effectiveness of each guess by a factor 240.







          share|improve this answer









          $endgroup$



          Usually. However, if you are using 128-bit AES in CTR mode (remember that GCM is essentially just CTR with authentication), then a kind of attack called a multi-target attack can become possible. This attack is realistic when an attacker has a huge amount of stored ciphertext, each with a random key. While breaking a specific key requires performing up to 2128 operations, breaking any key is significantly easier. This attack can be mitigated either by using a larger key size, or by using a random nonce.



          From the above-linked blog post by DJB:




          What the attacker hopes to find inside the AES attack is a key collision. This means that a key guessed by the attack matches a key chosen by a user. Any particular guessed key has chance only 1/2128 of matching any particular user key, but the attack ends up merging costs across a batch of 240 user keys, amplifying the effectiveness of each guess by a factor 240.








          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 15 at 7:56









          forestforest

          5,00211744




          5,00211744











          • $begingroup$
            Good to know! I'm using a 256-bit key and there is not much ciphertext per key (a few kilobytes). It sounds like my particular situation is safe, but can you quantify "huge" to shed light on the decision-making process if I find myself in a similar but different scenario?
            $endgroup$
            – jnm2
            Apr 15 at 13:48











          • $begingroup$
            And the sole benefit of a random IV is that it avoids collisions using 256+96 random bits rather than just 256 random bits (or 128+96 instead of 128)?
            $endgroup$
            – jnm2
            Apr 15 at 14:09











          • $begingroup$
            @jnm2 How huge depends on how much advantage you are OK with the attacker getting. The attack starts to become significantly easier than brute force after around $2^40$ keys. And if you are using a 256-bit key, then there is no reason to use a random nonce, as long as the key is unique and always random.
            $endgroup$
            – forest
            Apr 16 at 1:46

















          • $begingroup$
            Good to know! I'm using a 256-bit key and there is not much ciphertext per key (a few kilobytes). It sounds like my particular situation is safe, but can you quantify "huge" to shed light on the decision-making process if I find myself in a similar but different scenario?
            $endgroup$
            – jnm2
            Apr 15 at 13:48











          • $begingroup$
            And the sole benefit of a random IV is that it avoids collisions using 256+96 random bits rather than just 256 random bits (or 128+96 instead of 128)?
            $endgroup$
            – jnm2
            Apr 15 at 14:09











          • $begingroup$
            @jnm2 How huge depends on how much advantage you are OK with the attacker getting. The attack starts to become significantly easier than brute force after around $2^40$ keys. And if you are using a 256-bit key, then there is no reason to use a random nonce, as long as the key is unique and always random.
            $endgroup$
            – forest
            Apr 16 at 1:46
















          $begingroup$
          Good to know! I'm using a 256-bit key and there is not much ciphertext per key (a few kilobytes). It sounds like my particular situation is safe, but can you quantify "huge" to shed light on the decision-making process if I find myself in a similar but different scenario?
          $endgroup$
          – jnm2
          Apr 15 at 13:48





          $begingroup$
          Good to know! I'm using a 256-bit key and there is not much ciphertext per key (a few kilobytes). It sounds like my particular situation is safe, but can you quantify "huge" to shed light on the decision-making process if I find myself in a similar but different scenario?
          $endgroup$
          – jnm2
          Apr 15 at 13:48













          $begingroup$
          And the sole benefit of a random IV is that it avoids collisions using 256+96 random bits rather than just 256 random bits (or 128+96 instead of 128)?
          $endgroup$
          – jnm2
          Apr 15 at 14:09





          $begingroup$
          And the sole benefit of a random IV is that it avoids collisions using 256+96 random bits rather than just 256 random bits (or 128+96 instead of 128)?
          $endgroup$
          – jnm2
          Apr 15 at 14:09













          $begingroup$
          @jnm2 How huge depends on how much advantage you are OK with the attacker getting. The attack starts to become significantly easier than brute force after around $2^40$ keys. And if you are using a 256-bit key, then there is no reason to use a random nonce, as long as the key is unique and always random.
          $endgroup$
          – forest
          Apr 16 at 1:46





          $begingroup$
          @jnm2 How huge depends on how much advantage you are OK with the attacker getting. The attack starts to become significantly easier than brute force after around $2^40$ keys. And if you are using a 256-bit key, then there is no reason to use a random nonce, as long as the key is unique and always random.
          $endgroup$
          – forest
          Apr 16 at 1:46












          5












          $begingroup$


          Am I missing anything?




          No, you are not; if you use a key only once, that is, to encrypt a single message, and never use it to encrypt anything else, then it doesn't matter what nonce you use. An implicit 'all-00' nonce is as good as any.



          BTW: AES-GCM also uses the nonce as a part of the transform that generates the integrity tag; however, that addition does not complicate the fact that an all-00 nonce is fine, as long as you use the key once.






          share|improve this answer









          $endgroup$












          • $begingroup$
            I'm not sure that this is entirely correct, due to the risk of multi-target attacks on AES128.
            $endgroup$
            – forest
            Apr 15 at 8:04
















          5












          $begingroup$


          Am I missing anything?




          No, you are not; if you use a key only once, that is, to encrypt a single message, and never use it to encrypt anything else, then it doesn't matter what nonce you use. An implicit 'all-00' nonce is as good as any.



          BTW: AES-GCM also uses the nonce as a part of the transform that generates the integrity tag; however, that addition does not complicate the fact that an all-00 nonce is fine, as long as you use the key once.






          share|improve this answer









          $endgroup$












          • $begingroup$
            I'm not sure that this is entirely correct, due to the risk of multi-target attacks on AES128.
            $endgroup$
            – forest
            Apr 15 at 8:04














          5












          5








          5





          $begingroup$


          Am I missing anything?




          No, you are not; if you use a key only once, that is, to encrypt a single message, and never use it to encrypt anything else, then it doesn't matter what nonce you use. An implicit 'all-00' nonce is as good as any.



          BTW: AES-GCM also uses the nonce as a part of the transform that generates the integrity tag; however, that addition does not complicate the fact that an all-00 nonce is fine, as long as you use the key once.






          share|improve this answer









          $endgroup$




          Am I missing anything?




          No, you are not; if you use a key only once, that is, to encrypt a single message, and never use it to encrypt anything else, then it doesn't matter what nonce you use. An implicit 'all-00' nonce is as good as any.



          BTW: AES-GCM also uses the nonce as a part of the transform that generates the integrity tag; however, that addition does not complicate the fact that an all-00 nonce is fine, as long as you use the key once.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 14 at 22:57









          ponchoponcho

          94.5k2151248




          94.5k2151248











          • $begingroup$
            I'm not sure that this is entirely correct, due to the risk of multi-target attacks on AES128.
            $endgroup$
            – forest
            Apr 15 at 8:04

















          • $begingroup$
            I'm not sure that this is entirely correct, due to the risk of multi-target attacks on AES128.
            $endgroup$
            – forest
            Apr 15 at 8:04
















          $begingroup$
          I'm not sure that this is entirely correct, due to the risk of multi-target attacks on AES128.
          $endgroup$
          – forest
          Apr 15 at 8:04





          $begingroup$
          I'm not sure that this is entirely correct, due to the risk of multi-target attacks on AES128.
          $endgroup$
          – forest
          Apr 15 at 8:04












          1












          $begingroup$

          Does your random generator guarantee (with sufficient confidence) that it won't generate the same random key a second time?



          As you correctly stated, as long as the same nonce and key are never re-used, everything is fine. But a randomly generated key does not by itself have such an assurance.



          There are two simple ways you can take:



          a) accept the risk. Make a quick calculation based on your RNG what the probability is that a key will be repeated and then decide that this chance is acceptable (or not).



          b) instead of using a zero nonce, use a simple counter. That's what many implementations actually do. The nonce can be predictable, that's ok.



          The decision in a) largely depends on the number of messages you are going to send. If the number is low, the risk is most likely acceptable. If we're talking millions-plus messages, you might find the probability of an identical key (remember the birthday paradox!) too high for comfort.






          share|improve this answer









          $endgroup$












          • $begingroup$
            The advantage of using a fixed nonce, is that you don't need to transmit it or store it. I presume this is enough of an advantage for the OP.
            $endgroup$
            – Martin Bonner
            Apr 15 at 9:52










          • $begingroup$
            @MartinBonner You can usually derive the nonce from the same master secret that the key is derived from.
            $endgroup$
            – forest
            Apr 15 at 9:53










          • $begingroup$
            @MartinBonner - as written: weigh the advantage against the risk and make a decision. The OP doesn't specify his use case, which makes it difficult to be specific on the threat level.
            $endgroup$
            – Tom
            Apr 15 at 9:56










          • $begingroup$
            Good reminder. I can't use a counter since there is no context saved from one encryption to the next. This is a standalone tool with no central server to house a counter. The only options I know of are fixed nonce (e.g. zeros) and random nonce. The key is 256 bits and encryption will be occasional. The generator is BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG on Windows and OpenSSL on Unix.
            $endgroup$
            – jnm2
            Apr 15 at 14:01











          • $begingroup$
            @jnm2 you could use a trivial counter, such as the timestamp (rounded to full seconds or even minutes, if both systems are time-synchronized) or even just the day-of-year (if not and the edge case of one message being not decryptable because it was sent at just the right second doesn't matter). This would already dramatically reduce the chances of a chance repetition.
            $endgroup$
            – Tom
            Apr 15 at 18:44















          1












          $begingroup$

          Does your random generator guarantee (with sufficient confidence) that it won't generate the same random key a second time?



          As you correctly stated, as long as the same nonce and key are never re-used, everything is fine. But a randomly generated key does not by itself have such an assurance.



          There are two simple ways you can take:



          a) accept the risk. Make a quick calculation based on your RNG what the probability is that a key will be repeated and then decide that this chance is acceptable (or not).



          b) instead of using a zero nonce, use a simple counter. That's what many implementations actually do. The nonce can be predictable, that's ok.



          The decision in a) largely depends on the number of messages you are going to send. If the number is low, the risk is most likely acceptable. If we're talking millions-plus messages, you might find the probability of an identical key (remember the birthday paradox!) too high for comfort.






          share|improve this answer









          $endgroup$












          • $begingroup$
            The advantage of using a fixed nonce, is that you don't need to transmit it or store it. I presume this is enough of an advantage for the OP.
            $endgroup$
            – Martin Bonner
            Apr 15 at 9:52










          • $begingroup$
            @MartinBonner You can usually derive the nonce from the same master secret that the key is derived from.
            $endgroup$
            – forest
            Apr 15 at 9:53










          • $begingroup$
            @MartinBonner - as written: weigh the advantage against the risk and make a decision. The OP doesn't specify his use case, which makes it difficult to be specific on the threat level.
            $endgroup$
            – Tom
            Apr 15 at 9:56










          • $begingroup$
            Good reminder. I can't use a counter since there is no context saved from one encryption to the next. This is a standalone tool with no central server to house a counter. The only options I know of are fixed nonce (e.g. zeros) and random nonce. The key is 256 bits and encryption will be occasional. The generator is BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG on Windows and OpenSSL on Unix.
            $endgroup$
            – jnm2
            Apr 15 at 14:01











          • $begingroup$
            @jnm2 you could use a trivial counter, such as the timestamp (rounded to full seconds or even minutes, if both systems are time-synchronized) or even just the day-of-year (if not and the edge case of one message being not decryptable because it was sent at just the right second doesn't matter). This would already dramatically reduce the chances of a chance repetition.
            $endgroup$
            – Tom
            Apr 15 at 18:44













          1












          1








          1





          $begingroup$

          Does your random generator guarantee (with sufficient confidence) that it won't generate the same random key a second time?



          As you correctly stated, as long as the same nonce and key are never re-used, everything is fine. But a randomly generated key does not by itself have such an assurance.



          There are two simple ways you can take:



          a) accept the risk. Make a quick calculation based on your RNG what the probability is that a key will be repeated and then decide that this chance is acceptable (or not).



          b) instead of using a zero nonce, use a simple counter. That's what many implementations actually do. The nonce can be predictable, that's ok.



          The decision in a) largely depends on the number of messages you are going to send. If the number is low, the risk is most likely acceptable. If we're talking millions-plus messages, you might find the probability of an identical key (remember the birthday paradox!) too high for comfort.






          share|improve this answer









          $endgroup$



          Does your random generator guarantee (with sufficient confidence) that it won't generate the same random key a second time?



          As you correctly stated, as long as the same nonce and key are never re-used, everything is fine. But a randomly generated key does not by itself have such an assurance.



          There are two simple ways you can take:



          a) accept the risk. Make a quick calculation based on your RNG what the probability is that a key will be repeated and then decide that this chance is acceptable (or not).



          b) instead of using a zero nonce, use a simple counter. That's what many implementations actually do. The nonce can be predictable, that's ok.



          The decision in a) largely depends on the number of messages you are going to send. If the number is low, the risk is most likely acceptable. If we're talking millions-plus messages, you might find the probability of an identical key (remember the birthday paradox!) too high for comfort.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 15 at 7:49









          TomTom

          24716




          24716











          • $begingroup$
            The advantage of using a fixed nonce, is that you don't need to transmit it or store it. I presume this is enough of an advantage for the OP.
            $endgroup$
            – Martin Bonner
            Apr 15 at 9:52










          • $begingroup$
            @MartinBonner You can usually derive the nonce from the same master secret that the key is derived from.
            $endgroup$
            – forest
            Apr 15 at 9:53










          • $begingroup$
            @MartinBonner - as written: weigh the advantage against the risk and make a decision. The OP doesn't specify his use case, which makes it difficult to be specific on the threat level.
            $endgroup$
            – Tom
            Apr 15 at 9:56










          • $begingroup$
            Good reminder. I can't use a counter since there is no context saved from one encryption to the next. This is a standalone tool with no central server to house a counter. The only options I know of are fixed nonce (e.g. zeros) and random nonce. The key is 256 bits and encryption will be occasional. The generator is BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG on Windows and OpenSSL on Unix.
            $endgroup$
            – jnm2
            Apr 15 at 14:01











          • $begingroup$
            @jnm2 you could use a trivial counter, such as the timestamp (rounded to full seconds or even minutes, if both systems are time-synchronized) or even just the day-of-year (if not and the edge case of one message being not decryptable because it was sent at just the right second doesn't matter). This would already dramatically reduce the chances of a chance repetition.
            $endgroup$
            – Tom
            Apr 15 at 18:44
















          • $begingroup$
            The advantage of using a fixed nonce, is that you don't need to transmit it or store it. I presume this is enough of an advantage for the OP.
            $endgroup$
            – Martin Bonner
            Apr 15 at 9:52










          • $begingroup$
            @MartinBonner You can usually derive the nonce from the same master secret that the key is derived from.
            $endgroup$
            – forest
            Apr 15 at 9:53










          • $begingroup$
            @MartinBonner - as written: weigh the advantage against the risk and make a decision. The OP doesn't specify his use case, which makes it difficult to be specific on the threat level.
            $endgroup$
            – Tom
            Apr 15 at 9:56










          • $begingroup$
            Good reminder. I can't use a counter since there is no context saved from one encryption to the next. This is a standalone tool with no central server to house a counter. The only options I know of are fixed nonce (e.g. zeros) and random nonce. The key is 256 bits and encryption will be occasional. The generator is BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG on Windows and OpenSSL on Unix.
            $endgroup$
            – jnm2
            Apr 15 at 14:01











          • $begingroup$
            @jnm2 you could use a trivial counter, such as the timestamp (rounded to full seconds or even minutes, if both systems are time-synchronized) or even just the day-of-year (if not and the edge case of one message being not decryptable because it was sent at just the right second doesn't matter). This would already dramatically reduce the chances of a chance repetition.
            $endgroup$
            – Tom
            Apr 15 at 18:44















          $begingroup$
          The advantage of using a fixed nonce, is that you don't need to transmit it or store it. I presume this is enough of an advantage for the OP.
          $endgroup$
          – Martin Bonner
          Apr 15 at 9:52




          $begingroup$
          The advantage of using a fixed nonce, is that you don't need to transmit it or store it. I presume this is enough of an advantage for the OP.
          $endgroup$
          – Martin Bonner
          Apr 15 at 9:52












          $begingroup$
          @MartinBonner You can usually derive the nonce from the same master secret that the key is derived from.
          $endgroup$
          – forest
          Apr 15 at 9:53




          $begingroup$
          @MartinBonner You can usually derive the nonce from the same master secret that the key is derived from.
          $endgroup$
          – forest
          Apr 15 at 9:53












          $begingroup$
          @MartinBonner - as written: weigh the advantage against the risk and make a decision. The OP doesn't specify his use case, which makes it difficult to be specific on the threat level.
          $endgroup$
          – Tom
          Apr 15 at 9:56




          $begingroup$
          @MartinBonner - as written: weigh the advantage against the risk and make a decision. The OP doesn't specify his use case, which makes it difficult to be specific on the threat level.
          $endgroup$
          – Tom
          Apr 15 at 9:56












          $begingroup$
          Good reminder. I can't use a counter since there is no context saved from one encryption to the next. This is a standalone tool with no central server to house a counter. The only options I know of are fixed nonce (e.g. zeros) and random nonce. The key is 256 bits and encryption will be occasional. The generator is BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG on Windows and OpenSSL on Unix.
          $endgroup$
          – jnm2
          Apr 15 at 14:01





          $begingroup$
          Good reminder. I can't use a counter since there is no context saved from one encryption to the next. This is a standalone tool with no central server to house a counter. The only options I know of are fixed nonce (e.g. zeros) and random nonce. The key is 256 bits and encryption will be occasional. The generator is BCryptGenRandom with BCRYPT_USE_SYSTEM_PREFERRED_RNG on Windows and OpenSSL on Unix.
          $endgroup$
          – jnm2
          Apr 15 at 14:01













          $begingroup$
          @jnm2 you could use a trivial counter, such as the timestamp (rounded to full seconds or even minutes, if both systems are time-synchronized) or even just the day-of-year (if not and the edge case of one message being not decryptable because it was sent at just the right second doesn't matter). This would already dramatically reduce the chances of a chance repetition.
          $endgroup$
          – Tom
          Apr 15 at 18:44




          $begingroup$
          @jnm2 you could use a trivial counter, such as the timestamp (rounded to full seconds or even minutes, if both systems are time-synchronized) or even just the day-of-year (if not and the edge case of one message being not decryptable because it was sent at just the right second doesn't matter). This would already dramatically reduce the chances of a chance repetition.
          $endgroup$
          – Tom
          Apr 15 at 18:44

















          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%2f68774%2fcan-a-zero-nonce-be-safely-used-with-aes-gcm-if-the-key-is-random-and-never-used%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

          getting Checkpoint VPN SSL Network Extender working in the command lineHow to connect to CheckPoint VPN on Ubuntu 18.04LTS?Will the Linux ( red-hat ) Open VPNC Client connect to checkpoint or nortel VPN gateways?VPN client for linux machine + support checkpoint gatewayVPN SSL Network Extender in FirefoxLinux Checkpoint SNX tool configuration issuesCheck Point - Connect under Linux - snx + OTPSNX VPN Ububuntu 18.XXUsing Checkpoint VPN SSL Network Extender CLI with certificateVPN with network manager (nm-applet) is not workingWill the Linux ( red-hat ) Open VPNC Client connect to checkpoint or nortel VPN gateways?VPN client for linux machine + support checkpoint gatewayImport VPN config files to NetworkManager from command lineTrouble connecting to VPN using network-manager, while command line worksStart a VPN connection with PPTP protocol on command linestarting a docker service daemon breaks the vpn networkCan't connect to vpn with Network-managerVPN SSL Network Extender in FirefoxUsing Checkpoint VPN SSL Network Extender CLI with certificate

          Cannot Extend partition with GParted The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) 2019 Community Moderator Election ResultsCan't increase partition size with GParted?GParted doesn't recognize the unallocated space after my current partitionWhat is the best way to add unallocated space located before to Ubuntu 12.04 partition with GParted live?I can't figure out how to extend my Arch home partition into free spaceGparted Linux Mint 18.1 issueTrying to extend but swap partition is showing as Unknown in Gparted, shows proper from fdiskRearrange partitions in gparted to extend a partitionUnable to extend partition even though unallocated space is next to it using GPartedAllocate free space to root partitiongparted: how to merge unallocated space with a partition

          Marilyn Monroe Ny fiainany manokana | Jereo koa | Meny fitetezanafanitarana azy.