Conversation

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

297

1,217

Filippo Valsorda

@FiloSottile

Dec 31, 2021

When I say a hot minute, the MAINTAINERS patch was mailed 30 days ago. lore.kernel.org/lkml/202111301 You might know

@zx2c4

for making Wireguard (and getting it into Linux).

164

Filippo Valsorda

@FiloSottile

Dec 31, 2021

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.

buttondown.email

Cryptography Dispatches: The Linux CSPRNG Is Now Good!

Welcome back to Cryptography Dispatches, my lightly edited newsletter on cryptography engineering. This newsletter doesn't track you, so I'll only know...

109

Filippo Valsorda

@FiloSottile

Dec 31, 2021

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

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.

Replying to

and

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.

12:42 AM · Dec 31, 2021Twitter Web App

Replying to

and

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.

Replying to

and

I think it's finally reasonable to say people should simply use (batched) getrandom(...) output for nearly all use cases explicitly needing secure random numbers. There are still many use cases for random numbers not involving cryptography where people expect better performance.

Show replies