[17492] in cryptography@c2.net mail archive
Re: expanding a password into many keys
daemon@ATHENA.MIT.EDU (John Kelsey)
Wed Jun 15 09:36:22 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Wed, 15 Jun 2005 09:27:17 -0400 (GMT-04:00)
From: John Kelsey <kelsey.j@ix.netcom.com>
Reply-To: John Kelsey <kelsey.j@ix.netcom.com>
To: Greg Rose <ggr@qualcomm.com>, EKR <ekr@rtfm.com>
Cc: Ian G <iang@systemics.com>, cryptography@metzdowd.com
>From: Greg Rose <ggr@qualcomm.com>
>Sent: Jun 14, 2005 2:54 PM
>To: EKR <ekr@rtfm.com>
>Cc: Ian G <iang@systemics.com>, 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: ggr@qualcomm.com
--John Kelsey
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
