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
17
297
1,217
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
164
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
109
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
11
113
Replying to
The kernel is generating per-CPU batches of random numbers. Directly using the CSPRNG without a cache would have substantial locking overhead. That overhead is substantially higher for userspace since it needs to make system calls which have gotten substantially more expensive.
go-review.googlesource.com/c/go/+/370894 here's a batching patch I submitted for Go a few weeks ago.
1
In userspace, you also need to remember to use MADV_WIPEONFORK (ideally) or hooks to avoid leaking it into child processes and to make them get fresh data from the kernel. It's also genuinely quite difficult to do per-CPU caching rather than per-thread caching in userspace.
1
1
5
Consuming an extra page of memory per thread can be a real issue. Per-CPU caching can be done with restartable sequences but it's not simple.
Kernel CSPRNG is certainly higher throughput than most CSPRNGs now. Still need more performance to get people to stop using non-CS PRNGs.
1
4
Show replies