Re: [PATCH 4/5] tsc: wire up entropy generation function

["H. Peter Anvin" <hpa@zytor.com>]

On 06/13/2011 04:10 PM, Matt Mackall wrote:
> 
> Well the issue is that samples are going to be roughly aligned to some
> multiple of the bus frequency. If an interrupt occurs on bus cycle X,
> this code will be hit at roughly TSC cycle X*M+d.
> 
>> This is correct; at the very least I would multiply the low 32 bits of
>> the TSC with a 32-bit prime number before mixing.
> 
> This multiply doesn't actually accomplish anything. Mixing known values
> into the pool is harmless because the mixing function is fully
> reversable. ie:
> 
>  unmix(sample, mix(sample, pool)) = pool
> 
> If you didn't know the contents of pool before, you can't guess it
> after.
> 
> The danger comes if you (a) already know pool and (b) can narrow sample
> to a tractable set of values. Then you can calculate a set of possible
> pool' values and compare the resulting output to confirm the actual
> state of pool' (aka state extension attack). Sticking a constant
> multiplier on sample doesn't affect this attack at all.
> 

It only matters if you actually truncate it to LSBs.

>> However, the big issue with this is that it's recursive... what causes
>> this to be invoked... probably an interrupt, which is going to have been
>> invoked by a timer, quite possible the TSC deadline timer.  Oops.
> 
> ..and the sampling function already mixes in a TSC timestamp with the
> provided timestamp.

Right.

	-hpa