Damn. has been the Linux random driver maintainer for like a hot minute, and /dev/[u]random is now 100% SHA-1 free and 370% faster. Amazing.
lore.kernel.org/lkml/202112231
lore.kernel.org/lkml/202112301
Conversation
When I say a hot minute, the MAINTAINERS patch was mailed 30 days ago. lore.kernel.org/lkml/202111301
You might know for making Wireguard (and getting it into Linux).
2
13
165
In case you missed it, the Linux CSPRNG is pretty good these days!
The extraction has been using ChaCha20 for a while. What just changes is that the entropy mixing will now use Blake2, which makes a lot of sense since it's the same core as ChaCha20.
1
12
110
When you make good crypto fast, you get to use it everywhere, which ends up making things more secure and robust.
Here's Jason replacing a "best effort" kernel RNG function with the CSPRNG. With how fast getrandom(2) is, applications can do the same!
lore.kernel.org/lkml/201612221
2
12
116
That urandom spends a lot of time in rdrand has been known for a while:
1
10
In the second link.
First line.
"RDRAND is not fast. RDRAND is actually quite slow. We've known this for
a while,"
9
How does this compare to OpenBSD's arc4random, in terms of performance and risk of starving/stalling etc.?
1
2
Not much of a difference, I would say, because BLAKE is a cryptographic hash function based on Dan Bernstein's ChaCha stream cipher. OpenBSD's arc4random uses ChaCha.
1
6
Show replies
I used to want a faster urandom for testing storage with dedupe, didn't need to be very random, just fast. I got half way through writing /dev/sdfrandom, would output sdsaasdfdsaas like when humans try to type randomly. Then found encrypting /dev/zero with h/w accel is blazing!
10