When it is safe to use weak random number generators?

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.

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

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.

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

Generating salt should be fine, no?

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