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  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]
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.

Powered by blists - more mailing lists