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. Hopefully that helps you understand more about where we're coming from. Regards, Jason
