You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
3.13 needs a backport but we need to wait until the MAC address detection PR is merged (see #135244 (comment)), as otherwise, there is a small penalty at import time and upon first use of uuid1() and uuid6().
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:
_random_getnode()from PRNG to CSPRNG which randomly generates 48-bits note when python failed to get MAC addressclock_seqfrom PRNG to CSPRNG in bothuuidv1()anduuidv6(). Well I think this is of great importance. Those two algorithm are time-based. The only random thing comes fromclock_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
uuid8docs about CSPRNG #135433uuid8docs about CSPRNG (GH-135433) #135467Note
3.13 needs a backport but we need to wait until the MAC address detection PR is merged (see #135244 (comment)), as otherwise, there is a small penalty at import time and upon first use of uuid1() and uuid6().