Hi Jason, thanks for your reply, I appreciate when there is a clear exchange of ideas. Comment inline. On Wed, 2021-12-01 at 11:02 -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. I have to say that although there is clearly a great deal of "because we need the certification" I do not fully agree that FIPS is just a checkbox to be ticked for me. Of course for customers that do not care that much it is, and it is a required one. However having worked a lot on this I can tell you there is actually real cryptographic value in the requirements FIPS introduced over the years. If anything my complaint is that the list of accepted constructs is restrictive, but other than that most of the requirements have real world sense, and the certification process do uncover issue that otherwise would linger as the testing is rather thorough. > 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. Well I think most of the requirements are sane practices, hopefully controversial stuff will be minimal. I fully believe we can work to have the best we can as well as having it FIPS compliant, because the intent of FIPS requirements here is exactly to have the best guarantees for randomness. > 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 happen to think quite a few of the requirements are actually good ideas to implement to improve the guarantees of randomness, but there may definitely be contentious ideas of what is "good" and what is an "arbitrary request". > 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. I would agree is compliance meant arbitrary/capricious requirements. Hopefully most of the requirements are reasonable and we can find a reasonable way to fulfill them. > 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." We always operate with this mindset to be quite frank. The kernel is just one of many crypto modules we certify, and we always try to find the least invasive options in all the crypto modules we certify. We also normally try to get all changes upstream because we think they are a benefit to everyone. > 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. I think the reason to propose this is to deal with cases where the kernel community and the FIPS requirement diverge. A pluggable system allows to provide a downstream module and in general will provide clear entry-points where to apply downstream patches that minimally deviate from the general structure. Unfortunately, regardless of what the kernel community find of its liking we have a business need to provide FIPS certifications to our customers. So for us it is also a matter of pragmatically reducing to the maximum extent possible any necessary deviation from upstream kernels. > 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. As long as there is actual feedback and a willingness to reach a compromise on both sides when a change does not materially cause issues, I think this is certainly reasonable. > 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. Unfortunately userspace is not an option for kernel's own cryptography. > 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. Hopefully we can take both into account. > Hopefully that helps you understand more about where we're coming from. It does, thanks. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc
