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
Date: Tue, 30 Apr 2024 12:26:32 -0400 [thread overview]
Message-ID: <20240430162632.GA1924352@mit.edu> (raw)
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
next prev parent reply other threads:[~2024-04-30 16:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 13:48 [PATCH] random: add chacha8_block and swtich the rng to it Aaron Toponce
2024-04-30 3:11 ` Eric Biggers
2024-04-30 4:41 ` Aaron Toponce
2024-04-30 16:26 ` Theodore Ts'o [this message]
2024-04-30 16:44 ` Aaron Toponce
2024-05-01 2:22 ` Theodore Ts'o
2024-05-01 12:38 ` Jean-Philippe Aumasson
2024-05-01 14:02 ` Aaron Toponce
2024-05-01 12:21 ` Jason A. Donenfeld
2024-05-02 13:41 ` Aaron Toponce
2024-05-08 7:41 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240430162632.GA1924352@mit.edu \
--to=tytso@mit.edu \
--cc=Jason@zx2c4.com \
--cc=aaron.toponce@gmail.com \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).