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>
