lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 19 Sep 2019 09:28:03 +0200
From:   Martin Steigerwald <martin@...htvoll.de>
To:     Lennart Poettering <mzxreary@...inter.de>
Cc:     Matthew Garrett <mjg59@...f.ucam.org>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "Theodore Y. Ts'o" <tytso@....edu>, Willy Tarreau <w@....eu>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8

Dear Lennart.

Lennart Poettering - 18.09.19, 15:53:25 CEST:
> On Mi, 18.09.19 00:10, Martin Steigerwald (martin@...htvoll.de) wrote:
> > > getrandom() will never "consume entropy" in a way that will block
> > > any
> > > users of getrandom(). If you don't have enough collected entropy
> > > to
> > > seed the rng, getrandom() will block. If you do, getrandom() will
> > > generate as many numbers as you ask it to, even if no more entropy
> > > is
> > > ever collected by the system. So it doesn't matter how many
> > > clients
> > > you have calling getrandom() in the boot process - either there'll
> > > be
> > > enough entropy available to satisfy all of them, or there'll be
> > > too
> > > little to satisfy any of them.
> > 
> > Right, but then Systemd would not use getrandom() for initial
> > hashmap/ UUID stuff since it
> 
> Actually things are more complex. In systemd there are four classes of
> random values we need:
> 
> 1. High "cryptographic" quality. There are very few needs for this in
[…]
> 2. High "non-cryptographic" quality. This is used for example for
[…]
> 3. Medium quality. This is used for seeding hash tables. These may be
[…]
> 4. Crap quality. There are only a few uses of this, where rand_r() is
>    is OK.
> 
> Of these four case, the first two might block boot. Because the first
> case is not common you won't see blocking that often though for
> them. The second case is very common, but since we use RDRAND you
> won't see it on any recent Intel machines.
> 
> Or to say this all differently: the hash table seeding and the uuid
> case are two distinct cases in systemd, and I am sure they should be.

Thank you very much for your summary of uses of random numbers in 
Systemd and also for your other mail that "neither RDRAND nor /dev/
urandom know a concept of of "depleting entropy"". I thought they would 
deplete entropy needed to the initial seeding of crng.

Thank you also for taking part in this discussion, even if someone put 
your mail address on carbon copy without asking with.

I do not claim I understand enough of this random number stuff. But I 
feel its important that kernel and userspace developers actually talk 
with each other about a sane approach for it. And I believe that the 
complexity involved is part of the issue. I feel an API for attaining 
random number with different quality levels needs to be much, much, much 
more simple to use *properly*.

I felt a bit overwhelmed by the discussion (and by what else is 
happening in my life, just having come back from holding a Linux 
performance workshop in front of about two dozen people), so I intend to 
step back from it. 

If one of my mails actually helped to encourage or facilitate kernel 
space and user space developers talking with each other about a sane 
approach to random numbers, then I may have used my soft skills in a way 
that brings some benefit. For the technical aspects certainly people are 
taking part in this discussion who are much much deeper into the 
intricacies of entropy in Linux and computers in general, so I just hope 
for a good outcome.

Best,
-- 
Martin


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ