Thor Lancelot Simon wrote: > I note that GBDE uses a number of algorithms in ways that are not > consistent with their design purposes. For instance, it truncates a > non-keyed hash (SHA512); the fact that this is not necessarily a > good idea is one of the major motivators for the design of HMAC.
This is a widely accepted practice. RFC 2631 generates keys this way, using SHA-1. And aren't most /dev/random implementations outputting SHA-1 hashes? Users are expected to treat the output as a stream of random bits, so in most cases truncated hashes are used. It may not be a good idea, but Poul-Henning Kamp has not made a radical design decision here. Also, a problem with a keyed hash may not be a problem when generating key material from a secret. Let's say we use this as a keyed hash function: SHA-1(k || p). (k the key, p the plaintext to be authenticated.) This has the bad property that the attacker can easily forge signatures of the form SHA-1(k || p || x) where x is attacker supplied material. (The attacker does not need to know the value of k.) But this is a reasonable way to generate key material to drive a cipher. I will note that Kamp's design differs from RFC 2631's approach. Section 7.1 ("From passphrase to master key") of his paper describes the generation of three keys from one hash. RFC 2631 would generate these keys by doing three hash computations with a counter used to vary the input slightly and using the leftmost bits of the result. Intuitively, I like RFC 2631's approach better, but it would be interesting to know if there's a better reason to do it that way. Peter _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"