linux-kernel - Re: Linux 5.3-rc8

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]

Message-ID: <20190916170028.GA15263@mit.edu>
Date:   Mon, 16 Sep 2019 13:00:28 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Lennart Poettering <mzxreary@...inter.de>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8

On Sun, Sep 15, 2019 at 08:40:30PM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 8:23 PM Theodore Y. Ts'o <tytso@....edu> wrote:
> >
> > But not blocking is *precisely* what lead us to weak keys in network
> > devices that were sold by the millions to users in their printers,
> > wifi routers, etc.
> 
> Ted, just admit that you are wrong on this, instead of writing the
> above kind of bad fantasy.
> 
> We have *always* supported blocking. It's called "/dev/random". And
> guess what? Not blocking wasn't what lead to weak keys like you try to
> imply.
> 
> What led to weak keys is that /dev/random is useless and nobody sane
> uses it, exactly because it always blocks.

How /dev/random blocks is very different from how getrandom(2) blocks.
Getrandom(2) blocks until the CRNG, and then it never blocks again.
/dev/random tries to do entropy accounting, and it blocks randomly all
the time.  *That* is why it is useless.  I agree that /dev/random is
bad, but I think you're taking the wrong message from it.  It's not
that blocking is always bad; it's that insisting on entropy accounting
and "true randomness" is bad.

The getrandom(2) system call is modelled after *BSD's getentropy(2)
call, and the fact that everyone is using is because for most use
cases, it really is the right way to go.

I think that's the core of my disagreement with you.  I agree that
what /dev/random does is wrong, and to date, we've kept it for
backwards compatibility reasons.  Some of these reasons could be
rational, or at least debated.  For example, GPG wants to use
/dev/random because it thinks it's more secure, and if they are
generating 4096 bit RSA keys, or something else which might be
"post-quantuum cryptography", it's possible that /dev/random is going
to be better than the CRNG for the hyper-paranoid.  Other use cases,
such as some PCI compliance labs who think that getrandom(2) is not
sufficiently secure, are just purely insane --- but that's assuming
today's getrandom(2) is guaranteed to return cryptographically strong
results, or nothing at all.

If we change the existing behavior of getrandom(2) with the default
flags to mean, "we return whatever we feel like, and this includes
something which looks random, but might be trivially reverse
engineered by a research engineer", that is in my mind, a Really Bad
Thing To Do.  And no, a big fat warning isn't sufficient, because
there will be some systems integrators and application programmers who
will ignore the kernel warning message.  They might not even look at
dmesg, and a system console might not exist.

					- Ted