Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...

[David Jacobson <[e-mail]>]

In engineering, we like to be able to think of things as black boxes 
with specifications.  If you follow the rules in the specification, it 
works properly.

The problem here is that HMAC fails to do this.  If you use HMAC with a 
key larger that the input block size (allowed), and you reveal the hash 
of the key (a la original /etc/password), you can lose security.

My suggestion would be to add wording to the specification that says ( 
a) that use of keys larger than the input block size is discouraged, and 
(b) if the keys larger than the input block size are used, the H(K) is 
also sensitive and must be protected with the same diligence as the key 
would be protected.

     --David Jacobson


On 2/10/17 5:23 AM, Dang, Quynh (Fed) wrote:
> See my discussion below.
>
> From: David Jacobson <[e-mail] 
> <mailto:[e-mail]>>
> Date: Friday, February 10, 2017 at 12:27 AM
> To: 'Quynh' <[e-mail] <mailto:[e-mail]>>, Randal 
> Atkinson <[e-mail] 
> <mailto:[e-mail]>>, Michael StJohns 
> <[e-mail] <mailto:[e-mail]>>, "Paterson, 
> Kenny" <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>
> Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
>
>     See interleaved comment.
>
>     On 2/8/17 5:31 AM, Dang, Quynh (Fed) wrote:
>>
>>     Randal, Michael and many others,
>>
>>
>>     Thank you for your suggestions.
>>
>>
>>     Kenny,
>>
>>
>>     Thank you for your discussion email.
>>
>>
>>     We are thinking about what would be the best option for HMAC.
>>      Some technical possibilities are below.
>>
>>
>>     1) Don't change the HMAC spec.
>>
>>
>>     Ask a HMAC key always to have a fixed length such as HMAC-SHA256
>>     having 256-bit key. Which means that all protocols using
>>     HMAC-SHA256 use 256-bit keys.
>>
>>     If each protocol uses a different key length, then the issue
>>     would still exist across protocols. I don't know if this is a
>>     practical security problem, but it seems like a problem that
>>     should be avoided.
>>
>>     Should ask HMAC keys to be processed/produced by a hash function
>>     or another PRF always.
>
>     I don't see the need or even desirability for this, assuming you
>     ask each protocol to use a fixed (for that protocol) key length. 
>     (That was the line above.)
>
>     For an attacker to find two messages with the same HMAC, not
>     knowing the key, he would have to find a collision in the first
>     stage, not knowing the first block.  And if you add an extra hash,
>     you are only making it easier.  He has to get a collision in the
>     pre-hash, where he knows everything.
>
>
> Of course, the hash function must be a collision-resistant one.
>
> The reason for hashing the key or the key is produced by a good hash 
> function or a PRF is to make the key become more of a "random key" as 
> you know HMAC is a PRF as keys are selected randomly, not selectively.
>
> Quynh.
>
>
>
>
>
>        --David Jacobson
>>
>>     This option does not break interoperability of  the current HMAC
>>     implementations.
>>
>>     2) Change the HMAC Spec.
>>
>>     a) Always hash the key regardless of its length, then perform
>>     step 3 in FIPS 198.
>>     b) Use a hash-based KDF (not HKDF) to produce B bits from the
>>     key, then go to step 4 in the FIPS. (bad for performance).
>>     c) Require key < B, then do multi-rate padding 10* to make the
>>     key B bits, then go to step 4 in the FIPS. (good for performance).
>>
>>     We recommend the use of KMAC in SP 800-185. KMAC's security is
>>     solid and proven, and it has great performance. Code to implement
>>     KMAC can be reused to implement many other
>>     Keccak-derived symmetric-key crypto functions.
>>
>>     Regards,
>>     Quynh.
>>     ------------------------------------------------------------------------
>>     *From:* Randal Atkinson <[e-mail]>
>>     *Sent:* Tuesday, February 7, 2017 12:34 PM
>>     *To:* Dang, Quynh (Fed)
>>     *Cc:* Randal Atkinson
>>     *Subject:* Aside Re: [CFRG] erratum for hmac ...
>>
>>     One option available to NIST would be for NIST to open comments
>>     on updating FIPS 198-1, even if opening comments on that now/soon
>>     would be earlier than NIST ordinarily would do so.
>>
>>     Given how long it takes to move from an approved FIPS revision
>>     to widespread US Government deployment, if data exists from
>>     Kenny P and/or others that merits an update, then starting sooner
>>     would not be a bad thing for the USG.
>>
>>     Cheers,
>>
>>     Ran Atkinson
>>
>>     --------------------------------
>>     Randal Atkinson, PhD
>>     Cheltenham Research for NRL 5520
>>     [e-mail]
>>
>>
>>
>>     _______________________________________________
>>     Cfrg mailing list
>>     [e-mail]://www.irtf.org/mailman/listinfo/cfrg
>
>