Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220201161342.154666-1-Jason@zx2c4.com> <1920812.EuvsCRJjSr@tauon.chronox.de>
In-Reply-To: <1920812.EuvsCRJjSr@tauon.chronox.de>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Wed, 2 Feb 2022 13:23:21 +0100
Message-ID: <CAHmME9ouMHtTQxB1WHq3H+nfbg27OFaJtw78E5epCJsiHt3sHg@mail.gmail.com>
Subject: Re: [PATCH] random: use computational hash for entropy extraction
To:     Stephan Mueller <smueller@chronox.de>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        "Theodore Ts'o" <tytso@mit.edu>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Stephan,

It's like this for a few reasons:

- Primarily, we want to feed 32 bytes back in after finalization (in
this case as a PRF key), just as the code does before this patch, and
return 32 bytes to the caller, and we don't want those to be relatable
to each other after the seed is erased from the stack.
- Actually, your statement isn't correct: _extract_entropy is called
for 48 bytes at ~boot time, with the extra 16 bytes affecting the
block and nonce positions of the chacha state. I'm not sure this is
very sensible to do -- it really is not adding anything -- but I'd
like to avoid changing multiple things at once, when these are better
discussed and done separately. (I have a separate patch for something
along those lines.)
- Similarly, I'd like to avoid changing the general idea of what
_extract_entropy does (the underscore version has never accounted for
entropy counts), deferring anything like that, should it become
necessary, to an additional patch, where again it can be discussed
separately.
- By deferring the RDRAND addition to the second phase, we avoid a
potential compression call while the input pool lock is held, reducing
our critical section.
- HKDF-like constructions are well studied and understood in the model
we're working in, so it forms a natural and somewhat boring fit for
doing what we want to do.

Regards,
Jason