Re: [PATCH v43 01/15] Linux Random Number Generator

[Willy Tarreau <w@1wt.eu>]

On Tue, Nov 30, 2021 at 04:45:44PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 30, 2021 at 09:31:09AM -0500, Simo Sorce wrote:
> > On Tue, 2021-11-30 at 15:04 +0100, Greg Kroah-Hartman wrote:
> > > Odds are, you REALLY do not want the in-kernel calls to be pulling from
> > > the "random-government-crippled-specification" implementation, right?
> > 
> > You really *do* want that.
> > When our customers are mandated to use FIPS certified cryptography,
> > they want to use it for kernel cryptography as well, and in general
> > they want to use a certified randomness source as well.
> 
> There are huge numbers of internal kernel calls that use random data for
> non-crypto things.

I think the confusion comes from the use of cryptography to hide the
internal state and provide non-predictable sequences, and not from the
use of this source to perform cryptography elsewhere. But crypto here,
when used, is not a goal but a means. We could call this a "reduction"
function or a "whitening" function. Its importance solely depends on
how much we want to protect the internal state from being guessed, which
first comes back to how long the knowledge of this internal state is
useful. If we'd mix completely independent and unpredictable sources
like cosmic microwave background noise and sea-level beta radiations,
these are constantly renewed, their knowledge doesn't bring anything
and there's no need for crypto to protect them. That's not necessarily
what we're using and we have to deal with more durable source whose
disclosure could have more impact for some time frame, thus would need
some protection.

As such there is probably a broad spectrum between "we must use strong
cryptography on this source hence abide with authorities' decisions" and
"we just need this short-lived state not to be trivially guessable till
the next call". In this case do we *really* care about what crypto
functions are used to hide the internal state ? I guess not really, and
that could possibly be configurable at run time. After all, in practice
the jitter entropy and other sources might add sufficient uncertainty
to complicate analysis of even a weak algorithm and render the internal
state hardly guessable.

> > Your plan requires an active maintainer that guides these changes and
> > interact with the people proposing them to negotiate the best outcome.
> > But that is not happening so that road seem blocked at the moment.
> 
> We need working patches that fit with the kernel development model first
> before people can start blaming maintainers :)
> 
> I see almost 300 changes accepted for this tiny random.c file over the
> years we have had git (17 years).  I think that's a very large number of
> changes for a 2300 line file that is relied upon by everyone.

I'm also having some concerns about this. It seems to me that it's always
difficult to *simplify* what we have and that each time we try to replace
something in that area we end up with multiple versions. Look at the recent
prandom32 stuff for example. We got a new algo used for IP IDs, in a rush,
hoping to generalize it to replace the existing Tausworthe one. I had a look
a few months ago to try to finish the job... hundreds of callers that make
use of the internal state for unit tests :-(  Basically unfeasible without
breaking lots of driver I have no idea how to test. So by trying to replace
something we just ended up with two implementations (and if I remember well
there were already a few more, mostly variants of the former).

A replacement ought to be an observation, a conclusion of a work well done,
not a goal. If the changes manage to move everyone in the right direction
and at the end everything is seamlessly replaced for good, that's awesome.
But changing for changing is hard. And if we end up with build time options
to decide between one solution and the other, we fragment the testability :-/

Just my two cents,
Willy