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
| ||
|
Date: Sun, 9 Aug 2020 14:10:08 -0700 From: Marc Plumb <lkml.mplumb@...il.com> To: Willy Tarreau <w@....eu>, George Spelvin <lkml@....org> Cc: 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, stephen@...workplumber.org, fw@...len.de Subject: Re: [DRAFT PATCH] random32: make prandom_u32() output unpredictable (Reseending since I accidentally sent it as HTML which the netdev mailing list doesn't like) On 2020-08-09 2:05 p.m., Marc Plumb wrote: > > Willy, > > > On 2020-08-07 3:19 p.m., Willy Tarreau wrote: >>> If I can figure the state out once, >> Yes but how do you take that as granted ? This state doesn't appear >> without its noise counterpart, so taking as a prerequisite that you may >> guess one separately obviously indicates that you then just have to >> deduce the other, but the point of mixing precisely is that we do not >> expose individual parts. > > > On 2020-08-09 2:38 a.m., Willy Tarreau wrote: >> However it keeps the problem that the whole sequence is entirely >> determined at the moment of reseeding, so if one were to be able to >> access the state, e.g. using l1tf/spectre/meltdown/whatever, then >> this state could be used to predict the whole ongoing sequence for >> the next minute. What some view as a security feature, others will >> see as a backdoor :-/ That's why I really like the noise approach. >> Even just the below would significantly harm that capability because >> that state alone isn't sufficient anymore to pre-compute all future >> values: > > > So two days ago I was unreasonable for assuming an attacker to could > recover the entire state, now you're assuming the same thing? As I > said before, if an attacker can recover the complete state, then > slowly adding noise doesn't help significantly since an attacker can > brute force the noise added (even if a perfect CPRNG is used). > > However, I think I'm starting to see your underlying assumptions. > You're thinking that raw noise data are the only truly unpredictable > thing so you think that adding it is a defense against attacks like > foreshadow/spectre/meltdown. You aren't entirely wrong -- if there was > a fast noise source then it might be a good option. Just if the noise > source is slow, you're just causing far more damage to a far more > critical crytpto function to get very little benefit. > > If you want to add noise to the network PRNG, then you can't put the > same noise into the dev/random CPRNG at all, in any way. I've tried > explaining the crypto reasons for this, and George has added to that, > so let me try a different approach: It breaks FIPS 140-2 for all of > Linux. While FIPS certification isn't a key driver, it is a > consideration for the crypt modules. FIPS references NIST.SP.800-90B > (which is specifically about Recommendation for the Entropy Sources > Used for Random Bit Generation) which has a requirement that the noise > source not pass any data used for crypto operations to anything > outside of the defined security boundary. If you want to feed a noise > measurement into the network PRNG, then you can't feed it into the > /dev/random pool also. You have to decide where the different > measurements are going to go and keep them completely seperate. > > I'm not intimately familiar with the standards so I spoke with someone > who does FIPS 140-x certification and was told "I don't think the > standards even considered the idea that someone might pass data from a > conditioning pool to other functions. It completely violates the > security boundary concept so is just prohibited ... that type of > change would absolutely be a problem." > > > Marc >
Powered by blists - more mailing lists