[lkml]   [2013]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH,RFC] random: make fast_mix() honor its name
On Sat, 21 September 2013 17:41:18 -0400, Theodore Ts'o wrote:
> BTW, just to give another example of the difference between the mixing
> funtions, try compiling the following with and without ORIG_MIX defined...

Garbage in, garbage out again. If there is absolutely no randomness
in the input (all bits zero), my mixing function will simply shift the
pool. And because the shifting has a period of 128, there are only
128 possible pool states. Your mixing function is doing slightly
better, it effectively becomes an interrupt counter with a silly
output format.

But who cares? If there is absolutely no randomness in the input, you
have lost. That case isn't worth contemplating. The question is
whether any randomness present in the input will get accumulated.

Without the shifting, a single unpredictable bit on, say, the lowest
position of the timestamp will be xor'ed into the same pool bit every
time. The rest of the pool would always be predictable and the
resulting mixing function would clearly be bad.

With the shifting and using the same example, after 128 rounds every
bit of the pool is unpredictable. Job done, we can go home now. You
cannot achieve anything better than 128 unpredictable bits, no matter
how much you try.


Those who come seeking peace without a treaty are plotting.
-- Sun Tzu
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2013-09-23 00:21    [W:0.079 / U:1.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site