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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9ae4be33-fdeb-b882-d705-bccfacda1c4e@gmail.com>
Date:   Fri, 7 Aug 2020 15:45:48 -0700
From:   Marc Plumb <lkml.mplumb@...il.com>
To:     Willy Tarreau <w@....eu>
Cc:     tytso@....edu, netdev@...r.kernel.org, aksecurity@...il.com,
        torvalds@...ux-foundation.org, edumazet@...gle.com,
        Jason@...c4.com, luto@...nel.org, keescook@...omium.org,
        tglx@...utronix.de, peterz@...radead.org, stable@...r.kernel.org
Subject: Re: Flaw in "random32: update the net random state on interrupt and
 activity"

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