
TIFU by using Math.random() - msoad
https://medium.com/@betable/tifu-by-using-math-random-f1c308c4fd9d#.3jpkwpclj
======
0x0
Why use a PRNG at all, instead of just an incrementing counter? The PRNG is
kind-of sequential anyways, since it works on its previous state, its pattern
is just a little more obfuscated?

Even for the distributed case, how would a PRNG be better than an incrementing
counter - perhaps where the high bits are locked down to an instance ID?

~~~
mmalone
Calling a PRNG is way easier than any of the alternatives. Coordinating
sequences on a bunch of nodes so that nobody overlaps is a pain in the ass,
and a point of failure. Incorporating some notion of "machine ID" in the
identifier makes it easier, but you still have to worry about multiple pieces
of software on the same machine, for example. UUIDs are the a good solution,
but you need a UUID library you trust, and they waste a lot of space / are
overkill for many use cases.

All of that is sort of beside the point though. Pseudo-random sequences are
useful for lots of things and the PRNG algorithm behind Math.random() is
pretty crappy.

~~~
0x0
If you don't want a machine ID to segment the counters:

What if you use a PRNG to initially seed an incremental counter? I don't
really see how that would that be weaker than using a PRNG for each value? Is
it just that the obfuscated period and pattern of a PRNG makes it "feel" less
likely to collide?

~~~
Someone
If you use a PRNG to seed an incremental counter on every node, and you get
one collision, you are bound to get zillions of them.

On the plus side, I think that means the risk that you get a collision is
smaller.

Also, using bare incrementing counters may be a bad idea for different
reasons: it allows attackers to guess IDs of future messages. You can
counteract that by hashing the IDs using a good cryptographic hash function,
but that effectively turns your ID generating process into a PRNG.

