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-next>] [day] [month] [year] [list]
Message-ID: <20201130151231.GA24862@lst.de>
Date:   Mon, 30 Nov 2020 16:12:32 +0100
From:   Torsten Duwe <duwe@....de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Theodore Y. Ts'o" <tytso@....edu>,
        Stephan Müller <smueller@...onox.de>,
        Willy Tarreau <w@....eu>, linux-crypto@...r.kernel.org,
        Nicolai Stange <nstange@...e.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        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>,
        zhangjs <zachary@...shancloud.com>,
        Andy Lutomirski <luto@...nel.org>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Peter Matthias <matthias.peter@....bund.de>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Neil Horman <nhorman@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        And y Lavr <andy.lavr@...il.com>,
        Eric Biggers <ebiggers@...nel.org>, ardb@...nel.org,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Petr Tesarik <ptesarik@...e.cz>, simo@...hat.com
Subject: 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ