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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
