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: <20200808222752.GG27941@SDF.ORG>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ