Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Fri, Oct 02, 2020 at 03:56:28PM +0200, Stephan Mueller wrote: > Am Freitag, 2. Oktober 2020, 15:15:55 CEST schrieb Willy Tarreau: > > Hi Willy, > > > > And this is all ??? > > > > Possibly a lot of people got used to seeing the numerous versions > > and are less attentive to new series, it's possible that your message > > will wake everyone up. > > I think that points to my patch series. My patch series which provide a > complete separate, API and ABI compliant drop in replacement of /dev/random, > nobody from the gatekeepers cared to even answer. It would not touch the > existing code. > > After waiting some time without changing the code (e.g. after Andi Lutomirski > commented), I got no answer at all from the gatekeepers, not even any > indication in what direction I should move if something was not desired in > the > patch series. > > Thus I continued adding the features that I think are necessary and for which > I received comments from mathematicians. What else should I do? > > With the patch set v35 of my patch series, I see all my goals finally > achieved at I expect the code to be stable from here on. The last one was the > hardest: to get rid of all non-cryptographic conditioning operations and yet > retain performance en par or even superior to the existing /dev/random > implementation. Would you mind to resend it here, for a comparison? Torsten
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
Eric Biggers 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+...@mail.gmail.com [2] https://lkml.kernel.org/r/20200921075857.4424-1-nsta...@suse.de -- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Felix Imendörffer
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
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
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
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
RE: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
> -Original Message- > From: Theodore Y. Ts'o > Sent: Friday, October 2, 2020 8:14 PM > To: Van Leeuwen, Pascal > Cc: Greg Kroah-Hartman ; Torsten Duwe > ; linux-cry...@vger.kernel.org; Nicolai Stange > ; LKML ; Arnd Bergmann > ; Eric W. Biederman > ; Alexander E. Patrakov ; Ahmed S. > Darwish ; Willy > Tarreau ; Matthew Garrett ; Vito Caputo > ; Andreas Dilger > ; Jan Kara ; Ray Strode > ; William Jon McCann ; > zhangjs ; Andy Lutomirski ; > Florian Weimer ; Lennart > Poettering ; Peter Matthias > ; Marcelo Henrique Cerri > ; Neil Horman ; Randy Dunlap > ; Julia Lawall > ; Dan Carpenter ; Andy Lavr > ; Eric Biggers > ; Jason A. Donenfeld ; Stephan Müller > ; Petr Tesarik > > Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST > SP800-90B compliance > > <<< External Email >>> > On Fri, Oct 02, 2020 at 03:39:35PM +, Van Leeuwen, Pascal wrote: > > > Then your company can not contribute in Linux kernel development, as > > > this is obviously not allowed by such a footer. > > > > > Interesting, this has never been raised as a problem until today ... > > Going back through my mail archive, it looks like they started > > automatically adding that some > > 3 months ago. Not that they informed anyone about that, it just silently > > happened. > > So use a private e-mail address (e.g., at fastmail.fm if you don't > want to run your mail server) and then tunnel out SMTP requests using > ssh. It's not hard. :-) > Actually, for the last patches I sent I already had to tunnel them over some 3rd party SMTP-over-HTTPS service because of our firewall blocking access to the Gmail SMTP server I previously used for that :-( I guess tunnelling over SSH is another option, although I have no idea how to do such a thing (didn't know it was possible). At the end of the day, I am not a software guy, so I'm not _that_ much into these kinds of things ... That doesn't work for _regular_ mail, though, as I would not be able to setup a mail client for that. I can't install anything and I can't even touch the settings of my Outlook client :-( For incoming mail I'm actually bulk forwarding the mailing list through my Gmail account now because our mail server stopped accepting it directly. WIth POP3 and IMAP being blocked, I still need to find some way to receive patches without our Exchange server fubarring them though (tips are welcome!). Right now the only solution I have is fetch them from my home PC and take them to work on a USB stick. Welcome to 2020 ... > I've worked a multiple $BIG_COMPANY's, and I've been doing this for > decades. It's also helpful when I need to send e-mails from > conference networks from my laptop > > 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. - Ted ** 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>
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Fri, Oct 02, 2020 at 03:39:35PM +, Van Leeuwen, Pascal wrote: > > Then your company can not contribute in Linux kernel development, as > > this is obviously not allowed by such a footer. > > > Interesting, this has never been raised as a problem until today ... > Going back through my mail archive, it looks like they started automatically > adding that some > 3 months ago. Not that they informed anyone about that, it just silently > happened. So use a private e-mail address (e.g., at fastmail.fm if you don't want to run your mail server) and then tunnel out SMTP requests using ssh. It's not hard. :-) I've worked a multiple $BIG_COMPANY's, and I've been doing this for decades. It's also helpful when I need to send e-mails from conference networks from my laptop - Ted
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On 10/2/20 8:39 AM, Van Leeuwen, Pascal wrote: >> -Original Message- >> From: Greg Kroah-Hartman >> Sent: Friday, October 2, 2020 5:13 PM >> To: Van Leeuwen, Pascal >> Cc: Torsten Duwe ; Theodore Y. Ts'o ; >> linux-cry...@vger.kernel.org; Nicolai Stange >> ; LKML ; Arnd Bergmann >> ; Eric W. Biederman >> ; Alexander E. Patrakov ; Ahmed >> S. Darwish ; Willy >> Tarreau ; Matthew Garrett ; Vito Caputo >> ; Andreas Dilger >> ; Jan Kara ; Ray Strode >> ; William Jon McCann ; >> zhangjs ; Andy Lutomirski ; >> Florian Weimer ; Lennart >> Poettering ; Peter Matthias >> ; Marcelo Henrique Cerri >> ; Neil Horman ; Randy >> Dunlap ; Julia Lawall >> ; Dan Carpenter ; Andy Lavr >> ; Eric Biggers >> ; Jason A. Donenfeld ; Stephan Müller >> ; Petr Tesarik >> >> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST >> SP800-90B compliance >> >> <<< External Email >>> >> On Fri, Oct 02, 2020 at 02:34:44PM +, Van Leeuwen, Pascal wrote: >>> >>> >>> >>>> -Original Message- >>>> From: Greg Kroah-Hartman >>>> Sent: Friday, October 2, 2020 4:04 PM >>>> To: Van Leeuwen, Pascal >>>> Cc: Torsten Duwe ; Theodore Y. Ts'o ; >>>> linux-cry...@vger.kernel.org; Nicolai Stange >>>> ; LKML ; Arnd Bergmann >>>> ; Eric W. Biederman >>>> ; Alexander E. Patrakov ; Ahmed >>>> S. Darwish ; Willy >>>> Tarreau ; Matthew Garrett ; Vito Caputo >>>> ; Andreas Dilger >>>> ; Jan Kara ; Ray Strode >>>> ; William Jon McCann >> ; >>>> zhangjs ; Andy Lutomirski ; >>>> Florian Weimer ; Lennart >>>> Poettering ; Peter Matthias >>>> ; Marcelo Henrique Cerri >>>> ; Neil Horman ; Randy >>>> Dunlap ; Julia Lawall >>>> ; Dan Carpenter ; Andy >>>> Lavr ; Eric Biggers >>>> ; Jason A. Donenfeld ; Stephan >>>> Müller ; Petr Tesarik >>>> >>>> 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 +, 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. >> > Interesting, this has never been raised as a problem until today ... > Going back through my mail archive, it looks like they started automatically > adding that some > 3 months ago. Not that they informed anyone about that, it just silently > happened. > >> Please work with your IT and legal department to fix this. >> > Eh ... Greg ... that's not how that works in the real world. In the real > world, legal and IT lay > down the law and you just comply with that (or hack your way around it, if > you can ;-). That's how it worked at $big_companies that I have worked at. If it's a company/business requirement that you do Linux kernel development work, (is it?) then they should make that possible on internal systems or give you access to external email server(s). > I'm already fighting the good fight trying to keep control of my development > machines > because IT would just love to get rid of those (since not under IT control > oh dear ...) > And obviously, you cannot do kernel development on a machine without root > access. > It's annoying enough already to require IT support to provide explicit > permission to open > the task manager on my own company laptop ... grmbl. > >> >> thanks, >> >> greg k-h > > 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> > -- ~Randy
RE: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
> -Original Message- > From: Greg Kroah-Hartman > Sent: Friday, October 2, 2020 5:13 PM > To: Van Leeuwen, Pascal > Cc: Torsten Duwe ; Theodore Y. Ts'o ; > linux-cry...@vger.kernel.org; Nicolai Stange > ; LKML ; Arnd Bergmann > ; Eric W. Biederman > ; Alexander E. Patrakov ; Ahmed S. > Darwish ; Willy > Tarreau ; Matthew Garrett ; Vito Caputo > ; Andreas Dilger > ; Jan Kara ; Ray Strode > ; William Jon McCann ; > zhangjs ; Andy Lutomirski ; > Florian Weimer ; Lennart > Poettering ; Peter Matthias > ; Marcelo Henrique Cerri > ; Neil Horman ; Randy Dunlap > ; Julia Lawall > ; Dan Carpenter ; Andy Lavr > ; Eric Biggers > ; Jason A. Donenfeld ; Stephan Müller > ; Petr Tesarik > > Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST > SP800-90B compliance > > <<< External Email >>> > On Fri, Oct 02, 2020 at 02:34:44PM +, Van Leeuwen, Pascal wrote: > > > > > > > > > -Original Message- > > > From: Greg Kroah-Hartman > > > Sent: Friday, October 2, 2020 4:04 PM > > > To: Van Leeuwen, Pascal > > > Cc: Torsten Duwe ; Theodore Y. Ts'o ; > > > linux-cry...@vger.kernel.org; Nicolai Stange > > > ; LKML ; Arnd Bergmann > > > ; Eric W. Biederman > > > ; Alexander E. Patrakov ; > > > Ahmed S. Darwish ; Willy > > > Tarreau ; Matthew Garrett ; Vito Caputo > > > ; Andreas Dilger > > > ; Jan Kara ; Ray Strode > > > ; William Jon McCann > ; > > > zhangjs ; Andy Lutomirski ; > > > Florian Weimer ; Lennart > > > Poettering ; Peter Matthias > > > ; Marcelo Henrique Cerri > > > ; Neil Horman ; Randy > > > Dunlap ; Julia Lawall > > > ; Dan Carpenter ; Andy > > > Lavr ; Eric Biggers > > > ; Jason A. Donenfeld ; Stephan > > > Müller ; Petr Tesarik > > > > > > 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 +, 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. > Interesting, this has never been raised as a problem until today ... Going back through my mail archive, it looks like they started automatically adding that some 3 months ago. Not that they informed anyone about that, it just silently happened. > Please work with your IT and legal department to fix this. > Eh ... Greg ... that's not how that works in the real world. In the real world, legal and IT lay down the law and you just comply with that (or hack your way around it, if you can ;-). I'm already fighting the good fight trying to keep control of my development machines because IT would just love to get rid of those (since not under IT control oh dear ...) And obviously, you cannot do kernel development on a machine without root access. It's annoying enough already to require IT support to provide explicit permission to open the task manager on my own company laptop ... grmbl. > > thanks, > > greg k-h 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>
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Fri, Oct 02, 2020 at 02:34:44PM +, Van Leeuwen, Pascal wrote: > > > > > -Original Message- > > From: Greg Kroah-Hartman > > Sent: Friday, October 2, 2020 4:04 PM > > To: Van Leeuwen, Pascal > > Cc: Torsten Duwe ; Theodore Y. Ts'o ; > > linux-cry...@vger.kernel.org; Nicolai Stange > > ; LKML ; Arnd Bergmann > > ; Eric W. Biederman > > ; Alexander E. Patrakov ; Ahmed > > S. Darwish ; Willy > > Tarreau ; Matthew Garrett ; Vito Caputo > > ; Andreas Dilger > > ; Jan Kara ; Ray Strode > > ; William Jon McCann ; > > zhangjs ; Andy Lutomirski ; > > Florian Weimer ; Lennart > > Poettering ; Peter Matthias > > ; Marcelo Henrique Cerri > > ; Neil Horman ; Randy > > Dunlap ; Julia Lawall > > ; Dan Carpenter ; Andy > > Lavr ; Eric Biggers > > ; Jason A. Donenfeld ; Stephan Müller > > ; Petr Tesarik > > > > 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 +, 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
RE: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
> -Original Message- > From: Greg Kroah-Hartman > Sent: Friday, October 2, 2020 4:04 PM > To: Van Leeuwen, Pascal > Cc: Torsten Duwe ; Theodore Y. Ts'o ; > linux-cry...@vger.kernel.org; Nicolai Stange > ; LKML ; Arnd Bergmann > ; Eric W. Biederman > ; Alexander E. Patrakov ; Ahmed S. > Darwish ; Willy > Tarreau ; Matthew Garrett ; Vito Caputo > ; Andreas Dilger > ; Jan Kara ; Ray Strode > ; William Jon McCann ; > zhangjs ; Andy Lutomirski ; > Florian Weimer ; Lennart > Poettering ; Peter Matthias > ; Marcelo Henrique Cerri > ; Neil Horman ; Randy Dunlap > ; Julia Lawall > ; Dan Carpenter ; Andy Lavr > ; Eric Biggers > ; Jason A. Donenfeld ; Stephan Müller > ; Petr Tesarik > > 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 +, 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>
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Fri, Oct 02, 2020 at 03:33:58PM +0200, Greg Kroah-Hartman wrote: > On Fri, Oct 02, 2020 at 03:15:55PM +0200, Willy Tarreau wrote: > > 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. > > > > I think there's a small misunderstanding here, my understanding is > > that for quite a while, the possibilities offered by the various > > random subsystems or their proposed derivative used to range from > > "you have to choose between a fast system that may be vulnerable > > to some attacks, a system that might not be vulnerable to certain > > attacks but might not always boot, or a slow system not vulnerable > > to certain attacks". Greg's point seems to be that if we add an > > option, it means it's yet another tradeoff between these possibilities > > and that someone will still not be happy at the end of the chain. If > > the proposed solution covers everything at once (performance, > > reliability, unpredictability), then there probably is no more reason > > for keeping alternate solutions at all, hence there's no need to give > > the user the choice between multiple options when only one is known > > to always be valid. At least that's how I see it and it makes sense > > to me. > > Thanks for spelling it out in much more detail than I was willing to :) I assume you're not trying to pull the discussion off-topic. The one and only choice here is that some people believe in NIST and certifications. Yes, others don't, no problem either. The former folks boot with fips=1, that's it. Those people are usually certain about their decision. That option is about to break, for reasons I stated previously. This patch set is to introduce the now-missing pieces. One thing worth to discuss here would be whether people not so security conscious should benefit from the sanity checks as well. IMHO they should, because, as Willy explained, stick with the option that's always valid. My disappointment was that _none_ of the maintaners had an on-topic, technical remark. I get the impression some read "FIPS" and stop, regardless of the actual functionality. Torsten
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Fri, Oct 02, 2020 at 01:35:18PM +, 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
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
Am Freitag, 2. Oktober 2020, 15:15:55 CEST schrieb Willy Tarreau: Hi Willy, > > And this is all ??? > > Possibly a lot of people got used to seeing the numerous versions > and are less attentive to new series, it's possible that your message > will wake everyone up. I think that points to my patch series. My patch series which provide a complete separate, API and ABI compliant drop in replacement of /dev/random, nobody from the gatekeepers cared to even answer. It would not touch the existing code. After waiting some time without changing the code (e.g. after Andi Lutomirski commented), I got no answer at all from the gatekeepers, not even any indication in what direction I should move if something was not desired in the patch series. Thus I continued adding the features that I think are necessary and for which I received comments from mathematicians. What else should I do? With the patch set v35 of my patch series, I see all my goals finally achieved at I expect the code to be stable from here on. The last one was the hardest: to get rid of all non-cryptographic conditioning operations and yet retain performance en par or even superior to the existing /dev/random implementation. Ciao Stephan
RE: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
Torsten, Ok, if you must have more replies then I'll bite :-) > -Original Message- > From: Torsten Duwe > Sent: Friday, October 2, 2020 2:39 PM > To: Theodore Y. Ts'o > Cc: linux-cry...@vger.kernel.org; Nicolai Stange ; LKML > ; Arnd Bergmann > ; Greg Kroah-Hartman ; Eric W. > Biederman ; Alexander > E. Patrakov ; Ahmed S. Darwish ; > Willy Tarreau ; Matthew Garrett > ; Vito Caputo ; Andreas Dilger > ; Jan Kara ; > Ray Strode ; William Jon McCann ; zhangjs > ; Andy Lutomirski > ; Florian Weimer ; Lennart Poettering > ; Peter Matthias > ; Marcelo Henrique Cerri > ; Neil Horman ; > Randy Dunlap ; Julia Lawall ; > Dan Carpenter ; Andy Lavr > ; Eric Biggers ; Jason A. Donenfeld > ; Stephan Müller > ; Petr Tesarik > 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>
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Fri, Oct 02, 2020 at 03:15:55PM +0200, Willy Tarreau wrote: > 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. > > I think there's a small misunderstanding here, my understanding is > that for quite a while, the possibilities offered by the various > random subsystems or their proposed derivative used to range from > "you have to choose between a fast system that may be vulnerable > to some attacks, a system that might not be vulnerable to certain > attacks but might not always boot, or a slow system not vulnerable > to certain attacks". Greg's point seems to be that if we add an > option, it means it's yet another tradeoff between these possibilities > and that someone will still not be happy at the end of the chain. If > the proposed solution covers everything at once (performance, > reliability, unpredictability), then there probably is no more reason > for keeping alternate solutions at all, hence there's no need to give > the user the choice between multiple options when only one is known > to always be valid. At least that's how I see it and it makes sense > to me. Thanks for spelling it out in much more detail than I was willing to :) thanks, greg k-h
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
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. I think there's a small misunderstanding here, my understanding is that for quite a while, the possibilities offered by the various random subsystems or their proposed derivative used to range from "you have to choose between a fast system that may be vulnerable to some attacks, a system that might not be vulnerable to certain attacks but might not always boot, or a slow system not vulnerable to certain attacks". Greg's point seems to be that if we add an option, it means it's yet another tradeoff between these possibilities and that someone will still not be happy at the end of the chain. If the proposed solution covers everything at once (performance, reliability, unpredictability), then there probably is no more reason for keeping alternate solutions at all, hence there's no need to give the user the choice between multiple options when only one is known to always be valid. At least that's how I see it and it makes sense to me. > And this is all ??? Possibly a lot of people got used to seeing the numerous versions and are less attentive to new series, it's possible that your message will wake everyone up. Regards, Willy
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
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
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Tue, 22 Sep 2020 18:21:52 +0200 Greg Kroah-Hartman wrote: > On Tue, Sep 22, 2020 at 03:23:44PM +0200, Torsten Duwe wrote: > > On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote: > > > Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai > > > Stange: > > > > > > > - people dislike the approach of having two competing > > > > implementations for what is basically the same functionality in > > > > the kernel. > > > > > > Is this really so bad considering the security implications on > > > this topic? We also have multiple file systems, multiple memory > > > allocators, etc... > > > > Exactly. I thought Linux was about the freedom of choice. > > http://www.islinuxaboutchoice.com/ > > :) Talk is cheap. gzip -dc /proc/config.gz | wc -l 9789 :-P Torsten
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Tue, Sep 22, 2020 at 03:23:44PM +0200, Torsten Duwe wrote: > On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote: > > Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange: > > > > > - people dislike the approach of having two competing implementations for > > > what is basically the same functionality in the kernel. > > > > Is this really so bad considering the security implications on this topic? > > We > > also have multiple file systems, multiple memory allocators, etc... > > Exactly. I thought Linux was about the freedom of choice. http://www.islinuxaboutchoice.com/ :)
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote: > Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange: > > > - people dislike the approach of having two competing implementations for > > what is basically the same functionality in the kernel. > > Is this really so bad considering the security implications on this topic? We > also have multiple file systems, multiple memory allocators, etc... Exactly. I thought Linux was about the freedom of choice. Some people choose to get a FIPS certification for their Linux-based products, which mostly means to restrict crypto capabilities to an "allowed" set, granted. But in this case people might opt for some sort of "entropy QA". I find it hard to accept that this option is suppressed, especially if it's because of personal antipathy of the maintainer about the origin of this change and not for technical reasons. Restrictions on cryptographic functionality are ok, but health tests on entropy sources are not? I do understand people's reluctance after the dual-ECC DRBG desaster, but OTOH SElinux is generally considered an improvement. Definitely not everything coming from that direction is tainted. A big portion of this patch set is cleanup, another one said introduction of entropy source monitoring. This is important, no matter what your attitude towards certifications might be. Torsten
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange: Hi Nicolai, > Hi all, > > first of all, my apologies for the patch bomb following up in reply to this > mail here -- it's not meant to receive any serious review at all, but only > to support the discussion I'm hoping to get going. Thank you for this effort! > > As some of you might already be aware of, all new submissions for FIPS > certification will be required to comply with NIST SP800-90B from Nov 7th > on ([1], sec. 7.18 "Entropy Estimation and Compliance with SP 800-90B"). > For reference: broadly speaking, NIST SP800-90B is about noise sources, > SP800-90A about the DRBG algorithms stacked on top and SP800-90C about how > everything is supposed to be glued together. The main requirements from > SP800-90B are > - no correlations between different noise sources, > - to continuously run certain health tests on a noise source's output and > - to provide an interface enabling access to the raw noise samples for > validation purposes. > > To my knowledge, all SP800-90B compliant noise sources available on Linux > today are either based on the Jitter RNG one way or another or on > architectural RNGs like e.g. x86's RDSEED or arm64's RNDRRS. Currently, > there's an in-kernel Jitter RNG implementation getting registered (c.f. > crypto/drbg.c, (*)) with the Crypto RNG API, which is also accessible from > userspace via AF_ALG. The userspace haveged ([2]) or jitterentropy > integrations ([3]) are worth mentioning in this context, too. So in > summary, I think that for the in-kernel entropy consumers falling under the > scope of FIPS, the currently only way to stay compliant would be to draw it > from said Crypto API RNG. For userspace applications there's the additional > option to invoke haveged and alike. > > OTOH, CPU jitter based techniques are not uncontroversial ([4]). In any > case, it would certainly be a good idea to mix (xor or whatever) any jitter > output with entropy obtained from /dev/random (**). If I'm not mistaken, > the mentioned Crypto API RNG implementation (crypto/drbg.c) follows exactly > this approach, but doesn't enforce it yet: there's no > wait_for_random_bytes() and early DRBG invocations could in principle run > on seeds dominated entirely by jitterentropy. However, this can probably > get sorted quite easily and thus, one reasonable way towards maintaining > FIPS resp. SP800-90 compliance would be to > - make crypto/drbg.c invoke wait_for_random_bytes(), > - make all relevant in-kernel consumers to draw their random numbers from > the Crypto RNG API, if not already the case and > - convert all relevant userspace to use a SP800-90B conforming Jitter RNG > style noise source for compliance reasons, either by invoking the > kernel's Crypto RNG API or by diffent means, and mix that with > /dev/random. > > Even though this would probably be feasible, I'm not sure that giving up on > /dev/random being the primary, well established source of randomness in > favor of each and every userspace crypto library rolling its own entropy > collection scheme is necessarily the best solution (it might very well be > though). > > An obvious alternative would be to make /dev/random conform to SP800-90B. > Stephan Müller posted his "LRNG" patchset ([5]), in which he proposed to > introduce a second, independent implementation aiming at SP800-90[A-C] > conformance. However, it's in the 35th iteration now and my impression is > that there's hardly any discussion happening around this for quite a while > now. I haven't followed the earlier development, but I can imagine several > reasons for that: > - people are not really interested in FIPS or even questioning the whole > concept in the first place (c.f. Theodore Ts'o remarks on this topic > at [6]), > - potential reviewers got merely discouraged by the diffstat or Maybe I followed the Linux principle a bit to much here? Release early, release often. But with the v35, all goals I tried to achieve are now in (namely the last was to get rid of any non-cryptographic conditioning functions) and to have a very clean data processing / entropy analysis. I do not expect big changes any more. > - people dislike the approach of having two competing implementations for > what is basically the same functionality in the kernel. Is this really so bad considering the security implications on this topic? We also have multiple file systems, multiple memory allocators, etc... > > In either case, I figured it might perhaps help further discussion to > provide at least a rough idea of how bad the existing /dev/random > implementation would get cluttered when worked towards SP800-90B > compliance. So I implemented the required health tests for the interrupt > noise source -- the resulting patches can be found in reply to this mail. > I'd like to stress(!) that this should really only be considered a first > step and that there would still be a long way towards a complete
Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
I haven't looked into the details of this patchset yet, but your description here indicates to me that this is motivated by FIPS certification desires, which...worries me. I would like to rewrite the RNG at some point, and I've started to work on a bunch of designs for this (and proving them correct, too), but going about this via FIPS certification or trying to implement some NIST specs is most certainly the wrong way to go about this, will lock us into subpar crypto for years, and is basically a waste of time.
[DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance
Hi all, first of all, my apologies for the patch bomb following up in reply to this mail here -- it's not meant to receive any serious review at all, but only to support the discussion I'm hoping to get going. As some of you might already be aware of, all new submissions for FIPS certification will be required to comply with NIST SP800-90B from Nov 7th on ([1], sec. 7.18 "Entropy Estimation and Compliance with SP 800-90B"). For reference: broadly speaking, NIST SP800-90B is about noise sources, SP800-90A about the DRBG algorithms stacked on top and SP800-90C about how everything is supposed to be glued together. The main requirements from SP800-90B are - no correlations between different noise sources, - to continuously run certain health tests on a noise source's output and - to provide an interface enabling access to the raw noise samples for validation purposes. To my knowledge, all SP800-90B compliant noise sources available on Linux today are either based on the Jitter RNG one way or another or on architectural RNGs like e.g. x86's RDSEED or arm64's RNDRRS. Currently, there's an in-kernel Jitter RNG implementation getting registered (c.f. crypto/drbg.c, (*)) with the Crypto RNG API, which is also accessible from userspace via AF_ALG. The userspace haveged ([2]) or jitterentropy integrations ([3]) are worth mentioning in this context, too. So in summary, I think that for the in-kernel entropy consumers falling under the scope of FIPS, the currently only way to stay compliant would be to draw it from said Crypto API RNG. For userspace applications there's the additional option to invoke haveged and alike. OTOH, CPU jitter based techniques are not uncontroversial ([4]). In any case, it would certainly be a good idea to mix (xor or whatever) any jitter output with entropy obtained from /dev/random (**). If I'm not mistaken, the mentioned Crypto API RNG implementation (crypto/drbg.c) follows exactly this approach, but doesn't enforce it yet: there's no wait_for_random_bytes() and early DRBG invocations could in principle run on seeds dominated entirely by jitterentropy. However, this can probably get sorted quite easily and thus, one reasonable way towards maintaining FIPS resp. SP800-90 compliance would be to - make crypto/drbg.c invoke wait_for_random_bytes(), - make all relevant in-kernel consumers to draw their random numbers from the Crypto RNG API, if not already the case and - convert all relevant userspace to use a SP800-90B conforming Jitter RNG style noise source for compliance reasons, either by invoking the kernel's Crypto RNG API or by diffent means, and mix that with /dev/random. Even though this would probably be feasible, I'm not sure that giving up on /dev/random being the primary, well established source of randomness in favor of each and every userspace crypto library rolling its own entropy collection scheme is necessarily the best solution (it might very well be though). An obvious alternative would be to make /dev/random conform to SP800-90B. Stephan Müller posted his "LRNG" patchset ([5]), in which he proposed to introduce a second, independent implementation aiming at SP800-90[A-C] conformance. However, it's in the 35th iteration now and my impression is that there's hardly any discussion happening around this for quite a while now. I haven't followed the earlier development, but I can imagine several reasons for that: - people are not really interested in FIPS or even questioning the whole concept in the first place (c.f. Theodore Ts'o remarks on this topic at [6]), - potential reviewers got merely discouraged by the diffstat or - people dislike the approach of having two competing implementations for what is basically the same functionality in the kernel. In either case, I figured it might perhaps help further discussion to provide at least a rough idea of how bad the existing /dev/random implementation would get cluttered when worked towards SP800-90B compliance. So I implemented the required health tests for the interrupt noise source -- the resulting patches can be found in reply to this mail. I'd like to stress(!) that this should really only be considered a first step and that there would still be a long way towards a complete solution; known open items are listed below. Also, I'm fully aware that making those continuous health tests block the best effort primary_crng reseeds upon failure is a ridiculous thing to do -- that's again meant for demonstration purposes only, c.f. the commit log from the next to last patch. Anyway, those of you who are interested in some more details beyond the mere diffstat can find them after the list of references below. In summary, I can imagine three feasible ways towards SP800-90 compliance: 1.) Put the burden on consumers. For in-kernel users this would mean conversion to the Jitter backed Crypto RNG API, in case that hasn't happened yet. Userspace is free to use any approved Jitter based mechanism for
