Subject: Re: SHA-2 based HMAC algorithm...

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Mar 2011 19:55:42 +1300

"Mark D. Baushke" <[email-masked]> writes:

>For what it is worth, if we are going to give a few mor options, addressing
>some of the other issues raised by NIST SP 800-131 might be wise.
>
>[...]

Hmm, are you sure you want to try and get all that in an RFC?  The amount of
bikeshedding this'll entail will be monumental, while just defining a few new
strings for SHA-256 to complement the existing SHA-1 ones should be fairly
quick.  I guess it depends on what the urgency is, the SHA-1 -> SHA-256 quick
fix could be done as a fast-path RFC and then the bikeshedding-magnet change-
other-bits-of-the-crypto could be done as a longer-term one.

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sat, 19 Mar 2011 01:00:05 -0700

Peter Gutmann <[email-masked]> writes:

> Hmm, are you sure you want to try and get all that in an RFC?  

I suppose RFC 4432 already has the rsa2048-sha256 covered and using
ECDH from RFC 5656 for KEX addresses the issues with DH not really
using sha256. Adding hmac-sha256 is likely going to be faster than
using AED_AES_128_GCM.

So, yes, it would be best to do the hmac-sha2 stuff first and let
RFCs 4432, 5647 and 5656 address the bit strength issues of NIST SP
800-131.

	-- Mark