Received-SPF: pass (google.com: domain of linux-crypto+bounces-3957-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 30 Apr 2024 12:26:32 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Aaron Toponce <aaron.toponce@gmail.com>
Cc: Eric Biggers <ebiggers@kernel.org>, "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>, linux-kernel@vger.kernel.org,
        linux-crypto@vger.kernel.org
Subject: Re: [PATCH] random: add chacha8_block and swtich the rng to it
Message-ID: <20240430162632.GA1924352@mit.edu>
References: <20240429134942.2873253-1-aaron.toponce@gmail.com>
 <20240430031105.GA10165@sol.localdomain>
 <ZjB2ZjkebZyC7FZp@hercules>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZjB2ZjkebZyC7FZp@hercules>

On Mon, Apr 29, 2024 at 10:41:10PM -0600, Aaron Toponce wrote:
> > Note also that currently the Linux RNG is using a portable C
> > implementation of ChaCha20.  If there is actually a desire to
> > accelerate large reads (which again, aren't the main use case of
> > the Linux RNG), it would be possible to use a SIMD implementation
> > of ChaCha20, which already exists in the kernel.  That would speed
> > up ChaCha20 by roughly 2-5x depending on the CPU.
> 
> If ChaCha8 makes us uncomfortable, even though defensible, ChaCha12
> is a good compromise. As you mentioned, Google implemented ChaCha12
> in Adiantum. It offers a 1.67x speedup over ChaCha20 while still
> providing 5 additional rounds of security over the best known
> attack.

I'm not sure I see the point of trying to accelerate the Linux RNG.
Sure, doing "dd if=/dev/urandom" is *fun*, but what's the real world
use case where this actually matters?  The kernel RNG is meant for key
generation, where a much larger safety margin is a good thing, and
where absolute performance is generally not a big deal.

After all, with key generation generally you are also performing some
kind of assymetric key crypto as part of the IKE or TLS setup, and the
time to generate the session key is in the noise.  And if you are
trying to wipe a disk, using something like shred(1) is really the
right tool.

Ultimately this boils down to a risk/benefit tradeoff.  I judge the
risk that you are a shill sent by a nation-state security agency ala
Jia Tan of xz infamy, trying to weaken Linux's RNG to be very low; but
what's the benefit?  If the risk is low, but the benefit is also low,
maybe it's not worth it?

Cheers,

					- Ted