Hacker News Reader

Comment by barathr | Hacker News Reader

Even simpler than implementing a cryptographic PRNG yourself, just use /dev/urandom, which will provide an infinite, non-blocking stream of cryptographically-strong pseudorandom bytes. All platforms currently have known-good implementations of /dev/urandom -- Linux uses ChaCha and MacOS and BSDs use Bruce Schneier's Fortuna.

View on HN

/dev/urandom is really slow compared to a userland CSPRNG, though. And if you are doing simulations or fuzz testing, you need to be able to seed your PRNG to get reproducible results.

You can always pre-fetch random bytes in larger blocks. Read a few kB of random bytes at a time, store them in a buffer, and refresh the buffer when you run out.

Agreed on the need for using a predictable seed for testing/simulations, though. Technically you can seed /dev/urandom, but it's per-system, not per-process, so you can't guarantee some other process isn't "interrupting" your random stream.

They weakened it recently in Linux again. For over a decade there was a badly bugged PRNG in the Linux kernel, it was discovered and replaced with a more costly one which worked great. Then, only a short time ago, they replaced that with one of... shady provenance. You're better off writing your own PRNG on that platform IMHO.

Jason Donenfeld (author of Wireguard) replaced Linux’s SHA-1 based PRNG (remember, SHA-1 is cryptographically broken) with BLAKE2. What is shady about it?

You can’t get cryptographically secure random numbers without platform support, so it’s really bad to tell people to avoid the kernel CSPRNG.

I simply don't trust NSA people and those who take their money. Why would you? We've seen nothing but shady moves from them in this space.

What are you talking about? Jason Donenfeld is the author of WireGuard, the extraordinarily popular VPN protocol that cannot use NIST cryptography (it does no negotiation, and is built on a version of Noise that uses ChaPoly and 25519). The change that was just described to you was a shift from NIST cryptography to non-NIST cryptography.

> that cannot use NIST cryptography

Do you mean as a matter of Donenfeld's engineering decisions (that those algorithms are unavailable in WireGuard)?

Yes: they use, for lack of a better term, DJB cryptography, and like many modern cryptosystems they eschew negotiation, so it's not straightforward to fit NIST algorithms in.

it's entirely straight-forward to substitute AES-256-GCM for ChaCha20/Poly1305 in Wireguard, and the result, while not "wireguard" is substantially faster than Wireguard.

Reply on news.ycombinator.com