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 20:47:29 +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 11:19:01AM -0700, Linus Torvalds wrote:
> If siphash is a good enough hash to make the pseudo-random state hard
> to guess, then it's also a good enough hash to hide the small part of
> the fast-pool we mix in.

No!

No, no, a thousand times no.

I *just* finished explaining, using dribs and drabs of entropy allows an 
*information theoretical attack* which *no* crypto can prevent.

The drip-feed design of the current patch is a catastrophic antifeature
which must be anethametized.

You could replace SipHash with a random function, the platonic ideal
to which all other cryptographic functions are compared, and you'd
still have a hole.

The fact that *nothing* can fix bad seeding is the entire reason
/dev/random exists in the first place.

*Second*, I have no intention of using full SipHash.  I'm spending
all of that security margin making it as fast as possible, leaving
just enough to discourage the original attack.

As you just pointed out, half-MD4 (still used in fs/ext4/hash.c) is quite 
enough to discourage attack if used appropriately.

If you go and *vastly* increase the value of a successful attack, 
letting an attacker at long-lived high-value keys, I have to put all
that margin back.

(Not to mention, even full SipHash only offers 128-bit security in the 
first place!  Shall I go and delete AES-256 and SHA2-512, since we've 
decided the Linux kernel is capped at 128-bit security?)

It's not even remotely difficult: use the *output* of random.c.  
Making that safe is what all that code is for.

(It costs some cycles, but SipHash's strength lets you go long 
enough between reseeds that it amorizes to insignificance.)