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

10 pointsrapphil3y ago16 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?

16 comments

Grimburger3y ago

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.

byoung23y ago

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.

exmadscientist3y ago

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.

ralusek3y ago

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.

jmercan3y ago

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)

yarg3y ago

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

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

mod3y ago

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

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

Test01293y ago

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.

jcynix3y ago

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.

ericbarrett3y ago

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

wruza3y ago

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

Sohcahtoa823y ago

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.

redditor986543y ago

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.

duped3y ago

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

Rastonbury3y ago

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

majou3y ago

Generating salt should be fine, no?

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

j / k navigate · click thread line to collapse