TIFU by using Math.random()

medium.com

11 points·msoad··4 comments

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?

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.

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?

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.

Reply on news.ycombinator.com