linux-kernel - Another batched entropy idea

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: <20200330024511.GB4206@SDF.ORG>
Date:   Mon, 30 Mar 2020 02:45:11 +0000
From:   George Spelvin <lkml@....ORG>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     linux-kernel@...r.kernel.org, lkml@....org
Subject: Another batched entropy idea

Posting all those patches has depressurized my brain and let me think of 
additional ways to speed up batched random number generation, taking 
advantage of the fact that we don't have to anti-backtrack the key.

Rather than using the primary_crng and its lock, use a global 256-bit key, 
and give each CPU a disjoint 64-bit sequence number space.
(for (seq = raw_smp_processor_id(); ; seq += NR_CPUS).)

Then, when a CPU needs to refill its batched pool, copy over the constant, 
the global key, the per-cpu sequence number, do something TBD with the 
nonce, and run ChaCha on the result.

And voila, no global locking ever, unless a reseed interval has elapsed.

(We could also consider using 12 <= r < 20 ChaCha rounds for the batch.
After all, the best attack is <8 rounds and eSTREAM recommends 12.
16 might be reasonable.)