Another CSPRNG( os.urandom() + cutoff + int.from_bytes()) is considered if its faster than secrets.randbits()

I've run the brench mark wieh pyperf. It seems like os.urandom() might be faster.

    from os import urandom
    return int.from_bytes(urandom(2), 'big') & 0x3fff

so to sum up, may we use os.urandom() instead of random.getrandbits() in clock_seq and notes generations, and make clearer security clarifications in doc of UUIDv8? @picnixz

Hackers can predict the next UUID if they got 624*32 random bits generated from the previous UUIDs (1427 UUIDs will be enough).

To be precise, I should have said that this is assuming that the UUIDs are generated sequentially and that the underlying MT-19937 state is not touched in between, so it's a bit more complex.

so to sum up, may we use os.urandom() instead of random.getrandbits() in clock_seq and notes generations

I think I saw the benchmarks results somewhere. Can you post them in full as well? (I think you edited your message).

I'll treat this as a bugfix but not a security bug fix as it's not critical enough IMO.

so to sum up, may we use os.urandom() instead of random.getrandbits() in clock_seq and notes generations

I think I saw the benchmarks results somewhere. Can you post them in full as well? (I think you edited your message).

os.urandom(): Mean +- std dev: 205 ns +- 6 ns
random.getrandbits(): Mean +- std dev: 105 ns +- 5 ns
secrets.randbits(): Mean +- std dev: 17.6 us +- 2.3 us

pyperf on python 3.9

benchmark_UUID.json

Hackers can predict the next UUID if they got 624*32 random bits generated from the previous UUIDs (1427 UUIDs will be enough).

To be precise, I should have said that this is assuming that the UUIDs are generated sequentially and that the underlying MT-19937 state is not touched in between, so it's a bit more complex.

You're right. And there are also secruity warnings of uuid1() and uuid6() in docs. So its just not a serious problem.

pyperf on python 3.9

Can you test using the latest main branch instead of Python 3.9? TiA

I've done the benchmarks on my side and they are different:

$ ./python -m pyperf timeit -s "import random" "random.getrandbits(14)"
Mean +- std dev: 14.0 ns +- 0.3 ns

$ ./python -m pyperf timeit -s "import os" "int.from_bytes(os.urandom(2)) & 0x3fff"
Mean +- std dev: 555 ns +- 5 ns

$ ./python -m pyperf timeit -s "import secrets" "secrets.randbits(14)"
Mean +- std dev: 599 ns +- 5 ns

So we're still losing quite a lot of speed.

This is a very huge drop of performance. We're 25x times slower now. Since the node ID is cached, I think we can live with a CSPRNG. However resampling the clock sequence every time is too much of a performance loss, so we won't use it. However, we can add a note.

I've done the benchmarks on my side and they are different:

$ ./python -m pyperf timeit -s "import random" "random.getrandbits(14)"
Mean +- std dev: 14.0 ns +- 0.3 ns

$ ./python -m pyperf timeit -s "import os" "int.from_bytes(os.urandom(2)) & 0x3fff"
Mean +- std dev: 555 ns +- 5 ns

$ ./python -m pyperf timeit -s "import secrets" "secrets.randbits(14)"
Mean +- std dev: 599 ns +- 5 ns
So we're still losing quite a lot of speed.

My benchmark on 3.13:

os.urandom(): Mean +- std dev: 183 ns +- 7 ns
random.getrandbits(): Mean +- std dev: 75.0 ns +- 3.1 ns

Well yes, we are losing a quiet lot of speed

Correct. node ID is cached so even if its 25x slower we just need to generate it once.

So the new changes would be only in _random_getnode:

def _random_getnode():
	import secrets
	return secrets.randbits(48) | (1 << 40)

and some notes in docs?

Yes. But prefer using os.urandom instead of secrets. os is likely already imported (and 48 is already a multiple of 8 so it's easy)

Ok. I will post the final changes soon at the linked PR

For 3.13, I'll hold the backport because I need #134704, which I don't want to merge for a while (see #132901 (comment) for the rationale).