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]

Date:   Wed, 5 Aug 2020 09:06:40 -0700
From:   Marc Plumb <lkml.mplumb@...il.com>
To:     tytso@....edu, Willy Tarreau <w@....eu>
Cc:     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"

Hi Ted,

On 2020-08-05 8:34 a.m., tytso@....edu wrote:
> On Wed, Aug 05, 2020 at 04:49:41AM +0200, Willy Tarreau wrote:
>> Not only was this obviously not the goal, but I'd be particularly
>> interested in seeing this reality demonstrated, considering that
>> the whole 128 bits of fast_pool together count as a single bit of
>> entropy, and that as such, even if you were able to figure the
>> value of the 32 bits leaked to net_rand_state, you'd still have to
>> guess the 96 other bits for each single entropy bit :-/
> Not only that, you'd have to figure out which 32-bits in the fast_pool
> actually had gotten leaked to the net_rand_state.

That's 2 bits which are already inputs to the fast_pool, so it doesn't 
even make a brute force any more difficult.

> I agree with Willy that I'd love to see an exploit since it would
> probably give a lot of insights.  Maybe at a Crypto rump session once
> it's safe to have those sorts of things again.  :-)

Just because you or I don't have a working exploit doesn't mean that 
someone else isn't more clever. It pays to be paranoid about 
cryptographic primitives and there is nothing more important than the 
entropy pool.

> So replacing LFSR-based PRnG with
> something stronger which didn't release any bits from the fast_pool
> would certainly be desireable, and I look forward to seeing what Willy
> has in mind.

Isn't get_random_u32 the function you wrote to do that? If this needs to 
be cryptographically secure, that's an existing option that's safe.

The fundamental question is: Why is this attack on net_rand_state 
problem? It's Working as Designed. Why is it a major enough problem to 
risk harming cryptographically important functions?

Do you remember how you resisted making dev/urandom fast for large reads 
for a long time to punish stupid uses of the interface? In this case 
anyone who is using net_rand_state assuming it is a CPRNG should stop 
doing that. Don't enable stupidity in the kernel.

This whole thing is making the fundamental mistake of all amateur 
cryptographers of trying to create your own cryptographic primitive. 
You're trying to invent a secure stream cipher. Either don't try to make 
net_rand_state secure, or use a known secure primitive.

Thanks,

Marc