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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux