Torsten, Ok, if you must have more replies then I'll bite :-) > -----Original Message----- > From: Torsten Duwe <duwe@xxxxxx> > Sent: Friday, October 2, 2020 2:39 PM > To: Theodore Y. Ts'o <tytso@xxxxxxx> > Cc: linux-crypto@xxxxxxxxxxxxxxx; Nicolai Stange <nstange@xxxxxxx>; LKML <linux-kernel@xxxxxxxxxxxxxxx>; Arnd Bergmann > <arnd@xxxxxxxx>; Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; Eric W. Biederman <ebiederm@xxxxxxxxxxxx>; Alexander > E. Patrakov <patrakov@xxxxxxxxx>; Ahmed S. Darwish <darwish.07@xxxxxxxxx>; Willy Tarreau <w@xxxxxx>; Matthew Garrett > <mjg59@xxxxxxxxxxxxx>; Vito Caputo <vcaputo@xxxxxxxxxxx>; Andreas Dilger <adilger.kernel@xxxxxxxxx>; Jan Kara <jack@xxxxxxx>; > Ray Strode <rstrode@xxxxxxxxxx>; William Jon McCann <mccann@xxxxxxx>; zhangjs <zachary@xxxxxxxxxxxxxxxx>; Andy Lutomirski > <luto@xxxxxxxxxx>; Florian Weimer <fweimer@xxxxxxxxxx>; Lennart Poettering <mzxreary@xxxxxxxxxxx>; Peter Matthias > <matthias.peter@xxxxxxxxxxx>; Marcelo Henrique Cerri <marcelo.cerri@xxxxxxxxxxxxx>; Neil Horman <nhorman@xxxxxxxxxx>; > Randy Dunlap <rdunlap@xxxxxxxxxxxxx>; Julia Lawall <julia.lawall@xxxxxxxx>; Dan Carpenter <dan.carpenter@xxxxxxxxxx>; Andy Lavr > <andy.lavr@xxxxxxxxx>; Eric Biggers <ebiggers@xxxxxxxxxx>; Jason A. Donenfeld <Jason@xxxxxxxxx>; Stephan Müller > <smueller@xxxxxxxxxx>; Petr Tesarik <ptesarik@xxxxxxx> > 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>
