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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200808205912.GE27941@SDF.ORG>
Date:   Sat, 8 Aug 2020 20:59:12 +0000
From:   George Spelvin <lkml@....ORG>
To:     Florian Westphal <fw@...len.de>
Cc:     Willy Tarreau <w@....eu>, 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,
        tytso@....edu, lkml.mplumb@...il.com, stephen@...workplumber.org
Subject: Re: Flaw in "random32: update the net random state on interrupt and
 activity"

On Sat, Aug 08, 2020 at 09:18:27PM +0200, Florian Westphal wrote:
> Can't we keep prandom_u32 as-is...?  Most of the usage, esp. in the
> packet schedulers, is fine.
> 
> I'd much rather have a prandom_u32_hashed() or whatever for
> those cases where some bits might leak to the outside and then convert
> those prandom_u32 users over to the siphashed version.

That's a question I've been asking.  Since this is apparently an
Important Security Bug that wants backported to -stable, I'm making
the minimally-invasive change, which is to change prandom_u32() for
all callers rather that decide which gets what.

But going forward, adding an additional security level between
the current prandom_u32() and get_random_u32() is possible.

I'm not sure it's a good idea, however.  This entire hullalbaloo stems
from someone choosing the wrong PRNG.  Adding another option doesn't
seem likely to prevent a repetition in future.