Ask HN: When it is safe to use weak random number generators? | Hacker News Reader

Ask HN: When it is safe to use weak random number generators?

10 pointsrapphil16 comments

I could not find any definitive material about this topic, but when is it safe to use weak random number generators?

I would say:

  * Generating random passwords - no
  * Generating salt - no
  * Jitter in a Retry Strategy - yes

Anything else?

What rules can we apply here?

View on HN

State your use-case?

"Strong" and "weak" is a sliding scale between indifference and tin-foil paranoia. Plenty of low-end embedded devices have questionable rng's but it's enough for them to make tls requests.

In many modern cryptosystems keys are ephemeral, there's a relatively small window to exploit weak rng's knowing the full state of the system. Long-lived keys are a different story, especially those generated soon after booting.

> Generating salt - no

A salt can be an incrementing number that is publicly known, they are not required to be secret. Using email as a salt is perfectly fine and poses no risk.

When there is nothing to be gained from guessing the random number (to the point where you could just hardcode it, then it is safe to use a weak random number generator. Examples would be randomizing background images in a website header or picking a random quote of the day from a list.

If there is a benefit to guessing the random number, then use a secure random number generator. Anything related to passwords, private keys, or anything you expect to be reasonably hard to guess, use a secure number generator.

Weak generators can also cause trouble in non-security-related applications. Monte Carlo simulations or integrations run with generators that don't truly randomly sample with respect to the underlying structure of the problem can go quite badly wrong. This usually requires a truly awful generator, but you'd be surprised what can happen. These days there is really no excuse to use anything worse than the Mersenne Twister for mathematical uses.

I think what you're talking about would be random numbers with a poor distribution, which is important to distinguish from random numbers with poor unpredictability.

Frankly, if you have to ask, just use a (system) CSPRNG.

People massively overblow the impact of the speed difference for most scenarios. Yes, A simulation running on a large scale etc. will probably need a statistically good RNG w/o any security properties but (say) a game generating a seed occasionally will not be bottlenecked by using a CSPRNG. I would say it is worth it just to not have any mental load and slightest change of misuse.

Also, if the salt part is for salting and hashing passwords, forget about the whole idea and use a proper password hash be it Argon2id, scrypt, PBKDF2, whatever. It doesn't really matter which one and ideally a library should have chosen one of the algorithms with good parameters and nonce generation.

(I know Argon2 calls its nonce a salt too but that is irrelevant. It should come from a CSPRNG)

In video games (and anywhere else where speed matters but quality doesn't).

https://doom.fandom.com/wiki/Pseudorandom_number_generator

Unless the video game is poker, in which case it does matter.

https://www.datamation.com/applications/how-to-cheat-at-onli...

There's no hard, fast rule for when a weak PRNG is bad except in the obvious use cases - salts, etc. There's no reason you can't use a weak random number generator for generating a password. It only becomes a problem when you have a bunch of passwords, stored in the same place, generated with a weak PRNG, AND the adversary knows the PRNG and how they were generated.

It really comes down to threat surface and likelihood of attack. CSPRNGs are cheap enough to run that you can just use one all the time these days with no loss. The problem is the esoteric math they rely on means that you're giving up some control of your threat surface (unless you understand cryptanalysis with modern crypto). So generally, you can just always use a CSPRNG due to cheap execution time, with the understanding you then become vulnerable to attacks like the ECC attack where adversarial mathematicians know more than you about your own security.

Erasing a hard disc (i.e. spinning rust, not solid state ones) before retiring it is a proper use case. Linux/Unix example:

  dd if=/dev/urandom bs=8mb of=/dev/sda

Note: this is a trivial example, which could be optimized in various ways, e.g. by generating one 8mb file of randomness and reusing that, especially if your urandom is slow.

Data recovery on overwritten hard drives haven't been feasible since the 90s. A zero-wipe is sufficient!

2008 paper [PDF]: https://www.researchgate.net/profile/Craig-Wright-6/publicat...

Thanks, I always thought that these 7-pass DoD methods must be an insane overkill.

It basically boils down to one question:

What are the ramifications of a malicious user being able to predict the RNG results with 100% accuracy?

For generating passwords and encryption keys, obviously predicting RNG is Game Over. For choosing random colors to put on a graph, it's meaningless.

What about a simplistic version of A/B testing. Like I have a piece of code that should execute x% of the requests (typically 1-2%) to test that it works well before rolling it out for all requests.

Noise generation, fuzzing, map/terrain or procedural generation in games, etc where you need randomness and someone replicating the same sequence isn't a threat

Reminds me of how people on the scicraft minecraft server manipulated RNG to get lightning to strike the same spot every game tick. But yeah not really a threat

Generating salt should be fine, no?

It's to thwart rainbow tables and ensure unique hashes for users with the same passphrase.

Reply on news.ycombinator.com