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

181–190 of 376 posts

Re: Goodbye integers, hello UUIDv7

#181

Post by pdpi »

dragontamer wrote: post #139
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

Why not just use the AES-128 result as the UUID then? What's the benefit of the internal structure at all? If AES-128 is an acceptable external UUID (and likely an acceptable internal one), then you might as well just stick with a faster RNG.

> What's the benefit of the internal structure at all?

Purely random identifiers are the bane of DB indices. The internal structure is sequential-ish and therefore indexes well.

Re: Goodbye integers, hello UUIDv7

#182

Post by sapling-ginger »

larschdk wrote: post #134
sapling-ginger wrote: post #118

Earlier quoted context omitted.

Base8192: https://alicecengal.github.io/uuid-hangul/

Not very useful. Always decodes to 00NaN-0NaN-0NaN-0NaN-000000NaN.

The decode input needs to be exactly ten hangul character, and must be the first 8192 hangul characters in the unicode set. Obviously I didn't put too much effort into making this robust, it was just a fun toy project.

Re: Goodbye integers, hello UUIDv7

#183

Post by Nevermark »

noduerme wrote: post #92
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…

Thinking that harder-to-guess IDs will mitigate attacks is an example of security by obscurity. It's better to think of any IDs in your database as being public knowledge, because they will leak anyway. Assuming that no one can guess another ID leads to shoddy practices. I generally keep IDs sequential and build security around the basic assumption that IDs are not keys, passwords, sessions, or secrets - they're just…

Security by obscurity is a necessary step in most software security.

It hardens, completes and complements other measures.

Examples of every day security using obscurity: every password and encryption key

EDIT: Thanks for the replies.

Ignore above!

Obscurity is the low bit of security. But when it’s convenient, it still helps.

Re: Goodbye integers, hello UUIDv7

#185

Post by LAC-Tech »

oittaa wrote: post #120
LAC-Tech wrote: post #47

Why use UUIDv7 over ULIDs? As Lazare points out in this thread they're basically the same thing, except with ULIDs you get those 6 extra bits of randomness back that UUIDs have to use for metadata.

https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc... ULID isn't an "official" standard like UUID. Having a real standard usually promotes interoperability and makes it easier to use. Additionally as others have pointed out you can already use UUIDv7 with some databases since it's just 16 opaque bytes and the database doesn't care what's actually in the UUID field.

How much of a standard do ULIDS need? 6 byte timestamp, 10 bytes crypto randomness, stringify it using crockfords base 62 - and off we go.

Re: Goodbye integers, hello UUIDv7

#186

Post by PhilipRoman »

Nevermark wrote: post #183
noduerme wrote: post #92

Earlier quoted context omitted.

Thinking that harder-to-guess IDs will mitigate attacks is an example of security by obscurity. It's better to think of any IDs in your database as being public knowledge, because they will leak anyway. Assuming that no one can guess another ID leads to shoddy practices. I generally keep IDs sequential and build security around the basic assumption that IDs are not keys, passwords, sessions, or secrets - they're just…

Security by obscurity is a necessary step in most software security. It hardens, completes and complements other measures. Examples of every day security using obscurity: every password and encryption key EDIT: Thanks for the replies. Ignore above! Obscurity is the low bit of security. But when it’s convenient, it still helps.

passwords and encryption keys are secrets, not obscurity.

Security by obscurity would be hiding your house key under a doormat for your friend to find - depending on the culture you live in you may be more or less safe but it is not security (just like hosting your ssh server on port 9384 will repel 99% of attackers but is not a security measure).

Re: Goodbye integers, hello UUIDv7

#187

Post by earnesti »

Nevermark wrote: post #183
noduerme wrote: post #92

Earlier quoted context omitted.

Thinking that harder-to-guess IDs will mitigate attacks is an example of security by obscurity. It's better to think of any IDs in your database as being public knowledge, because they will leak anyway. Assuming that no one can guess another ID leads to shoddy practices. I generally keep IDs sequential and build security around the basic assumption that IDs are not keys, passwords, sessions, or secrets - they're just…

Security by obscurity is a necessary step in most software security. It hardens, completes and complements other measures. Examples of every day security using obscurity: every password and encryption key EDIT: Thanks for the replies. Ignore above! Obscurity is the low bit of security. But when it’s convenient, it still helps.

Obscurity and secrecy are different things. Though I agree with you. Moderate amount of well implemented obscurity is helpful.

Re: Goodbye integers, hello UUIDv7

#188

Post by isbvhodnvemrwvn »

fodkodrasz wrote: post #113
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

No IV, ECB mode... why bother with encryption at all? Just expose the internal id.

You are encrypting a single block of unique information. No other encryption mode gives you any advantages whatsoever.

Re: Goodbye integers, hello UUIDv7

#189

Post by Nevermark »

danwee wrote: post #159
dgb23 wrote: post #157

Earlier quoted context omitted.

The maximum url length is typically quite long. Another thing is that you don’t necessarily need to encode uuids canonically. They are just u128’s. It’s relatively straightforward to find a url friendly string representation that is shorter.

> It’s relatively straightforward to find a url friendly string representation that is shorter. Are we talking about shortening the whole URL or shortening specific UUIDs? If the latter then I imagine one would still need to keep track of the mapping UUID shorten version, somewhere, right? If so, why not just add yet another field/column for an old good numeric integer that can be used for filtering? Would that work?

I think the point is for URLs you can consistently represent the 128 bits of UUIDs with shorter strings by using a higher base. I.e. more characters.

So a nonstandard but isomorphic shorter string representation.

Re: Goodbye integers, hello UUIDv7

#190

Post by aurbano »

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.

Assuming you have a table where the identifiers are stored you'd have the internal one (UUIDv7) and the encrypted version from it (external id).

You could rotate encryption keys whenever you want for new external id calculation, so that older external ids won't change (as they are external, they need to stay immutable).

Post reply on HN