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

> -----Original Message-----
> From: cfrg-bounces@ietf.org [mailto:cfrg-bounces@ietf.org] On 
> Behalf Of David McGrew
> Sent: Tuesday, October 25, 2005 9:56 AM
> To: cfrg@ietf.org
> Subject: [Cfrg] Fwd: Hash-Based Key Derivation
> 
> FYI
> 
> Begin forwarded message:
> 
> > From: Russ Housley <housley@vigilsec.com>
> > Date: October 25, 2005 9:44:42 AM PDT
> > To: saag@mit.edu
> > 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
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
> 

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