4 ms·

Even simpler than implementing a cryptographic PRNG yourself, just use /dev/urandom, which will provide an infinite, non-blocking stream of cryptographically-st

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.

steponlego 3y ago
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.
- fanf2 3y ago
  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.
  - steponlego 3y ago
    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.
    - tptacek 3y ago
      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.
      - schoen 3y ago
        > that cannot use NIST cryptography Do you mean as a matter of Donenfeld's engineering decisions (that those algorithms are unavailable in WireGuard)?
        tptacek 3y ago
        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.
        gonzo 3y ago
        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.
fanf2 3y ago
/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.
- kelnos 3y ago
  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.
deleted 3y ago
[deleted]

steponlego 3y ago

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.

fanf2 3y ago
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.
- steponlego 3y ago
  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.
  - tptacek 3y ago
    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.
    - schoen 3y ago
      > that cannot use NIST cryptography Do you mean as a matter of Donenfeld's engineering decisions (that those algorithms are unavailable in WireGuard)?
      - tptacek 3y ago
        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.
        gonzo 3y ago
        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.

fanf2 3y ago

/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.

kelnos 3y ago
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.

deleted 3y ago

[deleted]