Use CSPRNG for random UUID node ID

[LamentXU123]

Feature or enhancement

Proposal:

Issue for: #135226
(I forgot to open issue first, sry)
I'll do the benchmark of the performance impact when switching to secrets.getrandbits() for the clock sequence soon. I'll post here.
I totally agree with the previous discussion. Summary:

• Maybe make it more clearer in the docs of UUIDv8(?) Its possible to predict UUIDv8 if hackers have collected enough UUIDs. BUT, UUIDv8 is highly customizable. It's pretty ez if someone wants to use CSPRNG in UUIDv8s by writing a wrapper outside the call(or using UUIDv4 instead lol).
• Change _random_getnode() from PRNG to CSPRNG which randomly generates 48-bits note when python failed to get MAC address

def _random_getnode():
+	import secrets
+	return secrets.randbits(48) | (1 << 40)
-	import random
-	return random.getranbits(48) | (1 << 40)

• Change the logic when generating clock_seq from PRNG to CSPRNG in both uuidv1() and uuidv6(). Well I think this is of great importance. Those two algorithm are time-based. The only random thing comes from clock_seq. Hackers can predict the next UUID if they got 624*32 random bits generated from the previous UUIDs (1427 UUIDs will be enough).

def uuid1(node=None, clock_seq=None):
    ...
    if clock_seq is None:
+       import secrets
+       clock_seq = secrets.randbits(14) # instead of stable storage
-		import random
-		clock_seq = random.getrandbits(14) # instead of stable storage
    ...

def uuid6(node=None, clock_seq=None):
    ...
+       import secrets
+       clock_seq = secrets.randbits(14) # instead of stable storage
-		import random
-		clock_seq = random.getrandbits(14) # instead of stable storage
    ...

note that nothing will be changed if the performance impact is unacceptable.

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

#135226

Linked PRs

• gh-135244: use CSPRNG for random UUID node ID #135226
• [3.14] gh-135244: generate UUID random Node ID with a CSPRNG as per RFC 9562, §6.10.3 (GH-135226) #135255
• gh-135244: improve wording of uuid8 docs about CSPRNG #135433
• [3.14] gh-135244: improve wording of uuid8 docs about CSPRNG (GH-135433) #135467

[LamentXU123]

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

[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.

[picnixz]

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).

[picnixz]

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