(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
