3 ms·
The problem is that /dev/random, and /dev/urandom in certain systems (it may be just a symbolic link to /dev/random in the extreme case), depletes soon and bloc
by antirez 11y ago
The problem is that /dev/random, and /dev/urandom in certain systems (it may be just a symbolic link to /dev/random in the extreme case), depletes soon and blocks until the OS can collect new entropy. Even when /dev/urandom can be used without ever blocking, like in Linux, it is slower than just computing SHA1(secret||counter).
For the goal of just getting the initial seed /dev/random is just good. So basically the method described works almost everywhere there is some even slow source of unguessable bits.
- e12e 11y agoI meant reading 160 bits, then counting up: start = 160bits from /dev/random next_id = start+1 Using a hash function would seem to be more random, but you're effectively walking a path that is no more random than enumerating all 160 bits numbers. I don't thing there's any guarantee that "walking" from 1 with sha1(1+inc), is any less likely to converge on sha1(bigint+inc), than "walking" from 1 and bigint by simply increasing by 1. On the other hand, if you had some sort of communication between nodes, it'd be trivial to predict if two instances would overlap, if you just kept incrementing "big random number 1" and "big random number 2". ed: If sha1 is a perfect hash function (I don't know if has been proven to be that?), then sha1sum(seed+inc) shouldn't be more likely to collide than seed+inc % 2^160. But if you have one such "random" identifier, you can of course much more easily guess previous/next identifiers, than if using a secure hash function. ed2: I suppose it should be obvious that given a pair of seed1+inc1=seed2+inc2, both plain iteration and sha1sum(seed+inc) will collide. I'm not sure if there are cases where (seed1+inc1, seed2+inc2)<2^160 [ed3: and seed1+inc1 != seed2+inc2 ] can collide after running them through sha1.