Re: Flaw in "random32: update the net random state on interrupt and activity"

[Marc Plumb <lkml.mplumb@gmail.com>]

Willy,


On 2020-08-07 3:19 p.m., Willy Tarreau wrote:
> On Fri, Aug 07, 2020 at 12:59:48PM -0700, Marc Plumb wrote:
>>
>> If I can figure the state out once,
> Yes but how do you take that as granted ? This state doesn't appear
> without its noise counterpart,

Amit has shown attacks that can deduce the full internal state from 4-5 
packets with a weak PRNG. If the noise is added less often than that, an 
attacker can figure out the entire state at which point the partial 
reseeding doesn't help. If the noise is added more often than that, and 
it's raw timing events, then it's only adding a few bits of entropy so 
its easy to guess (and it weakens dev/random). If the noise is added 
more often, and it's from the output of a CPRNG, then we have all the 
performance/latency problems from the CPRNG itself, so we might as well 
use it directly.

>> I think it might be possible to do a decent CPRNG (that's at
>> least had some cryptanalys of it) with ~20 instructions per word, but if
>> that's not fast enough then I'll think about other options.
> I think that around 20 instructions for a hash would definitely be nice
> (but please be aware that we're speaking about RISC-like instructions,
> not SIMD instructions). And also please be careful not to count only
> with amortized performance that's only good to show nice openssl
> benchmarks, because if that's 1280 instructions for 256 bits that
> result in 20 instructions per 32-bit word, it's not the same anymore
> at all!

Understood.

Marc