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
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.
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
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 <[email protected]> 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
On Fri, 18 Dec 2020 10:25:19 -0300
Marcelo Henrique Cerri <[email protected]> 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
On Wed, 23 Dec 2020 13:28:51 +0100
Torsten Duwe <[email protected]> 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
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.
On Wed, 23 Dec 2020 15:32:55 +0100
"Jason A. Donenfeld" <[email protected]> wrote:
> On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik <[email protected]> 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
Hi Peter,
On Wed, Dec 23, 2020 at 5:01 PM Petr Tesarik <[email protected]> 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
On Wed, Dec 23, 2020 at 5:03 PM Jason A. Donenfeld <[email protected]> wrote:
>
> Hi Peter,
>
> On Wed, Dec 23, 2020 at 5:01 PM Petr Tesarik <[email protected]> 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
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
Hi!
> > On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik <[email protected]> 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
Pavel Machek <[email protected]> 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.