Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Thu, 20 Jan 2022 18:39:31 +0800
Message-ID: <CACXcFm=67TU=wy-WdkpiGnSm2M-E5__z=ACTzCmOkiGijrWNOg@mail.gmail.com>
Subject: random(4) question
To:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>, "Ted Ts'o" <tytso@mit.edu>,
        Herbert Xu <herbert@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

I see this in the current random.c

/* Note that EXTRACT_SIZE is half of hash size here, because above
 * we've dumped the full length back into mixer. By reducing the
  * amount that we emit, we retain a level of forward secrecy.
  */
   memcpy(out, hash, EXTRACT_SIZE);

Like the previous version based on SHA1, this produces an output half
the hash size which is likely a fine idea since we do not want to
expose the full hash output to an enemy. Unlike the older code,
though, this does expose some hash output.

The older code split the 160-bit hash in half and XORed the halves
together to get an 80-bit output. Should we do that here for 256-bit
output?

Dan Bernstein has something called "SURF: Simple Unpredictable Random
Function." that takes 384 bits in & gives 256 out.
https://cr.yp.to/papers.html#surf
I'm not sure that would work for us since it needs a 1024-bit key and
has 32 rounds, but it seems worth considering.