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:   Sat, 8 Aug 2020 22:27:52 +0000
From:   George Spelvin <lkml@....ORG>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Willy Tarreau <w@....eu>, Netdev <netdev@...r.kernel.org>,
        Amit Klein <aksecurity@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        "Theodore Ts'o" <tytso@....edu>,
        Marc Plumb <lkml.mplumb@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: Flaw in "random32: update the net random state on interrupt and
 activity"

On Sat, Aug 08, 2020 at 01:52:37PM -0700, Linus Torvalds wrote:
> On Sat, Aug 8, 2020 at 1:47 PM George Spelvin <lkml@....org> wrote:
>> I *just* finished explaining, using dribs and drabs of entropy allows an
>> *information theoretical attack* which *no* crypto can prevent.
> 
> The key word here being "theoretical".
> 
> The other key word is "reality".
> 
> We will have to agree to disagree. I don't _care_ about the
> theoretical holes. I care about the real ones.

It's not a theoretical hole, it's a very real one.  Other than the cycles 
to do the brute-force part, it's not even all that complicated.  The 
theory part is that it's impossible to patch.

*If* you do the stupid thing.  WHICH YOU COULD JUST STOP DOING.

> We plugged a real one. Deal with it.

The explain it to me.  What is that actual *problem*?  Nobody's described 
one, so I've been guessing.  What is this *monumentally stupid* abuse of 
/dev/random allegedly fixing?

If you're not an idiot, explain.

Because right now you sound like one.  There's a simple and easy fix which 
I've described and will get back to implementing as soon as I've finished 
yelling at you.  What, FFS, is your objection to considering it?

I'm trying to implement a solution that satisfies everyone's requirements 
*including* the absence of catastrophic security holes.  If there's some 
requirement I'm not satisfying, please tell me.  Just please don't say "I 
prefer doing the stupid thing to changing my mind."  I hear enough of that 
on the news.

I can deal with it *personally* by patching it out of my private kernels, 
but I'd really rather it doesn't get deployed to a billion devices before 
someone exploits it.