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. 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
Attachment:
signature.asc
Description: PGP signature
