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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZjOX_4aGUoY0msib@hercules>
Date: Thu, 2 May 2024 07:41:19 -0600
From: Aaron Toponce <aaron.toponce@...il.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Theodore Ts'o <tytso@....edu>, 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 Wed, May 01, 2024 at 02:21:35PM +0200, Jason A. Donenfeld wrote:
> There are probably better ways of speeding this up (e.g. my vDSO work,
> which should be coming back soon) than just removing rounds and hoping
> for the best.
> 
> The problem is that there's extremely broad consensus that ChaCha20 is
> good at what it does. There's much less so for ChaCha8. JP's _probably_
> right, and it all seems like a sensible risk analysis...maybe...but
> also, why play with fire? Is it really worth it? I don't think there's
> much harm done in being really conservative about all this.
> 
> Another consideration with the RNG is that most everybody else's crypto
> relies on the RNG being good. If some consumer of the RNG wants to use
> single DES, so be it. If another consumer wants to use a cascade of
> ChaCha20 and AES and Serpent and Keccak for something, okay. Those
> aren't our choices. But we shouldn't prevent those choices by weakening
> the RNG.
> 
> So while it *might* be kinda overkill, there's also broad consensus that
> what we've got is *definitely* sufficient for all uses. At the same
> time, it's still pretty darn fast, there exist other ways to make it
> faster, and I don't think it's /overly/ much.

ChaCha20 reminds me of cascading encryption actually. That's a good analogy.
VeraCrypt offers several cascading options choices, such as AES(Twofish),
AES(Twofish(Serpent)), Kuzneychik(Serpent(Camellia)), etc. While there isn't
anything technically wrong with the approach, most security-minded folks would
agree it's overkill. Using just AES, or just Twofish, or just Serpent is more
than sufficent. ChaCha20 is kind of like that. It's extra security because "just
in case".

ChaCha8 is certainly aggressive. As another analogy, it's a 10 character random
password. While a 10 character password hashed with MD5 is *probably* fine at 65
bits, 13 random characters (80 bits) would definitely be safer. But 20 random
characters (128 bits) is certainly overkill to protect against even the most
well-funded orgs with distributed GPU resources cracking password hashes.

ChaCha12 seems like a good compromise. It's 5 rounds of security away from the
latest known attack while also providing a solid performance improvement.

Cheers,

-- 
 o .   o . o   . . o   o . .   . o .
 . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o