RE: [Cfrg] New Proofs for NMAC and HMAC: Security Without Collision-Resistance

["Blumenthal, Uri" <uri.blumenthal at intel.com>]

Hi David, 

>> One observation: this paper basically says that we were looking for
>> wrong properties! Collision resistance (strong or weak) is  
>> unnecessary: if the underlying compression function is a PRF then
>> keyed MAC is secure; and if it's not a PRF (Bellare proved that
>> a slightly weaker assumption is still OK) - then weak collision
>> resistance won't help.
>>
>> So when we specify requirements for crypto hash - what we really
>> want/need is Pseudo-Randomness. Then we can safely use it in key
>> derivation, and then keyed MAC is also secure.
>
> AFAICT, Mihir's work doesn't address the issue of whether or not
> NMAC or HMAC is a secure way of deriving symmetric keys from a
> Diffie-Hellman secret.

True. But *if* the construct is a PRF - and there's a good chance of it
if the underlying primitive is a PRF - then key derivation using that
construct to derive keys seems secure enough (yes I realize that DH
secret may have properties :-).

> The abstract describes the work as showing that the functions
> are good PRFs (or just good MACs) based on some different
> assumptions

Hmm... What I read from the paper is something different: in order to
have a good MAC one _has_ to start with a PRF as a compression function.
I don't see anything but assumption that SHA (or MDx) in fact _are_ PRFs
- just the statement that _if_ they are - not only HMAC is secure
(regardless of presence or absence of collision resistance), but also
key derivation applications. Consequently - if those hash function are
in fact _not_ PRFs, then not only key derivation shouldn't be done with
them - but also MACing may be insecure even using HMAC construct.

> ......... but a DH key derivation function can't be shown
> to be secure merely because it is a PRF.

Understand, though not quite. We can discuss this.

> Of course, this is not to suggest that HMAC is a bad KDF. 
> I suspect that it is a good one, but I just don't think
> that the work cited proves anything in that direction.

:-)

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg