"Dan Harkins" <dharkins@xxxxxxxxxx> writes: > Hi Simon, > > On Mon, May 3, 2010 3:32 pm, Simon Josefsson wrote: >> "Dan Harkins" <dharkins@xxxxxxxxxx> writes: >> >>> Issues with prf and prf+ >>> >>> - In sections 5.1 and 5.2 the password is passed directly into prf+ >>> (which is the same as the one from RFC 2409 and uses HMAC-SHA1 or >>> HMAC-SHA256). This is a key derivation type function and assumes it >>> has been passed a key having properties, like a uniformly random >>> distribution, that a low-entropy password does not have. >>> >>> I recommend deriving a key for Encr() in a 2-step process using and >>> "extractor and expander" KDF. It might also be good to mention that >>> the first, leftmost, length-of-cipher-key bits are used as the >>> cipher >>> key. >> >> I agree with your comments. However would not salting and an iterative >> design, as provided by PKCS#5 PBKDF2, be more appropriate than >> extract-and-expand? See section 4 of the extract-and-expand document to >> see why it is not always appropriate for passwords. > > I don't believe so. PBKDF2 does 1000 iterations of HMAC-ing to increase > the work factor of brute force guessing the password. This is useful when > the protocol using the password is not based on a zero knowledge proof. > In this case it is, and an active attacker gets only one guess at the > password per attack (a passive attacker gets zero guesses) and that > would be the case even if the password is used directly as a "key" to > an HMAC-based KDF. > > Section 4 of the extract-and-expand document says, "In the case of > password-based KDFs, a main goal is to slow down dictionary attacks using > two ingredients: a salt value and the intentional slowing of the key > derivation computation. HKDF naturally accommodates the use of salt; > however, a slowing down mechanism is not part of this specification." > But in the case of EAP-EKE a dictionary attack is foiled outright by the > protocol. There is no need to use a KDF to slow one down. Right. I agree. >>> Issues with elliptic curves cryptography >> >> This raises a question. What is the patent status of the technologies >> used by this document? I recall concerns with some non-HMAC-based >> password based authentication protocols. > > I believe it has been submitted: > > https://datatracker.ietf.org/ipr/1071/ Thanks for the pointer. /Simon _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf