Hacker News Reader

Comment by MichaelGG | Hacker News Reader

On Windows at least I had no trouble getting many hundreds of MBs/sec out of the default CSPRNG (which uses AES CTR or something like that) - even with small calls. (A customer was insisting that generating 16-byte IDs this way was too slow for production apps and was shown to be incorrect.) It'd be surprising if other OSes weren't around the same level.

View on HN

On Linux it's easy to benchmark this via e.g. `dd if=/dev/urandom of=/dev/null bs=1M`. On my somewhat old server (with Intel Core i5s from 2012), I'm getting 17 MB/s.

Supposing we blame slowness on syscall overhead: at a block size of 16 bytes instead of one megabyte, it slows down to all of 11.6 MB/s, that is, some 700,000 128-bit IDs per second. (And since we're not using SHA-1, all 128 bits are meaningful for collision resistance.) For comparison, Twitter gets about 1% that many tweets per second, globally.

If anyone has plans of scaling to 100 times the size of Twitter on a single 2012-era Core i5, and has figured everything else out already, I'll be happy to audit your userspace PRNG then.

What about the case of using Linux in a VM? Isn't there a possible problem with the amount of entropy available?

You only need 16-32 bytes to fully seed a CSPRNG real good. It's true that some VM setups have had issues, yes, but that shouldn't generally be the case. But a user mode generator isn't gonna do any better.

Reply on news.ycombinator.com