lkml.org 
[lkml]   [2022]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v43 01/15] Linux Random Number Generator
    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

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2022-01-10 14:24    [W:4.771 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site