Hacker News Reader

Comment by miohtama | Hacker News Reader

UUID4 random is 122 bit of randomness:

https://gist.github.com/miohtama/6e72c2458a7138599dc1

The point here is that UUID4 is only as random as the underlying source of randomness. If the source of randomness is garbage your UUID4 is garbage as well. v8's Math.random() does not even remotely come close to a CSPRNG, and as a post a few days ago noted[0] it has a very, very small cycle length, so you can easily (via brute-force) find where in the cycle it was when it generated a given value, and enumerate all the UUIDs it could generate.

[0] https://medium.com/@betable/tifu-by-using-math-random-f1c308...

C's rand() is typically poor as well. Thought it was par for the course for builtin rng to be somewhat shitty, but maybe other languages stack up better?

C's rand() (rather, your libcs rand()) is perfectly fine for what it's supposed to be: fast random data, with no particular guarantees to cryptographic security, for things like randomized algorithms or the 99% of cases where you're picking what powerup to spawn instead of generating super important key material.

To make it into a CSPRNG would be a detriment. The only thing I would change is to have a minimum cycle length.

No, C's rand is unsuited for most randomized algorithms. MCMC algorithms won't work with rand unless you're lucky, it's even unsuited for choosing pivots for quicksort. The only application where it might be ok is games.

> The only application where it might be ok is games.

This is silly, there are plenty of ways randomness is used to communicate randomness to the user (think games, song shuffling, visualizations, art, etc. Algorithms using randomness ≠ randomized algorithms.

> The only application where it might be ok is games.

Not even that. Different types of games require different types of RNGs (e.g. in an RPG or strategy game you probably want a stable seeded RNG to preclude RNG save-scumming), the C standard requires almost no guarantee of rand().

> Thought it was par for the course for builtin rng to be somewhat shitty, but maybe other languages stack up better?

That seems to be pretty common, although v8's seems especially terrible. In thread linked by PhantomGremlin[0] pcwalton also points out that stronger RNG can be "detrimental" to benchmarks if they're slower, as many benchmarks ultimately bench the speed of the basic RNG (or for an other issue in the same category the speed of the basic hash function), so the incentive for builtin RNGs is to be fast and cheap, not to be good.

[0] https://news.ycombinator.com/item?id=10598065

Luckily we have <random> in modern C++ these days. While they unfortunately left the default as implementation defined you can still manualy pick a good PRNG and random_device should give you good CSPRNG quality entropy in any sane implementation (although I wish they would formally say that it couldn't be based on a PRNG).

Also worth checking out: https://channel9.msdn.com/Events/GoingNative/2013/rand-Consi...

Here's the link to the 219 post HN discussion of that Medium post:

https://news.ycombinator.com/item?id=10598065

Reply on news.ycombinator.com