Do I understand HMAC-SHA-xxx and HMAC-SHA-xxx-yyy correctly?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












I've recently started looking at HMAC, and there a few things that I'm not 100% sure that I'm understanding correctly. Am I right about these three things?



  1. HMAC-SHA-xxx has an output length of xxx bits


  2. HMAC-SHA-xxx-yyy has an output length of yyy bits


  3. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bits of HMAC-SHA-xxx output.


If I am misunderstanding any of them, how so?










share|improve this question









New contributor




Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.























    up vote
    2
    down vote

    favorite












    I've recently started looking at HMAC, and there a few things that I'm not 100% sure that I'm understanding correctly. Am I right about these three things?



    1. HMAC-SHA-xxx has an output length of xxx bits


    2. HMAC-SHA-xxx-yyy has an output length of yyy bits


    3. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bits of HMAC-SHA-xxx output.


    If I am misunderstanding any of them, how so?










    share|improve this question









    New contributor




    Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





















      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      I've recently started looking at HMAC, and there a few things that I'm not 100% sure that I'm understanding correctly. Am I right about these three things?



      1. HMAC-SHA-xxx has an output length of xxx bits


      2. HMAC-SHA-xxx-yyy has an output length of yyy bits


      3. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bits of HMAC-SHA-xxx output.


      If I am misunderstanding any of them, how so?










      share|improve this question









      New contributor




      Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      I've recently started looking at HMAC, and there a few things that I'm not 100% sure that I'm understanding correctly. Am I right about these three things?



      1. HMAC-SHA-xxx has an output length of xxx bits


      2. HMAC-SHA-xxx-yyy has an output length of yyy bits


      3. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bits of HMAC-SHA-xxx output.


      If I am misunderstanding any of them, how so?







      hmac






      share|improve this question









      New contributor




      Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited 3 hours ago





















      New contributor




      Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 6 hours ago









      Jan

      133




      133




      New contributor




      Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Jan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          3
          down vote



          accepted











          1. HMAC-SHA-xxx has an output length of xxx bits



          That's right, the output of the HMAC function is identical to the output of the hash by default. This is obvious if you take the design of HMAC in consideration.




          1. HMAC-SHA-xxx-yyy has an output length of yyy bits



          Certainly. It has been defined that way in the venerable RFC 2104 - HMAC: Keyed-Hashing for Message Authentication, section 5: Truncated output.



          Not many implementations will allow you to specify the output size, so you may have to truncate yourself. Also note that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256).




          1. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bytes of HMAC-SHA-xxx output.



          Yes, you'd use the leftmost bits / bytes. yyy would be in bits, so you'd have to devide by 8 (and I would only allow multiples of 8 for yyy).




          Beware that the authors of the RFC talk about "recommend" and "propose" in section 5, so the implementation of HMAC-<hash>-yyy seems strictly optional.






          share|improve this answer


















          • 1




            What justifies "that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256)" ? I see no benefit compared to using full-width hash and truncating in the end, and never met that. Further, that would always reduce the amount of hashed data making it from the data hash of HMAC to the final hash; and, if the HMAC key is larger than 512-bit, that would get hashed to 224-bit rather than 256-bit as the key hash of HMAC, reducing the effective key size (admittedly, to a width that still seems large enough).
            – fgrieu
            1 hour ago











          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',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );






          Jan is a new contributor. Be nice, and check out our Code of Conduct.









           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f63251%2fdo-i-understand-hmac-sha-xxx-and-hmac-sha-xxx-yyy-correctly%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          3
          down vote



          accepted











          1. HMAC-SHA-xxx has an output length of xxx bits



          That's right, the output of the HMAC function is identical to the output of the hash by default. This is obvious if you take the design of HMAC in consideration.




          1. HMAC-SHA-xxx-yyy has an output length of yyy bits



          Certainly. It has been defined that way in the venerable RFC 2104 - HMAC: Keyed-Hashing for Message Authentication, section 5: Truncated output.



          Not many implementations will allow you to specify the output size, so you may have to truncate yourself. Also note that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256).




          1. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bytes of HMAC-SHA-xxx output.



          Yes, you'd use the leftmost bits / bytes. yyy would be in bits, so you'd have to devide by 8 (and I would only allow multiples of 8 for yyy).




          Beware that the authors of the RFC talk about "recommend" and "propose" in section 5, so the implementation of HMAC-<hash>-yyy seems strictly optional.






          share|improve this answer


















          • 1




            What justifies "that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256)" ? I see no benefit compared to using full-width hash and truncating in the end, and never met that. Further, that would always reduce the amount of hashed data making it from the data hash of HMAC to the final hash; and, if the HMAC key is larger than 512-bit, that would get hashed to 224-bit rather than 256-bit as the key hash of HMAC, reducing the effective key size (admittedly, to a width that still seems large enough).
            – fgrieu
            1 hour ago















          up vote
          3
          down vote



          accepted











          1. HMAC-SHA-xxx has an output length of xxx bits



          That's right, the output of the HMAC function is identical to the output of the hash by default. This is obvious if you take the design of HMAC in consideration.




          1. HMAC-SHA-xxx-yyy has an output length of yyy bits



          Certainly. It has been defined that way in the venerable RFC 2104 - HMAC: Keyed-Hashing for Message Authentication, section 5: Truncated output.



          Not many implementations will allow you to specify the output size, so you may have to truncate yourself. Also note that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256).




          1. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bytes of HMAC-SHA-xxx output.



          Yes, you'd use the leftmost bits / bytes. yyy would be in bits, so you'd have to devide by 8 (and I would only allow multiples of 8 for yyy).




          Beware that the authors of the RFC talk about "recommend" and "propose" in section 5, so the implementation of HMAC-<hash>-yyy seems strictly optional.






          share|improve this answer


















          • 1




            What justifies "that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256)" ? I see no benefit compared to using full-width hash and truncating in the end, and never met that. Further, that would always reduce the amount of hashed data making it from the data hash of HMAC to the final hash; and, if the HMAC key is larger than 512-bit, that would get hashed to 224-bit rather than 256-bit as the key hash of HMAC, reducing the effective key size (admittedly, to a width that still seems large enough).
            – fgrieu
            1 hour ago













          up vote
          3
          down vote



          accepted







          up vote
          3
          down vote



          accepted







          1. HMAC-SHA-xxx has an output length of xxx bits



          That's right, the output of the HMAC function is identical to the output of the hash by default. This is obvious if you take the design of HMAC in consideration.




          1. HMAC-SHA-xxx-yyy has an output length of yyy bits



          Certainly. It has been defined that way in the venerable RFC 2104 - HMAC: Keyed-Hashing for Message Authentication, section 5: Truncated output.



          Not many implementations will allow you to specify the output size, so you may have to truncate yourself. Also note that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256).




          1. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bytes of HMAC-SHA-xxx output.



          Yes, you'd use the leftmost bits / bytes. yyy would be in bits, so you'd have to devide by 8 (and I would only allow multiples of 8 for yyy).




          Beware that the authors of the RFC talk about "recommend" and "propose" in section 5, so the implementation of HMAC-<hash>-yyy seems strictly optional.






          share|improve this answer















          1. HMAC-SHA-xxx has an output length of xxx bits



          That's right, the output of the HMAC function is identical to the output of the hash by default. This is obvious if you take the design of HMAC in consideration.




          1. HMAC-SHA-xxx-yyy has an output length of yyy bits



          Certainly. It has been defined that way in the venerable RFC 2104 - HMAC: Keyed-Hashing for Message Authentication, section 5: Truncated output.



          Not many implementations will allow you to specify the output size, so you may have to truncate yourself. Also note that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256).




          1. If I have a function that generates HMAC-SHA-xxx output, then I can create a function that generates HMAC-SHA-xxx-yyy output simply by returning the first yyy bytes of HMAC-SHA-xxx output.



          Yes, you'd use the leftmost bits / bytes. yyy would be in bits, so you'd have to devide by 8 (and I would only allow multiples of 8 for yyy).




          Beware that the authors of the RFC talk about "recommend" and "propose" in section 5, so the implementation of HMAC-<hash>-yyy seems strictly optional.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 5 hours ago

























          answered 6 hours ago









          Maarten Bodewes

          49.7k569182




          49.7k569182







          • 1




            What justifies "that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256)" ? I see no benefit compared to using full-width hash and truncating in the end, and never met that. Further, that would always reduce the amount of hashed data making it from the data hash of HMAC to the final hash; and, if the HMAC key is larger than 512-bit, that would get hashed to 224-bit rather than 256-bit as the key hash of HMAC, reducing the effective key size (admittedly, to a width that still seems large enough).
            – fgrieu
            1 hour ago













          • 1




            What justifies "that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256)" ? I see no benefit compared to using full-width hash and truncating in the end, and never met that. Further, that would always reduce the amount of hashed data making it from the data hash of HMAC to the final hash; and, if the HMAC key is larger than 512-bit, that would get hashed to 224-bit rather than 256-bit as the key hash of HMAC, reducing the effective key size (admittedly, to a width that still seems large enough).
            – fgrieu
            1 hour ago








          1




          1




          What justifies "that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256)" ? I see no benefit compared to using full-width hash and truncating in the end, and never met that. Further, that would always reduce the amount of hashed data making it from the data hash of HMAC to the final hash; and, if the HMAC key is larger than 512-bit, that would get hashed to 224-bit rather than 256-bit as the key hash of HMAC, reducing the effective key size (admittedly, to a width that still seems large enough).
          – fgrieu
          1 hour ago





          What justifies "that using a standardized, truncated version of SHA-2 should be preferred (e.g. SHA-224 is already a truncated version of SHA-256)" ? I see no benefit compared to using full-width hash and truncating in the end, and never met that. Further, that would always reduce the amount of hashed data making it from the data hash of HMAC to the final hash; and, if the HMAC key is larger than 512-bit, that would get hashed to 224-bit rather than 256-bit as the key hash of HMAC, reducing the effective key size (admittedly, to a width that still seems large enough).
          – fgrieu
          1 hour ago











          Jan is a new contributor. Be nice, and check out our Code of Conduct.









           

          draft saved


          draft discarded


















          Jan is a new contributor. Be nice, and check out our Code of Conduct.












          Jan is a new contributor. Be nice, and check out our Code of Conduct.











          Jan is a new contributor. Be nice, and check out our Code of Conduct.













           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f63251%2fdo-i-understand-hmac-sha-xxx-and-hmac-sha-xxx-yyy-correctly%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Displaying single band from multi-band raster using QGIS

          How many registers does an x86_64 CPU actually have?