Why not just use version 4 UUIDs? In Python, at least, they are generated directly from /dev/urandom.
1) It's not better than the method I suggested, but requires to use I/O for every generated ID. So without gaining anything you lose performances. In fact you could imagine /dev/urandom as a more complex form of an hash function in "counter mode". Given that for this application, cryptographic properties are not needed, but only good distribution, the two methods are identical but one is very fast and one is slower.
2) /dev/urandom in certain systems, notably OSX, at some point may block for some time, it is not guaranteed to be always able to generate a stream of random numbers. Certain operating systems may generate only a given amount of stream to /dev/urandom, starting with a given amount of entropy they have in the pool. If the seed cannot be renewed with new entropy the OS may block readers on /dev/urandom. I think this implementation does not make much sense and /dev/urandom should always provide output as long as the original seed had enough entropy, but implementations may vary, and you cannot ignore OSX.
Also, I can't find references to OS X or any other OS blocking on urandom reads. Can you point me to one?
This is not true. OS X has the same behavior as the BSDs: /dev/urandom is a compatibility symlink to /dev/random, and neither device blocks.
https://developer.apple.com/library/mac/documentation/Darwin...
"Yarrow is a fairly resilient algorithm, and is believed to be resistant to non-root. The quality of its output is however dependent on regular addition of appropriate entropy. If the SecurityServer daemon fails for any reason, output quality will suffer over time without any explicit indication from the random device itself."
The only device node that's broken in this way is Linux's /dev/random.
I highly doubt unique ID generation is going to be the bottle neck in your app. Even if is, while your method is faster, it is not that much faster; for me in Python:
In [15]: %timeit hashlib.sha1(b'100'+seed).digest()
1000000 loops, best of 3: 632 ns per loop
In [17]: %timeit dev_urand.read(20)
100000 loops, best of 3: 1.08 µs per loop
In [22]: %timeit uuid.uuid4()
10000 loops, best of 3: 15.7 µs per loopI haven't tried OS X, but given that it also uses a PRNG (Yarrow) for /dev/random, I would expect it to behave similarly. Are you able to reproduce the described behavior?
However, the same applies to the method from this article.