Re: drivers/char/random.c needs a (new) maintainer
Pavel Machek wrote: > To play devil's advocate, does RNG subsystem need to evolve? Its task > is to get random numbers. Does it fail at the task? > > Problem is, random subsystem is hard to verify, and big rewrite is > likely to cause security problems... Parts of the problem, though, are dead easy in many of today's environments. Many CPUs, e,g. Intel, have an instruction that gives random numbers. Some systems have another hardware RNG. Some can add one using a USB device or Denker's Turbid (https://www.av8n.com/turbid/). Many Linux instances run on VMs so they have an emulated HWRNG using the host's /dev/random. None of those is necessarily 100% trustworthy, though the published analysis for Turbid & for (one version of) the Intel device seem adequate to me. However, if you use any of them to scribble over the entire 4k-bit input pool and/or a 512-bit Salsa context during initialisation, then it seems almost certain you'll get enough entropy to block attacks. They are all dirt cheap so doing that, and using them again later for incremental squirts of randomness, looks reasonable. In many cases you could go further. Consider a system with an intel CPU and another HWRNG, perhaps a VM. Get 128 bits from each source & combine them using the 128-bit finite field multiplication from the GSM authentication. Still cheap & it cannot be worse than the better of the two sources. If both sources are anywhere near reasonable, this should produce 128 bits of very high grade random material, cheaply. I am not suggesting any of these should be used for output, but using them for initialisation whenever possible looks obvious to me.
Re: drivers/char/random.c needs a (new) maintainer
Hi! > > On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote: > > > Upfront, let me admit that SUSE has a vested interest in a > > > FIPS-certifiable Linux kernel. > > > > Sorry, but just because you have a "vested interest", or a financial > > interest, or because you want it does not suddenly make it a good > > idea. The idea is to have good crypto, not to merely check some boxes > > I never suggested that this should serve as a supportive argument. I was just > trying to be honest about our motivations. > > I'm a bit sad that this discussion has quickly gone back to the choice of > algorithms and how they can be implemented. The real issue is that the RNG > subsystem has not developed as fast as it could. This had not been much of an > issue as long as nobody was really interested in making any substantial > changes to that code, but it is more apparent now. Torsten believes it can be > partly because of a maintainer who is too busy with other tasks, and he > suggested we try to improve the situation by giving the RNG-related tasks to > someone else. > (Please wrap at 80 columns). To play devil's advocate, does RNG subsystem need to evolve? Its task is to get random numbers. Does it fail at the task? Problem is, random subsystem is hard to verify, and big rewrite is likely to cause security problems... Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: drivers/char/random.c needs a (new) maintainer
Hi! > > Any updates on that? > > > > I don't believe Torsten's concerns are simply about *applying* patches > > but more about these long periods of radio silence. That kills > > Exactly. I could live with replies in the style of "old" Linus like: > "Your code is crap, because it does X and Y". Then I knew how to > proceed. But this extended silence slows things down a lot. Well... you know. We now have code of conflict, so maintainers are not supposed to tell submitters that their code is . So... you get silence. Pavel -- p http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: drivers/char/random.c needs a (new) maintainer
On Wed, Dec 23, 2020 at 5:03 PM Jason A. Donenfeld wrote: > > Hi Peter, > > On Wed, Dec 23, 2020 at 5:01 PM Petr Tesarik wrote: > > I never suggested that this should serve as a supportive argument. I was > > just trying to be honest about our motivations. > > > > I'm a bit sad that this discussion has quickly gone back to the choice of > > algorithms and how they can be implemented. > > Why are you sad? You are interested in FIPS. FIPS indicates a certain > set of algorithms. The ones most suitable to the task seem like they'd > run into real practical problems in the kernel's RNG. > > That's not the _only_ reason I'm not keen on FIPS, but it does seem > like a very basic one. > > Jason And just to add to that: in working through Nicholai's patches (an ongoing process), I'm reminded of his admonishment in the 00 cover letter that at some point chacha20 will have to be replaced, due to FIPS. So it seems like that's very much on the table. I brought it up here as an example ("For example, " is how I began that sentence), but it is a concern. If you want to make lots of changes for cryptographic or technical reasons, that seems like a decent way to engage. But if the motivation for each of these is the bean counting, then again, I'm pretty wary of churn for nothing. And if that bean counting will eventually lead us into bad corners, like the concerns I brought up about FPU usage in the kernel, then I'm even more hesitant. However, I think there may be good arguments to be made that some of Nicholai's patches stand on their own, without the FIPS motivation. And that's the set of arguments that are compelling. Jason
Re: drivers/char/random.c needs a (new) maintainer
Hi Peter, On Wed, Dec 23, 2020 at 5:01 PM Petr Tesarik wrote: > I never suggested that this should serve as a supportive argument. I was just > trying to be honest about our motivations. > > I'm a bit sad that this discussion has quickly gone back to the choice of > algorithms and how they can be implemented. Why are you sad? You are interested in FIPS. FIPS indicates a certain set of algorithms. The ones most suitable to the task seem like they'd run into real practical problems in the kernel's RNG. That's not the _only_ reason I'm not keen on FIPS, but it does seem like a very basic one. Jason
Re: drivers/char/random.c needs a (new) maintainer
On Wed, 23 Dec 2020 15:32:55 +0100 "Jason A. Donenfeld" wrote: > On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote: > > Upfront, let me admit that SUSE has a vested interest in a FIPS-certifiable > > Linux kernel. > > Sorry, but just because you have a "vested interest", or a financial > interest, or because you want it does not suddenly make it a good > idea. The idea is to have good crypto, not to merely check some boxes I never suggested that this should serve as a supportive argument. I was just trying to be honest about our motivations. I'm a bit sad that this discussion has quickly gone back to the choice of algorithms and how they can be implemented. The real issue is that the RNG subsystem has not developed as fast as it could. This had not been much of an issue as long as nobody was really interested in making any substantial changes to that code, but it is more apparent now. Torsten believes it can be partly because of a maintainer who is too busy with other tasks, and he suggested we try to improve the situation by giving the RNG-related tasks to someone else. I have not seen a clear answer to this suggestion, except Jason offering his helping hand with Nicolai's cleanup patches, but nothing wrt Stephan's patches. So, what is the plan? Petr Tesarik SUSE HW Enablement Team pgpw9IwlgRr2W.pgp Description: Digitální podpis OpenPGP
Re: drivers/char/random.c needs a (new) maintainer
On Wed, Dec 23, 2020 at 4:26 PM Stephan Mueller wrote: > > Am Mittwoch, dem 23.12.2020 um 15:32 +0100 schrieb Jason A. Donenfeld: > > > > I would, however, be interested in a keccak-based construction. But > > just using the keccak permutation does not automatically make it > > "SHA-3", so we're back at the same issue again. FIPS is simply not > > interesting for our requirements. > > Using non-assessed cryptography? Sounds dangerous to me even though it may be > based on some well-known construction. "assessed" is not necessarily the same as FIPS. Don't conflate the two. I don't appreciate that kind of dishonest argumentation. And new constructions that I'm interested in would be formally verified (like the other crypto work I've done) with review and buy-in from the cryptographic community, both engineering and academic. I have no interest in submitting "non-assessed" things developed in a vacuum, and I'm displeased with your attempting to make that characterization. Similarly, any other new design proposed I would expect a similar amount of rigor. The current RNG is admittedly a bit of a mess, but at least it's a design that's evolved. Something that's "revolutionary", rather than evolutionary, needs considerably more argumentation. So, please, don't strawman this into the "non-assessed" rhetoric.
Re: drivers/char/random.c needs a (new) maintainer
Am Mittwoch, dem 23.12.2020 um 15:32 +0100 schrieb Jason A. Donenfeld: > > I would, however, be interested in a keccak-based construction. But > just using the keccak permutation does not automatically make it > "SHA-3", so we're back at the same issue again. FIPS is simply not > interesting for our requirements. Your requirements? Interesting approach. Using non-assessed cryptography? Sounds dangerous to me even though it may be based on some well-known construction. I thought Linux in general and crypto in particular is about allowing user (or the vendor) to decide about the used algorithm. So, let us have a mechanism that gives them this freedom. Thus the proposed idea sounds to me like a dangerous proposition upon which almost all cryptography shall rest. This will surely invite even more fragmentation. Ciao Stephan PS: This entire discussion is NOT about the crypto side of the random numbers, but about how get the entropy for the random numbers.
Re: drivers/char/random.c needs a (new) maintainer
On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote: > Upfront, let me admit that SUSE has a vested interest in a FIPS-certifiable > Linux kernel. Sorry, but just because you have a "vested interest", or a financial interest, or because you want it does not suddenly make it a good idea. The idea is to have good crypto, not to merely check some boxes for the bean counters. For example, it's very unlikely that future kernel RNGs will move to using AES, due to the performance overhead involved on non-table-based implementations, and the lack of availability of FPU/AES-NI in all the contexts we need. NT's fortuna machine can use AES, because NT allows the FPU in all contexts. We don't have that luxury (or associated performance penalty). I would, however, be interested in a keccak-based construction. But just using the keccak permutation does not automatically make it "SHA-3", so we're back at the same issue again. FIPS is simply not interesting for our requirements. Jason
Re: drivers/char/random.c needs a (new) maintainer
On Wed, 23 Dec 2020 13:28:51 +0100 Torsten Duwe wrote: >[...] > > collaboration and disengage people. More than simply reviewing patches > > I would expect a maintainer to give directions and drive the > > community. Asking Jason to review Nicolai's patches was a step towards > > that, but I believe we still could benefit from better communication. > > Even regarding this I'm not so sure it was a good idea. Jason seems to > narrow the proposed changes down to "FIPS certification", when it > actually is a lot more. I think his motivation suffers because of his > personal dislike. Upfront, let me admit that SUSE has a vested interest in a FIPS-certifiable Linux kernel. However, it seems to me that nobody can be happy about keeping the current status quo forever. Even in the hypothetical case that the RNG maintainer rejected the whole idea merely because it makes it possible to achieve NIST compliance, and he detests standards compliance, it would still be better than no decision at all. The silence is paralyzing, as it blocks any changes in upstream, while also making it difficult to maintain an out-of-tree implementation that aims at becoming upstream eventually. The only option ATM is a fork (similar to what the Xen folks did with XenLinux many years ago). IOW the current situation demotivates contributors from being good citizens. I hope we can find a better solution together. Petr Tesarik SUSE HW Enablement Team pgpFeg_6a6sxB.pgp Description: Digitální podpis OpenPGP
Re: drivers/char/random.c needs a (new) maintainer
On Fri, 18 Dec 2020 10:25:19 -0300 Marcelo Henrique Cerri wrote: > Hi, Ted and Jason. > > Any updates on that? > > I don't believe Torsten's concerns are simply about *applying* patches > but more about these long periods of radio silence. That kills Exactly. I could live with replies in the style of "old" Linus like: "Your code is crap, because it does X and Y". Then I knew how to proceed. But this extended silence slows things down a lot. > collaboration and disengage people. More than simply reviewing patches > I would expect a maintainer to give directions and drive the > community. Asking Jason to review Nicolai's patches was a step towards > that, but I believe we still could benefit from better communication. Even regarding this I'm not so sure it was a good idea. Jason seems to narrow the proposed changes down to "FIPS certification", when it actually is a lot more. I think his motivation suffers because of his personal dislike. > Besides Nicolai's RFC, are you also planning to take another look at > Stephan's patches? Yes, please advise! For important, major changes the maintainer should ping the contributors, not vice versa. Not even to mention the bunch of minor changes pending, some even acked by independent developers. Torsten
Re: drivers/char/random.c needs a (new) maintainer
Hi, Ted and Jason. Any updates on that? I don't believe Torsten's concerns are simply about *applying* patches but more about these long periods of radio silence. That kills collaboration and disengage people. More than simply reviewing patches I would expect a maintainer to give directions and drive the community. Asking Jason to review Nicolai's patches was a step towards that, but I believe we still could benefit from better communication. Besides Nicolai's RFC, are you also planning to take another look at Stephan's patches? Thank you for your attention. On Tue, Dec 01, 2020 at 12:42:36PM +0100, Jason A. Donenfeld wrote: > On Mon, Nov 30, 2020 at 5:56 PM Theodore Y. Ts'o wrote: > > patches this cycle. One thing that would help me is if folks > > (especially Jason, if you would) could start with a detailed review of > > Nicolai's patches. > > Sure, I'll take a look. -- Regards, Marcelo signature.asc Description: PGP signature
Re: drivers/char/random.c needs a (new) maintainer
On Mon, Nov 30, 2020 at 5:56 PM Theodore Y. Ts'o wrote: > patches this cycle. One thing that would help me is if folks > (especially Jason, if you would) could start with a detailed review of > Nicolai's patches. Sure, I'll take a look.
Re: drivers/char/random.c needs a (new) maintainer
On Mon, Nov 30, 2020 at 04:15:23PM +0100, Jason A. Donenfeld wrote: > I am willing to maintain random.c and have intentions to have a > formally verified RNG. I've mentioned this to Ted before. > > But I think Ted's reluctance to not accept the recent patches sent to > this list is mostly justified, and I have no desire to see us rush > into replacing random.c with something suboptimal or FIPSy. Being a maintainer is not about *accepting* patches, it's about *reviewing* them. I do plan to make time to catch up on reviewing patches this cycle. One thing that would help me is if folks (especially Jason, if you would) could start with a detailed review of Nicolai's patches. His incremental approach is I believe the best one from a review perspective, and certainly his cleanup patches are ones which I would expect are no-brainers. - Ted
Re: drivers/char/random.c needs a (new) maintainer
I am willing to maintain random.c and have intentions to have a formally verified RNG. I've mentioned this to Ted before. But I think Ted's reluctance to not accept the recent patches sent to this list is mostly justified, and I have no desire to see us rush into replacing random.c with something suboptimal or FIPSy.
drivers/char/random.c needs a (new) maintainer
Hi Linus! AFAIK it's legit to bother you directly with issues like this one? I see certifications as the mere messengers here which tell us that our /dev/random is technologically outdated. Input entropy amounts are guesstimated in advance, obviously much too conservatively, compiled in and never checked thereafter; the whitening is done using some home- grown hash function derivative and other non-cryptographic, non-standard operations. All of this does not affect the Linux kernel directly, it will compile happily, and will run smoothly with all given crypto apps. Only new crypto keys are generated slower than necessary or, much worse, might contain less entropy than required because something broke down unnoticed. In that case, problems would arise only much later, but in the real world and with much graver impact. I would rather like to see the Linux /dev/random being reliable, whether certified or not. If it provided that reliable entropy fast that would be even cooler. If it was at least possible to get approval from a standardization body (without forcing this onto all users, of course) that would be optimal. Meanwhile there's quite a maintenance backlog; minor fixes are pending, medium-sized cleanups are ignored and major patch sets to add the missing features are not even discussed. (I'm deliberately not including links here to avoid excessive finger pointing.) I'd like to believe that Ted is too busy working on ext4, but, especially on explicit request, a "hold on, I'm busy, will get at it later" or "right, someone wants to take over?" would be appropriate IMHO. It is also not helpful to object to or ignore all changes which might benefit certifications just for that sole reason and because of personal aversion. No reply at all yields exactly the same result as having no maintainer at all, hence the subject. Could you please try to get a definite answer from him? I know there is at least one person (probably more) with enough enthusiasm and expertise who would happily take over, should that turn out to be a problem. Thanks, Torsten