Re: [PATCH,RFC] random: make fast_mix() honor its name

["Jörn Engel" <joern@logfs.org>]

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.

Jörn

--
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu