Almost two weeks passed and these are the "relevant" replies:
Jason personally does not like FIPS, and is afraid of
"subpar crypto". Albeit this patch set strictly isn't about
crypto at all; the crypto subsystem is in the unlucky position
to just depend on a good entropy source.
Greg claims that Linux (kernel) isn't about choice, which is clearly
wrong.
And this is all ???
There are options for stack protection. I can see bounds checking
and other sanity checks all over the place. And doing a similar thing
on entropy sources is a problem?
Admittedly, if entropy sources fail, the kernel will happily remain
running. No bad immediate effects in userland will arise. Only some
cryptographic algorithms, otherwise very decent, will run on
unneccessarily weak keys, probably causing some real-world problems.
Does anybody care?
The NIST and the BSI do, but that does not mean their solutions are
automatically wrong or backdoored.
There is now a well layed-out scheme to ensure quality randomness,
and a lot of work here has been put into its implementation.
Would some maintainer please comment on potential problems or
shortcomings? Otherwise a "Thanks, applied" would be appropriate, IMO.
Torsten
Torsten,
Ok, if you must have more replies then I'll bite :-)
> -----Original Message-----
> From: Torsten Duwe <[email protected]>
> Sent: Friday, October 2, 2020 2:39 PM
> To: Theodore Y. Ts'o <[email protected]>
> Cc: [email protected]; Nicolai Stange <[email protected]>; LKML <[email protected]>; Arnd Bergmann
> <[email protected]>; Greg Kroah-Hartman <[email protected]>; Eric W. Biederman <[email protected]>; Alexander
> E. Patrakov <[email protected]>; Ahmed S. Darwish <[email protected]>; Willy Tarreau <[email protected]>; Matthew Garrett
> <[email protected]>; Vito Caputo <[email protected]>; Andreas Dilger <[email protected]>; Jan Kara <[email protected]>;
> Ray Strode <[email protected]>; William Jon McCann <[email protected]>; zhangjs <[email protected]>; Andy Lutomirski
> <[email protected]>; Florian Weimer <[email protected]>; Lennart Poettering <[email protected]>; Peter Matthias
> <[email protected]>; Marcelo Henrique Cerri <[email protected]>; Neil Horman <[email protected]>;
> Randy Dunlap <[email protected]>; Julia Lawall <[email protected]>; Dan Carpenter <[email protected]>; Andy Lavr
> <[email protected]>; Eric Biggers <[email protected]>; Jason A. Donenfeld <[email protected]>; Stephan Müller
> <[email protected]>; Petr Tesarik <[email protected]>
> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
>
> <<< External Email >>>
> Almost two weeks passed and these are the "relevant" replies:
>
> Jason personally does not like FIPS, and is afraid of
> "subpar crypto". Albeit this patch set strictly isn't about
> crypto at all; the crypto subsystem is in the unlucky position
> to just depend on a good entropy source.
>
IMHO, Jason's statement is completely silly and solely based on some personal beef.
Obviously, the _ability_ to be compliant with FIPS testing does not preclude the use
of non-FIPS crypto, in case you should choose not to trust any of the FIPS recommended
implementations.
Fact of the matter is, many application areas (including but not limited to defence,
industrial automation, automotive, aero space, ...) have a hard a hard requirement on
FIPS certification. So not supporting that would either rule out using Linux altogether,
or steer them towards out-of-tree solutions.
And just running tests on your entropy source can't possibly be a bad thing anyway,
especially if you can configure it out if don't need or want to have it.
> Greg claims that Linux (kernel) isn't about choice, which is clearly
> wrong.
>
Well, I'm not going to argue with Greg about that ;-)
> And this is all ???
>
> There are options for stack protection. I can see bounds checking
> and other sanity checks all over the place. And doing a similar thing
> on entropy sources is a problem?
>
> Admittedly, if entropy sources fail, the kernel will happily remain
> running. No bad immediate effects in userland will arise. Only some
> cryptographic algorithms, otherwise very decent, will run on
> unneccessarily weak keys, probably causing some real-world problems.
> Does anybody care?
> The NIST and the BSI do, but that does not mean their solutions are
> automatically wrong or backdoored.
>
> There is now a well layed-out scheme to ensure quality randomness,
> and a lot of work here has been put into its implementation.
>
> Would some maintainer please comment on potential problems or
> shortcomings? Otherwise a "Thanks, applied" would be appropriate, IMO.
>
> Torsten
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>
On Fri, Oct 02, 2020 at 01:35:18PM +0000, Van Leeuwen, Pascal wrote:
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
As per my legal department requests, this is now ignored and deleted on
my system...
Hint, it's not a valid footer for public mailing lists...
greg k-h
> -----Original Message-----
> From: Greg Kroah-Hartman <[email protected]>
> Sent: Friday, October 2, 2020 4:04 PM
> To: Van Leeuwen, Pascal <[email protected]>
> Cc: Torsten Duwe <[email protected]>; Theodore Y. Ts'o <[email protected]>; [email protected]; Nicolai Stange
> <[email protected]>; LKML <[email protected]>; Arnd Bergmann <[email protected]>; Eric W. Biederman
> <[email protected]>; Alexander E. Patrakov <[email protected]>; Ahmed S. Darwish <[email protected]>; Willy
> Tarreau <[email protected]>; Matthew Garrett <[email protected]>; Vito Caputo <[email protected]>; Andreas Dilger
> <[email protected]>; Jan Kara <[email protected]>; Ray Strode <[email protected]>; William Jon McCann <[email protected]>;
> zhangjs <[email protected]>; Andy Lutomirski <[email protected]>; Florian Weimer <[email protected]>; Lennart
> Poettering <[email protected]>; Peter Matthias <[email protected]>; Marcelo Henrique Cerri
> <[email protected]>; Neil Horman <[email protected]>; Randy Dunlap <[email protected]>; Julia Lawall
> <[email protected]>; Dan Carpenter <[email protected]>; Andy Lavr <[email protected]>; Eric Biggers
> <[email protected]>; Jason A. Donenfeld <[email protected]>; Stephan Müller <[email protected]>; Petr Tesarik
> <[email protected]>
> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
>
> <<< External Email >>>
> On Fri, Oct 02, 2020 at 01:35:18PM +0000, Van Leeuwen, Pascal wrote:
> > ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is
> confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying,
> forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
>
> As per my legal department requests, this is now ignored and deleted on
> my system...
>
> Hint, it's not a valid footer for public mailing lists...
>
> greg k-h
It's automatically added by our company mail server ... not something I can control at all :-(
And using some external SMTP server would not pass our firewall.
So free webmail would be my only alternative, but I have a thorough dislike for web-based
tools, as I have yet to come across one with an even remotely acceptable user interface.
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>
On Fri, Oct 02, 2020 at 02:34:44PM +0000, Van Leeuwen, Pascal wrote:
>
>
>
> > -----Original Message-----
> > From: Greg Kroah-Hartman <[email protected]>
> > Sent: Friday, October 2, 2020 4:04 PM
> > To: Van Leeuwen, Pascal <[email protected]>
> > Cc: Torsten Duwe <[email protected]>; Theodore Y. Ts'o <[email protected]>; [email protected]; Nicolai Stange
> > <[email protected]>; LKML <[email protected]>; Arnd Bergmann <[email protected]>; Eric W. Biederman
> > <[email protected]>; Alexander E. Patrakov <[email protected]>; Ahmed S. Darwish <[email protected]>; Willy
> > Tarreau <[email protected]>; Matthew Garrett <[email protected]>; Vito Caputo <[email protected]>; Andreas Dilger
> > <[email protected]>; Jan Kara <[email protected]>; Ray Strode <[email protected]>; William Jon McCann <[email protected]>;
> > zhangjs <[email protected]>; Andy Lutomirski <[email protected]>; Florian Weimer <[email protected]>; Lennart
> > Poettering <[email protected]>; Peter Matthias <[email protected]>; Marcelo Henrique Cerri
> > <[email protected]>; Neil Horman <[email protected]>; Randy Dunlap <[email protected]>; Julia Lawall
> > <[email protected]>; Dan Carpenter <[email protected]>; Andy Lavr <[email protected]>; Eric Biggers
> > <[email protected]>; Jason A. Donenfeld <[email protected]>; Stephan M?ller <[email protected]>; Petr Tesarik
> > <[email protected]>
> > Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
> >
> > <<< External Email >>>
> > On Fri, Oct 02, 2020 at 01:35:18PM +0000, Van Leeuwen, Pascal wrote:
> > > ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is
> > confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying,
> > forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
> >
> > As per my legal department requests, this is now ignored and deleted on
> > my system...
> >
> > Hint, it's not a valid footer for public mailing lists...
> >
> > greg k-h
> It's automatically added by our company mail server ... not something I can control at all :-(
Then your company can not contribute in Linux kernel development, as
this is obviously not allowed by such a footer.
Please work with your IT and legal department to fix this.
thanks,
greg k-h
On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
> Almost two weeks passed and these are the "relevant" replies:
>
> Jason personally does not like FIPS, and is afraid of
> "subpar crypto". Albeit this patch set strictly isn't about
> crypto at all; the crypto subsystem is in the unlucky position
> to just depend on a good entropy source.
>
> Greg claims that Linux (kernel) isn't about choice, which is clearly
> wrong.
>
> And this is all ???
>
> There are options for stack protection. I can see bounds checking
> and other sanity checks all over the place. And doing a similar thing
> on entropy sources is a problem?
>
> Admittedly, if entropy sources fail, the kernel will happily remain
> running. No bad immediate effects in userland will arise. Only some
> cryptographic algorithms, otherwise very decent, will run on
> unneccessarily weak keys, probably causing some real-world problems.
> Does anybody care?
> The NIST and the BSI do, but that does not mean their solutions are
> automatically wrong or backdoored.
>
> There is now a well layed-out scheme to ensure quality randomness,
> and a lot of work here has been put into its implementation.
>
> Would some maintainer please comment on potential problems or
> shortcomings? Otherwise a "Thanks, applied" would be appropriate, IMO.
>
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.
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...
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).
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.
- Eric
Am Mittwoch, 7. Oktober 2020, 06:24:09 CEST schrieb Eric Biggers:
Hi Eric,
>
> 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...
Thank you for sharing your considerations.
If you say that only one implementation should be there, I am wondering why
not considering an implementation that as significant advantages over the
existing implementation as outlined in my cover letter to patch v35. In the
default configuration, it compiles no code at all that has any bearing on
government standards. Yet it has a more cryptographic sound approach to handle
entropy. In addition is meant to be extensible allowing each user to pick and
chose what he wants. Yet, users who do not want these extensions should not
suffer from it (neither performance-wise, nor should they suffer from an
unnecessary complex code that builds all options into one C file).
And speaking of fragmentation, if it is not *possible* to allow users to pick
what they want and need (and yes, in some parts of the world or for some users
these government standards are simply a necessity), we surely invite
fragmentation. In the LRNG, I tried to have all operations critical to entropy
compression and random number generation modularized so that the a can be
replaced or extended if needed without fragmentation.
PS: The reason why I started the LRNG was not government standards, but the
result of performing two studies. The one study was about entropy in
virtualized environment which showed that we have significant entropy in
virtual environments and yet the existing /dev/random implementation thinks
there is much less available. Another study I maintain for years also shows
that the entire entropy collection and heuristic on bare metal systems is also
in need of advancements. Initially I provided patches to the existing /dev/
random implementation, but basically all were silently ignored.
Ciao
Stephan