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

["Dang, Quynh (Fed)" <[e-mail]>]

From: David Jacobson <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 10, 2017 at 10:50 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 ...

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.

In our guildlines, we require to keep K0 as secret key.



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


Thank you,
Quynh.




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]><mailto:[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]<mailto:[e-mail]>




_______________________________________________
Cfrg mailing list
[e-mail]<mailto:[e-mail]>https://www.irtf.org/mailman/listinfo/cfrg