expanding a password into many keys

[John Kelsey]

>From: Greg Rose <ggr at qualcomm.com>
>Sent: Jun 14, 2005 2:54 PM
>To: EKR <ekr at rtfm.com>
>Cc: Ian G <iang at systemics.com>, cryptography at metzdowd.com
>Subject: Re: expanding a password into many keys

...
>You know, the proof that HMAC is a good MAC requires that the
>*compression function* of the underlying hash is good. And for almost
>all applications like this one, both the input password and the
>sequence number, tag name, or whatever the second input is, all fit
>into a single compression function block.

Actually, there are quite a few attacks on these schemes that amount
to messing up that property--getting the message to span multiple
blocks (as with the length extension attacks).  The other thing that
any direct use of a crypto primitive can't help with is "sliding" data
between fields.  If you don't encode your fields in some parseable way
before feeding them into the hash/MAC/block cipher/whatever, you get
these weird attacks where I either request key "XXX" with optional
additional string "Y", or I request key "XX" with optional additional
string "XY", and I get the same result.  Usually this doesn't lead to
a practical attack, but it puts an extra burden on the engineer using
the KDF, since he or she had better understand this attack and make
sure it doesn't apply.  Adams, Kramer, Mister, and Zucherato have a
recent paper pointing out a bunch of these problems with widely used
KDFs.  I think of these as analogous to the length-extension property
of hash functions or the complementation property of DES--it doesn't
keep the crypto mechanism from being used securely, but it does make
the job of an engineer trying to use it needlessly more complicated.  

>Greg Rose                                    INTERNET: ggr at qualcomm.com

--John Kelsey

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com