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