Hacker News Reader

Comment by tgsovlerkhgsel | Hacker News Reader

I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications.

The main arguments I've seen are speed and determinism.

However, a cryptographically secure, deterministic PRNG can be built from hash or block cipher primitives that have hardware acceleration, making them quite fast. Seed (and potentially periodically re-seed) it from a strong source of randomness, and you've got a fast and cryptographically secure non-deterministic PRNG.

I thought that "classic" PRNGs like the widespread Mersenne Twister even had issues that can cause practical problems when used in certain kinds of simulations (Monte Carlo, possibly) that rely on large amounts of random numbers, but I haven't been able to find a clear source for this.

I'm certainly defaulting to secure ones, and I'm surprised modern languages and libraries don't do this by default for their standard randomness functions.

View on HN

> I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications.

Because for well over 99.99% of developers, cryptography is a “niche application”.

I’ve never written crypto code I’ve deployed anywhere. If I need crypto, I use the highest level crypto library I can find that people I trust who _do_ know about crypto recommend.

The only time I ever recall non cryptographic random() functions to have surprised or affected me was way back when I discovered if you forgot to seed the random on an AppleII the games I wrote in Basic all started out with the same “random” choices.

It's true that most people who aren't doing sensitive work don't need cryptographically secure random number generators, but if you use something secure by default, it probably won't cause problems, and to the extent that it does you can catch them with some profiling. If you use insecure RNG by default, it probably won't cause problems but if it does you'll find them when a black hat hacker compromises your system in production.

Very few people set out to roll their own crypto. The issue in my experience is less about someone writing their own hand-optimized password hash function and more about people having overly-narrow views of what counts as security critical code.

Cryptography is rare, but generating other data that needs to be unpredictable (e.g. session IDs, password reset tokens, random passwords getting generated, gift card codes, real-money gambling numbers) is quite common, I think.

And the default implementation of random() doesn't seem to be any faster than AES-CTR (which is the core of one form of secure PRNG).

The problem is the “banning” things as suggested in the article leads to bullshit like FIPS 140-2 mode.

So MD5 hashes are disabled in the system library for applications where it is not presenting any meaningful risk, for example. The other issue is that bans usually come with lists of things are not aren’t banned. So now you are stuck with waiting for some disinterested committee to support something that delivers a benefit.

Use the minimal amount of resources and scale up. If you need mostly random don't force cryptographic level random. It adds unnecessary processor cycles and reduces speed.

I benchmarked it, and AES-CTR is faster than `random()` on a machine with AES-NI.

That's my main point: It does _not_ seem to be meaningfully more expensive to use cryptographic randomness. Yes, you could build a faster non-cryptographic PRNG, but that's not what is done by the default library.

The most common case for me is when fuzzing, when I want reproducible random numbers, so it must be possible to initialize the RNG from a known fixed seed so that I can re-run and debug a failure.

Hence my suggestion to use a deterministic cryptographic generator: This way, you can either get "proper" randomness by seeding it with a random value, or predictable (and yet strong against anyone who doesn't know the seed) randomness by seeding with a fixed value.

Reply on news.ycombinator.com