How would a preimage attack matter in this case? Even if I could pull one off, (i.e. guess the contents of the entropy pool based on the output of the hash), we perturb it again right afterwards. Furthermore, how would this be any different than choosing just the upper or lower half?
And again, is this *ever* used directly, or is it simply the input to the RC4 generator? In which case, pulling off a preimage attack would be essentially miraculous. In any case, if there is not a good reason to keep it (since it's not standard practice), why not eliminate it? I just don't see what it accomplishes. Sure, it may be worth investigating another hash function. Maybe even another stream cipher for use with the PRNG, but we should be clear about what the requirements for such a hash / cipher should be. Certainly, speed is a factor for both. RC4 is hella fast, but since we need to dump k*256 bytes of keystream every time, something else may end up being faster. Lack of a distinguisher in the stream cipher would also seem to be important, of course, given the application. Set-up time matters for the stream cipher, since we routinely set up new instances for large random requests, and so on. Anyway, I'm muttering aloud now. In the meantime, is there any reason to keep the fold? On Tue, Dec 28, 2010 at 1:48 AM, Damien Miller <[email protected]> wrote: > On Mon, 27 Dec 2010, Kjell Wooding wrote: > > > The OpenBSD random number subsystem uses an in-kernel entropy pool. This > > data isn't used directly. When entropy is requested, the contents of the > > pool are hashed with MD5, and the massaged output used to seed an RC4 > PRNG. > > > > In looking at the code, however, I notice we actually fold the MD5 output > in > > half. From extract_entropy(): > > > > MD5Final(buffer, &tmp); > > > > /* > > * In case the hash function has some recognizable > > * output pattern, we fold it in half. > > */ > > buffer[0] ^= buffer[15]; > > buffer[1] ^= buffer[14]; > > buffer[2] ^= buffer[13]; > > buffer[3] ^= buffer[12]; > > buffer[4] ^= buffer[11]; > > buffer[5] ^= buffer[10]; > > buffer[6] ^= buffer[ 9]; > > buffer[7] ^= buffer[ 8]; > > > > /* Copy data to destination buffer */ > > bcopy(buffer, buf, i); > > nbytes -= i; > > buf += i; > > > > My question: Why? What exactly are we protecting against, and is this > really > > protection? (the comment indicates "some recognizable output pattern, but > > that means little to me as is) Can we really be sure it doesn't make > things > > worse? > > I think it is intended to make preimage attacks more difficult. > > > Is this done elsewhere, or is it our particular brand of voodoo? > > I'm not aware of it being done elsewhere. Usually the recommendation is > to truncate, rather than fold hash output. > > IMO we should reassess the output hash. Something like Whirlpool might be > significantly faster given its large block size. > > -d
