RE: [Cfrg] Fwd: Hash-Based Key Derivation

["Simon Blake-Wilson" <[e-mail]>]

Is it really true that you can build a KDF like this based on standard
assumptions about a MAC?

To my mind, the key goal behind a KDF is to take an unpredictable value
(the shared secret)(ie. A value an attacker can't guess) and turn it into
a pseudorandom value (the session key)(ie a value an attacker can't
distinguish from a random value). MACs are by design secure only if the
key is pseudorandom, aren't they?

It's amazing to me that no formal theory of KDF design seems to have
emerged yet, despite many years of use in practice.

Best regards. Simon

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Scott Fluhrer
> Sent: Tuesday, October 25, 2005 1:49 PM
> To: 'David McGrew'; [e-mail]
> Subject: RE: [Cfrg] Fwd: Hash-Based Key Derivation
> 
> 
>  
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of David McGrew
> > Sent: Tuesday, October 25, 2005 9:56 AM
> > To: [e-mail]
> > Subject: [Cfrg] Fwd: Hash-Based Key Derivation
> > 
> > FYI
> > 
> > Begin forwarded message:
> > 
> > > From: Russ Housley <[e-mail]>
> > > Date: October 25, 2005 9:44:42 AM PDT
> > > To: [e-mail]
> > > Subject: Hash-Based Key Derivation
> > >
> > >
> > > I wanted call your attention to an individual draft on
> > "Hash-Based Key
> > > Derivation."
> > >
> > >       
> http://www.ietf.org/internet-drafts/draft-dang-nistkdf-00.txt
> > >
> > > This draft specifies a soon to be NIST-approved algorithm
> > for deriving
> > > secret key material from a shared secret using a hash
> > algorithm.  This
> > > algorithm is in the NIST draft SP 800-56.
> > >
> > > I encourage review and comment.  If you have concerns with this
> > > document, then the concerns probably apply to he NIST draft SP
> > > 800-56 document too.
> 
> Well, one concern I have is that the strength of this hash 
> derivation function depends on the difficulty of recovering a 
> preimage of a hash function given a large set of hashes of 
> related preimages.  If the attacker can recover that, then he 
> could recover the secret value (assuming he is able to 
> somehow get his hands on a number of derived keying 
> materials). This is a nonstandard assumption on hash 
> functions, and one that to the best of my knowledge has never 
> been analyzed.
> 
> I would suggest instead is that they construct the hash 
> derivation function out of a MAC (such as HMAC).  That is, 
> instead of doing setp 4.a:
> 
>         a. Compute Hash-i = H (counter || SV {|| algorithmID} || 
>           contextID {|| SharedInfo}). 
> 
> they instead do:
> 
>         a. Compute Mac-i = MAC(SV, counter {|| algorithmID} ||
>           contextID {|| SharedInfo})
> 
> (where the first parameter to the MAC is the key).  By doing 
> this, we are relying on the designed property of the MAC 
> (which implies that you cannot recover the key even with a 
> large number of MAC/Plaintext pairs).
> 
> > >
> > > I am considering sponsoring this document as an
> > Informational RFC.   
> > > Please let me know if you have any concerns with this
> > proposed action.
> > >
> > > Thanks,
> > >   Russ
> > 
> > _______________________________________________
> > Cfrg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/cfrg
> > 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/cfrg
> 

_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg