Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye integers, hello UUIDv7

buildkite.com

Post reply on HN
Print view View original

81–90 of 376 posts

Re: Goodbye integers, hello UUIDv7

#81

Post by paulddraper »

stepanhruda wrote: post #23
chacham15 wrote: post #9

Earlier quoted context omitted.

They can be bad for performance. It all depends on your access patterns. A common caching pattern is called "temporal locality" which means that theres a high likelihood that data created at the same time will be accessed at the same time. Therefore, if these pieces of information are on the same machine, they can be queried / returned much faster than if they were both on separate machines. This is doubly true if th…

Yes but if that machine with sequential data receives 100x the traffic of other machines, it can be worse than splitting this traffic evenly across all available machines.

It depends if you have a request covers a lot of sequential data, or if you have a lot of requests of sequential data.

Re: Goodbye integers, hello UUIDv7

#82

Post by rhaps0dy »

BWStearns wrote: post #78
andrewmatte wrote: post #51

Earlier quoted context omitted.

jonhohle, thanks. Do you know of examples of when milliseconds are part of the session tokens or accounts being created has been exploited?

I could imagine using the timestamp segment of publicly observable ids to estimate activity patterns in an organization. Probably not super crucial and there are probably easier ways in most cases but it could be a big deal at the right moment and for the right target. This could be like a more refined version of PIZZAINT (where you can detect impending policy/operational movements by the quantity of food deliveries…

Is PIZZAINT real? I thought it was a joke. How do you even find out how much pizza is being delivered?

Re: Goodbye integers, hello UUIDv7

#83

Post by hawski »

kijin wrote: post #63
jiggawatts wrote: post #38

It seems insane to me to “validate” GUIDs/UUIDs. Half the point of these things is that they’re treated as opaque identifiers.

If UUIDv4 was all that ever existed, there would be no need to validate anything apart of the fact that it's supposed to contain 32 hexadecimal characters. All other versions, including the new v7, attach meaning to certain bits of the identifier. That cat has been out of the bag for a long time, so now everyone needs to maintain code to ensure that some rogue node doesn't spew back-dated identifiers belonging to the…

UUIDv4 attaches meaning to certain 6 or 7 bits (depending on a variant) of the identifier. UUIDv4 is a UUID after all.

Re: Goodbye integers, hello UUIDv7

#85

Post by dajonker »

oconnore wrote: post #55
jonhohle wrote: post #35

This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…

Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits

That's an interesting idea, how would you deal with the bits in the UUID that are used for the version? Setting them to random bits may cause issues for clients that try to use the identifier in their own database or application, as mentioned in the article.

Re: Goodbye integers, hello UUIDv7

#86

Post by BWStearns »

rhaps0dy wrote: post #82
BWStearns wrote: post #78

Earlier quoted context omitted.

I could imagine using the timestamp segment of publicly observable ids to estimate activity patterns in an organization. Probably not super crucial and there are probably easier ways in most cases but it could be a big deal at the right moment and for the right target. This could be like a more refined version of PIZZAINT (where you can detect impending policy/operational movements by the quantity of food deliveries…

Is PIZZAINT real? I thought it was a joke. How do you even find out how much pizza is being delivered?

In ye olden days you had a minion sitting in a car watching the front gate with a notepad and enough cigarettes to last the night.

Pizza itself might be a bit of a joke but looking for non-operational behavioral changes is absolutely real. The Cuban missile crisis was started in part because soviets played soccer and Cubans played baseball and the presence of soccer fields helped confirm soviet presence (in enough numbers to bother making rec centers). A more advanced version might be the public Strava data leaking US base layouts and locations or Strava helping the Ukrainians kill a Russian submarine commander.

Edit to add: you could also just figure out where your target orders pizza from and pay one of the dudes working there to tell you when there’s a spike in deliveries to your target.

Re: Goodbye integers, hello UUIDv7

#87

Post by lysium »

oconnore wrote: post #55
jonhohle wrote: post #35

This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…

Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits

Neat idea.

I’m afraid you won’t be able to ever rotate that key, would you? Since it’s result is externally used as an identifier, you would have to rotate the external identifiers, too.

Re: Goodbye integers, hello UUIDv7

#88

Post by lelanthran »

dataangel wrote: post #53

why bother with any version of the uuid standard? just generate a random 128-bit number and use it. that's all the newer ones are anyway

> why bother with any version of the uuid standard? just generate a random 128-bit number and use it. that's all the newer ones are anyway

Good question.

Won't random 128-bit numbers actually be superior to UUIDs in every way except predictability?

Re: Goodbye integers, hello UUIDv7

#89

Post by mholt »

dataangel wrote: post #53

why bother with any version of the uuid standard? just generate a random 128-bit number and use it. that's all the newer ones are anyway

Sorry to be this guy, but did you read the article? Only UUIDv4 is "just generating a random 128-bit number" (almost) -- and there are valid reasons that's not a good choice. Which the article explains. :) Like database insertion performance. Sequential IDs have benefits.

Re: Goodbye integers, hello UUIDv7

#90

Post by the_arun »

lysium wrote: post #87
oconnore wrote: post #55

Earlier quoted context omitted.

Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits

Neat idea. I’m afraid you won’t be able to ever rotate that key, would you? Since it’s result is externally used as an identifier, you would have to rotate the external identifiers, too.

What is the use case for rotating uuids? Aren’t they immutable?
Post reply on HN