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: <20200805164934.253346fe@hermes.lan>
Date:   Wed, 5 Aug 2020 16:49:34 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Marc Plumb <lkml.mplumb@...il.com>, Willy Tarreau <w@....eu>,
        "Theodore Ts'o" <tytso@....edu>, 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>,
        stable <stable@...r.kernel.org>
Subject: Re: Flaw in "random32: update the net random state on interrupt and
 activity"

On Wed, 5 Aug 2020 09:39:17 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Wed, Aug 5, 2020 at 8:44 AM Marc Plumb <lkml.mplumb@...il.com> wrote:
> >
> > I thought net_rand_state was assumed to be insecure and that anyone
> > could determine the internal state. Isn't this Working as Designed?  
> 
> I was working as designed - because it wasn't really designed to be
> "real crypto" - but sadly it's also the only thing that is fast enough
> for a lot of networking.
> 
> So it may be _designed_ to be "not real crypto" and to have a
> discoverable internal state. But once again, reality interferes, and
> it turns out that people really want something very very fast that is
> also not deterministic enough to be discoverable at least remotely.

If you turn on the wayback machine, the original net_random came out
of having ok values for network simulation with netem. In that use case,
the point was to just have something with good distribution and reasonably long
period.

Then the idea of TCP ports have to be random came along and that was both
a weak security feature and benchmark sensitive so the net_random got drafted
into more areas.