linux-kernel - Re: [PATCH v2 1/4] random: use computational hash for entropy extraction

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: <CAHmME9pTDCUb7pAMeCMnU=jiAQd=ctrWN4K7s=8DqCtiOqbkrg@mail.gmail.com>
Date:   Sat, 5 Feb 2022 12:42:09 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        "Theodore Ts'o" <tytso@....edu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
Subject: Re: [PATCH v2 1/4] random: use computational hash for entropy extraction

On 2/5/22, Dominik Brodowski <linux@...inikbrodowski.net> wrote:
> Why are we only using RDRAND here, and not RDSEED?

Simply because that's what was already used here; I didn't revisit the
old decision. It seems like any changes there should be made in a
separate patch with its own justification. If you think there's good
rationale, free to send that.

Part of why these changes are so gradual is because much of random.c
isn't my code originally. Were it mine, I'd presumably know all my
various rationales and be able to rapidly think within them and
reevaluate. But because that's not the case, I find that I'm spending
a lot of time trying to reconstruct the original rationales of its
authors. IOW, rather than saying, "I don't get this, must be bad," I'm
trying to do a little bit of archeology to at least make sure I know
what I'm disagreeing with, if I even disagree at all. That's time
consuming in part, but also is part of doing things evolutionarily.

With regards to RDRAND vs RDSEED, just off the top of my head -- I'm
writing this email on my phone -- I think extract_entropy/extract_buf
used to be used as part of /dev/random's blocking stream, which
ostensibly could mean more frequent calls, once every 10 bytes IIRC.
Nowadays it's only called once every 5 minutes (per numa node), so
maybe RDSEED could make sense? Or maybe there are other reasons to
unearth, or none at all. We'll have to look and see.

Jason