>From: Greg Rose <[EMAIL PROTECTED]> >Sent: Jun 14, 2005 2:54 PM >To: EKR <[EMAIL PROTECTED]> >Cc: Ian G <[EMAIL PROTECTED]>, cryptography@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: [EMAIL PROTECTED] --John Kelsey --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]