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