Do AEADs also authenticate the nonce?












4












$begingroup$


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:




  1. Let's say I'm using XChaCha20-Poly1305 with a shared secret key.

  2. I generate the nonce/IV by concatenating an 8-byte timestamp and a 16-byte random value.

  3. I send concat(nonce, ciphertext, auth_tag)

  4. 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?










share|improve this question









$endgroup$

















    4












    $begingroup$


    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:




    1. Let's say I'm using XChaCha20-Poly1305 with a shared secret key.

    2. I generate the nonce/IV by concatenating an 8-byte timestamp and a 16-byte random value.

    3. I send concat(nonce, ciphertext, auth_tag)

    4. 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?










    share|improve this question









    $endgroup$















      4












      4








      4





      $begingroup$


      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:




      1. Let's say I'm using XChaCha20-Poly1305 with a shared secret key.

      2. I generate the nonce/IV by concatenating an 8-byte timestamp and a 16-byte random value.

      3. I send concat(nonce, ciphertext, auth_tag)

      4. 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?










      share|improve this question









      $endgroup$




      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:




      1. Let's say I'm using XChaCha20-Poly1305 with a shared secret key.

      2. I generate the nonce/IV by concatenating an 8-byte timestamp and a 16-byte random value.

      3. I send concat(nonce, ciphertext, auth_tag)

      4. 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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Dec 29 '18 at 5:02









      Kannan GoundanKannan Goundan

      1485




      1485






















          1 Answer
          1






          active

          oldest

          votes


















          4












          $begingroup$

          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.






          share|improve this answer











          $endgroup$













          • $begingroup$
            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.
            $endgroup$
            – Kannan Goundan
            Dec 29 '18 at 6:11










          • $begingroup$
            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 :)
            $endgroup$
            – Maarten Bodewes
            Dec 29 '18 at 6:57













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


          }
          });














          draft saved

          draft discarded


















          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









          4












          $begingroup$

          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.






          share|improve this answer











          $endgroup$













          • $begingroup$
            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.
            $endgroup$
            – Kannan Goundan
            Dec 29 '18 at 6:11










          • $begingroup$
            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 :)
            $endgroup$
            – Maarten Bodewes
            Dec 29 '18 at 6:57


















          4












          $begingroup$

          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.






          share|improve this answer











          $endgroup$













          • $begingroup$
            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.
            $endgroup$
            – Kannan Goundan
            Dec 29 '18 at 6:11










          • $begingroup$
            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 :)
            $endgroup$
            – Maarten Bodewes
            Dec 29 '18 at 6:57
















          4












          4








          4





          $begingroup$

          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.






          share|improve this answer











          $endgroup$



          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 29 '18 at 7:25

























          answered Dec 29 '18 at 5:42









          Maarten BodewesMaarten Bodewes

          53.6k677193




          53.6k677193












          • $begingroup$
            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.
            $endgroup$
            – Kannan Goundan
            Dec 29 '18 at 6:11










          • $begingroup$
            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 :)
            $endgroup$
            – Maarten Bodewes
            Dec 29 '18 at 6:57




















          • $begingroup$
            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.
            $endgroup$
            – Kannan Goundan
            Dec 29 '18 at 6:11










          • $begingroup$
            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 :)
            $endgroup$
            – Maarten Bodewes
            Dec 29 '18 at 6:57


















          $begingroup$
          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.
          $endgroup$
          – Kannan Goundan
          Dec 29 '18 at 6:11




          $begingroup$
          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.
          $endgroup$
          – Kannan Goundan
          Dec 29 '18 at 6:11












          $begingroup$
          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 :)
          $endgroup$
          – Maarten Bodewes
          Dec 29 '18 at 6:57






          $begingroup$
          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 :)
          $endgroup$
          – Maarten Bodewes
          Dec 29 '18 at 6:57




















          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%2f66143%2fdo-aeads-also-authenticate-the-nonce%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

          Monofisismo

          Angular Downloading a file using contenturl with Basic Authentication

          Olmecas