3 ms·

UUID4 random is 122 bit of randomness: https://gist.github.com/miohtama/6e72c2458a7138599dc1 https://gist.github.com/miohtama/6e72c2458a7138599dc1

masklinn 11y ago
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-f1c308c4fd9d#.7p2jjzxba https://medium.com/@betable/tifu-by-using-math-random-f1c308...
- im2w1l 11y ago
  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?
  - masklinn 11y ago
    > 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 https://news.ycombinator.com/item?id=10598065
  - revelation 11y ago
    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.
    - adrianN 11y ago
      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.
      - duaneb 11y ago
        > 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.
      - masklinn 11y ago
        > 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().
  - jjuhl 11y ago
    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-Considered-Harmful https://channel9.msdn.com/Events/GoingNative/2013/rand-Consi...
  - deleted 11y ago
    [deleted]
- PhantomGremlin 11y ago
  Here's the link to the 219 post HN discussion of that Medium post: https://news.ycombinator.com/item?id=10598065 https://news.ycombinator.com/item?id=10598065

masklinn 11y ago

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-f1c308c4fd9d#.7p2jjzxba https://medium.com/@betable/tifu-by-using-math-random-f1c308...

im2w1l 11y ago
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?
- masklinn 11y ago
  > 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 https://news.ycombinator.com/item?id=10598065
- revelation 11y ago
  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.
  - adrianN 11y ago
    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.
    - duaneb 11y ago
      > 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.
    - masklinn 11y ago
      > 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().
- jjuhl 11y ago
  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-Considered-Harmful https://channel9.msdn.com/Events/GoingNative/2013/rand-Consi...
- deleted 11y ago
  [deleted]
PhantomGremlin 11y ago
Here's the link to the 219 post HN discussion of that Medium post: https://news.ycombinator.com/item?id=10598065 https://news.ycombinator.com/item?id=10598065