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

Oops.  I made a mistake.  It is the key that is being hashed not the 
message.

But I still don't see where it helps.  An attacker does not choose the key.

Now there was this discussion about related keys they could generate the 
same output.  But if we fix the key to some protocol-specific value, 
then there is no easy way to get related keys that give the same 
output.  You would need to find a sort of double-collision where the 
hash internal state after the first block is the same for keyA ^ IPAD 
and keyB ^ IPAD and the internal state after the first block is the same 
for keyA ^ OPAD and keyB ^ OPAD.  This seems much harder than just 
finding a collision.

    --David

On 2/9/17 9:27 PM, David Jacobson wrote:
> 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.
>
>    --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 <randal.atkinson.ctr@nrl.navy.mil>
>> *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
>> randal.atkinson.ctr@nrl.navy.mil
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>
>