Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should random() be banned?

r2c.dev

Post reply on HN
Print view View original

211–214 of 214 posts

Re: Should random() be banned?

#211

Post by tgsovlerkhgsel »

fanf2 wrote: post #184
tgsovlerkhgsel wrote: post #133

Earlier quoted context omitted.

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, a…

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.

Re: Should random() be banned?

#212

Post by tatersolid »

zinkem wrote: post #32

I most commonly use random() for generating names (e.g. docker's container names) and generating test inputs. I don't care about cryptographic safety in either case.

But you probably care about collisions in that case. The small state of a language-default insecure PRNG will make collisions much more likely. Especially if seeded by a clock.

I have seen temp file name collisions cause data corruption in a real system because the default language RNG was used. Also infinite loops in a production system because random() was called in the same clock tick by two separate threads generating a handle value. Both wasted weeks of effort to pin down.

random() should default to the system CSPRNG. Provide insecureFastRandom() for those who know they need it and it is safe for their use.

Re: Should random() be banned?

#213

Post by wolf550e »

btilly wrote: post #57
tedunangst wrote: post #48

Earlier quoted context omitted.

So a simple linear generator is fine for an online poker game?

The claim that most uses of random() are not in places where cryptographic security is needed is not in conflict with any list of examples where it is needed. Here are the last several times I saw random() used. Seeding a neural network for a Coursera course. Not only do you need to call random() a bunch of times, but the ability to set a seed and get deterministic results makes grading of the results massively easie…

chacha8 (chacha20 but with fewer rounds) seeded with either a deterministic seed or from /dev/urandom (depending on what you need) is a perfectly fine PRNG, and should run at 4 GB/sec on a single core, which is plenty.

Only 7 rounds of chacha are cryptographically broken, so chacha20 has excessive security margin. Using 8 rounds of that everywhere you use random today (and not a CSPRING) should be a no-brainer, I guess.

On hardware with AESNI (like all x86 for the last 10 years), a reduced round AES-CTR should be very fast and also string enough for the cases when you don't need a CSPRING. Full AES-128 outputs 4.7GB/sec on my laptop, recent chips have better AES throughput.

Re: Should random() be banned?

#214

Post by IcePic »

Quillbert182 wrote: post #187
IcePic wrote: post #174

Earlier quoted context omitted.

I think those built-in RNGs should be treated like RDRAND on x86, you may mix them into the pool along with all the other sources of entropy your platform supplies, and then generate cryptographic streams seeded out of the pool. Using them alone might turn out to be a bad idea in the long run.

Would /dev/random be the combined entropy?

No, that would be the output of some hash/crypto stream(s) that in turn gets seeded by all the entropy sources the machine can find, mixed together.
Post reply on HN