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>
 <CAHmME9ouMHtTQxB1WHq3H+nfbg27OFaJtw78E5epCJsiHt3sHg@mail.gmail.com> <daffe6272525376d955a4eaa73263a7f08634ac1.camel@redhat.com>
In-Reply-To: <daffe6272525376d955a4eaa73263a7f08634ac1.camel@redhat.com>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Wed, 2 Feb 2022 15:10:57 +0100
Message-ID: <CAHmME9ohMLtfBgF752XCq-EOk5SRGcNkf-vf1oawXEkz9iOTtw@mail.gmail.com>
Subject: Re: [PATCH] random: use computational hash for entropy extraction
To:     Simo Sorce <simo@redhat.com>
Cc:     Stephan Mueller <smueller@chronox.de>,
        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 Simo,

Your message makes no sense to me.

> Note that there is no study
> about using internal states of hash functions, it would be better to

Ignoring your probably wrong mention about "no study", we're not
making any use of "internal states". We're using the hash function off
the shelf without modifications. There's no whacky bespoke crypto
going on, no use of "internal states", nothing that matches your
description.

> if the current code is mistakenly stretching the entropy, perhaps the
> correct curse of action

Except it's not. The non-underscore version calls into account(), and
returns false when it's not sufficiently full. I'm also not sure it
matters in the way you think it does; perhaps you could clarify what
you mean by "mistakenly stretching the entropy" and what you think
this enables.

> they are stretching the entropy, the risk is compounding errors and

Compounding errors? This doesn't make any sense.

> It would also be nice to have an explanation (in the patch or at least
> the commit message) about how entropy is preserved

That iterative hashing serves as a good entropy accumulator is
rigorously shown in the paper that the commit message references.

And either way, we never reseed the crng with more than 32 bytes, so
what's happening here is rather boring.

Thanks,
Jason