Thread (22 messages) flat view 22 messages, 7 authors, 2020-08-07

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

From: Marc Plumb <hidden>
Date: 2020-08-07 22:45:52
Also in: netdev

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:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help