Re: [Cfrg] erratum for hmac what do we think...

Inline.

On 2/1/2017 9:24 PM, Stephen Farrell wrote:
> Hiya,
>
> There's an erratum posted for hmac [1] where I'd be
> interested in what folks here think.
>
> I'm unsure if this is a real problem, esp given that
> there are I guess a lot of implementations.
>
> And even if it were a real problem, I'm not sure we'd
> want that fix.

I think it's probably a bogus erratum.   Basically, there are a lot of 
ways to calculate check values for secret keys - hashing the key as 
suggested in this report - is not the one I would suggest for HMAC 
keys.  Instead, doing an HMAC over a known value - HMAC (K, 
'0000000000000000'b) to get a check value might be a better choice.

I think this report boils down to a "I came up with a way to use this 
mechanism in a way that may have security weaknesses".  If he'd said 
that IPSEC uses this and its bad, then I'd say the report was actionable 
- with respect to IPSEC.  As it stands, I'd reject the report.  
Alternately, I might say "Applications MUST not use keys longer than 8 
bytes, where the hash of the key (with the same hash as used in the 
HMAC) is also used as a public value (a key identifier or check value)".

And given that AFAICT RFC 2104 was really a feeder document for the 
NIST  FIPS 198-1 submission  (compare if you will the abstract of the 
RFC with the NIST document Introduction), I would suggest that any 
changes to HMAC be fed in to NIST rather than being accepted as updates 
to this informational document.

Mike

>
> Opinions welcome...
>
> Thanks,
> S.
>
> [1]
> https://www.rfc-editor.org/errata_search.php?rfc=2104&eid=4809&rec_status=15&area_acronym=&errata_type=&wg_acronym=&submitter_name=&stream_name=&submit_date=&presentation=records
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg