linux-kernel - Re: [PATCH] random: add chacha8_block and swtich the rng to it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240430162632.GA1924352@mit.edu>
Date: Tue, 30 Apr 2024 12:26:32 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Aaron Toponce <aaron.toponce@...il.com>
Cc: Eric Biggers <ebiggers@...nel.org>, "Jason A. Donenfeld" <Jason@...c4.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>, linux-kernel@...r.kernel.org,
        linux-crypto@...r.kernel.org
Subject: Re: [PATCH] random: add chacha8_block and swtich the rng to it

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