Messages in this thread |  | | From | Nicolai Stange <> | Subject | Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance | Date | Wed, 07 Oct 2020 12:38:10 +0200 |
| |
Eric Biggers <ebiggers@kernel.org> writes:
> On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote: >> >> Would some maintainer please comment on potential problems or >> shortcomings? >> > > Well, very people are experts in the Linux RNG *and* have time to review large > patchsets, especially when three people are all proposing conflicting changes. > And those that might be able to review these patches aren't necessarily > interested in compliance with particular government standards.
To make it clear: I'm personally not really enthusiastic about some of the restrictions imposed by SP800-90 either and Jason certainly has a point with his concerns about "subpar crypto" ([1]). However, at the same time I'm acknowledging that for some users FIPS compliance is simply a necessity and I don't see a strong reason why that shouldn't be supported, if doable without negatively affecting !fips_enabled users.
> Note that having multiple RNG implementations would cause fragmentation, more > maintenance burden, etc. So IMO, that should be a last resort. Instead we > should try to find an implementation that works for everyone. I.e., at least to > me, Nicolai's patchset seems more on the right track than Stephan's patchset...
I suppose that this concern about fragmentation is among the main reasons for reservations against Stephan's LRNG patchset and that's why I posted this RFC series here for comparison purposes. But note that, as said ([2]), it's incomplete and the only intent was to provide at least a rough idea on what it would take to move the current /dev/random implementation towards SP800-90 -- I was hoping for either a hard NACK or something along the lines of "maybe, go ahead and let's see".
> However, not everyone cares about "compliance". So any changes for "compliance" > either need to have a real technical argument for making the change, *or* need > to be optional (e.g. controlled by fips_enabled).
Fully agreed.
> AFAICS, this patchset mostly just talks about NIST SP800-90B compliance, and > doesn't make clear whether the changes make the RNG better, worse, or the same > from an actual technical perspective. > > If that was properly explained, and if the answer was "better" or at least > "not worse", I expect that people would be more interested.
The goal was not to negatively affect !fips_enabled users, but as outlined in the cover letter ([2]), a performance impact had been measured on ARMv7. This probably isn't something which couldn't get sorted out, but I see no point in doing it at this stage, because - there's still quite some stuff missing for full SP800-90 compliance anyway, c.f. the overview at the end of [2] and - such optimizations would have bloated this patchset even more, e.g. for making fips_enabled a static_key, which should certainly go into a separate series.
User visible effects set aside, an obvious downside of SP800-90 compliance would be the increase in code size and the associated maintenance burden.
That being said, I can imagine that those boot health tests could also get enabled for !fips_enabled users in the future, if wanted: rather than inhibiting /dev/random output on failure, a warning would get logged instead. Whether or not this would be seen as an improvement is for others to judge though.
Thanks,
Nicolai
[1] https://lkml.kernel.org/r/CAHmME9rMXORFXtwDAc8yxj+h9gytJj6DpvCxA-JMAAgyOP+5Yw@mail.gmail.com [2] https://lkml.kernel.org/r/20200921075857.4424-1-nstange@suse.de
-- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Felix Imendörffer
|  |