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

[Marcelo Henrique Cerri <marcelo.cerri@canonical.com>]

[-- Attachment #1: Type: text/plain, Size: 7689 bytes --]

On Thu, Dec 09, 2021 at 10:43:37PM -0300, Marcelo Henrique Cerri wrote:
> On Wed, Dec 01, 2021 at 11:02:38AM -0500, Jason A. Donenfeld wrote:
> > Hi Simo,
> > 
> > I think various folks have said this during the various discussions on this
> > topic over the years, in addition to myself, but I suppose I'll reiterate my
> > general views on FIPS in this context.
> > 
> > FIPS is about compliance and certification. From a cryptographic point of
> > view, there might be some good ideas, some dated ideas, some superfluous but
> > harmless ideas, and so forth. But the reason that you want it for your
> > customers is because you think your product will become more valuable or
> > useful to customers if it checks that green compliance checkbox. I don't think
> > we disagree about this being the motivation.
> > 
> > Now typically the kernel interoperates with lots of things and implements many
> > different specifications. It supports scores of network protocols, IPsec
> > cipher suites, USB quirks, SCSI hacks, you name it. The implementation of
> > these drivers is always up to the author and hopefully kernel developers at
> > large do the best job they can with the implementation, but the hardware or
> > protocol they're interfacing with is not up to the author, by virtue of it
> > being external to the kernel. It's not like instantiating IPsec with single
> > DES and MD4, or SM3 and SM4, etc. is so great, and it's not like the
> > compendium of brilliant hacks in drivers/usb/host/pci-quirks.c is so great
> > either. But these things all exist to talk to something *outside* of the
> > kernel, and so we grit our teeth, and as I said, do the best we can to
> > implement it well.
> > 
> > But the RNG isn't like that. In fact, the RNG is logically *required* to be
> > not anything like that: it returns random bytes, and they must not have any
> > distinguishing quality with other random bytes; otherwise we have a serious
> > problem that needs fixing. And so, we carry things out according to the usual
> > kernel developer mindset: we implement it as best as we can, using the best
> > algorithms we can find, in a way most suitable for the kernel.
> > 
> > Then FIPS comes along and starts dictating things about *how* we implement it,
> > and those things it dictates might not be exactly the same as what we would
> > would be doing when doing best that we can, using the best algorithms we can
> > find, and in the most suitable way for the kernel. And so it would seem that
> > the goal of implementing the RNG as best as we can might potentially be at
> > odds with the goal of getting that green compliance checkbox, because that
> > checkbox oversteps its bounds a bit.
> > 
> > That's not to say, of course, that we shouldn't accept input on how we
> > implement our algorithms from elsewhere. On the contrary, I think random.c has
> > a *lot* to gain from incorporating newer ideas, and that the formalism and
> > guidance from academic cryptographers is less "academic" than it once was and
> > much more real world, implementable, and suitable for our uses. But, again,
> > incorporating new ideas and accepting input on how to improve our code is very
> > much not the same thing as following the FIPS laundry list for that green
> > compliance checkbox. Maybe some parts do overlap -- and I'd love patches that
> > improve the code alongside compelling cryptographic arguments -- but, again,
> > we're talking about compliance here, and not a more welcome, "hey check out
> > this document I found with a bunch of great ideas we should implement."
> > 
> > I would like the kernel to have an excellent CSPRNG, from a cryptographic
> > point of view, from a performance point of view, from an API point of view. I
> > think these motivations are consistent with how the kernel is generally
> > developed. And I think front loading the motivations with an external
> > compliance goal greatly deviates and even detracts from the way the kernel is
> > generally developed.
> > 
> > Now the above is somewhat negative on FIPS, but the question can still be
> > posed: does FIPS have a path forward in the RNG in the kernel? It's obviously
> > not a resounding "yes", but I don't think it's a totally certain "no" either.
> > It might be possible to find some wiggle room. I'm not saying that it is
> > certainly possible to do that, but it might be.
> > 
> > Specifically, I think that if you change your perspective from, "how can we
> > change the algorithms of the RNG to be FIPS" to "how can we bend FIPS within
> > its limits so that having what customers want would minimally impact the
> > quality of the RNG implementation or introduce undue maintenance burdens."
> > This means: not refactoring the RNG into some large abstraction layer that's
> > pluggable and supports multiple different implementations, not rewriting the
> > world in a massive patchset, not adding clutter. Instead, perhaps there's a
> > very, very minimal set of things that can be done that would be considerably
> > less controversial. That will probably require from you and other FIPS
> > enthusiasts some study and discussion at what the truly most minimal set of
> > things required are to get you that green compliance checkbox. And hey --
> > maybe it's still way too much and it doesn't work out here. But maybe it's not
> > that much, or, as Greg suggested, maybe it winds up that your needs are
> > actually satisfied just fine by something in userspace or userspace-adjacent.
> > 
> > So I don't know whether the FIPS has a path forward here, but if it does, I
> > think the above is the general shape it would take. And in the mean time, I'm
> > of course open to reviewing patches that improve the RNG in a cryptographic or
> > algorithmic sense, rather than a purely compliance one.
> 
> Hi, Jason. How do you think we could approach that then?
> 
> Are you willing to discuss the FIPS 140-3 requirements that random.c
> doesn't currently meet so we can dive deeper on how we could implement
> them in a way that would improve the kernel other then simply
> providing compliance to FIPS?
> 
> I believe that several requirements would be beneficial to random.c
> (ie, health test, oversampling, entropy data collection). But so far
> we lack proper direction on how to proceed and it would be better for
> us to have a clear notion of what could be accepted before putting
> more effort on yet another patch set.
> 
> I believe all the distros are interested in making progress on that,
> but without a general guidance it makes very hard for us to
> collaborate and we end up in the current situation in which each
> distro is carrying its own "hack", as Simo mentioned before. Canonical
> is in the same situation as the other distros and we are carrying an
> workaround to wire up the crypto DRBG to random.c in order to archive
> compliance.
>

Hoping that might help with the discussion and to explain why I do
consider those solutions a "hack", that's the patch we've been using
so far to achieve SP 800-90B compliance:

https://kernel.ubuntu.com/~mhcerri/0001-UBUNTU-SAUCE-random-Use-Crypto-API-DRBG-for-urandom-.patch


> We could also concentrate all the discussion in the linux-crypto
> mailing list to facilitate this process, since right now I believe the
> MAINTAINERS file doesn't have a specific mailing list associate to
> random.c
> 
> > 
> > Hopefully that helps you understand more about where we're coming from.
> > 
> > Regards,
> > Jason
> 
> -- 
> Regards,
> Marcelo
> 



-- 
Regards,
Marcelo


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]