If this is a concern, pass your UUIDv7 ID through an ECB block cipher with a 0 IV. 128 bit UUID, 128 bit AES block. Easy, near zero overhead way to scramble and unscramble IDs as they go in/out of your application.

There is no need to put the privacy preserving ID in a database index when you can calculate the mapping on the fly

▲

10000truths a day ago | parent | next [-]

This is, strictly speaking, an improvement, but not by much. You can't change the cipher key because your downstream users are already relying on the old-key-scrambled IDs, and you lose all the benefits of scrambling as soon as the key is leaked. You could tag your IDs with a "key version" to change the key for newly generated IDs, but then that "key version" itself constitutes an information leak of sorts.

▲

DSingularity a day ago | parent [-]

Why do you need forward secrecy?

	▲	10000truths a day ago \| parent [-]
		I edited that out of my post, as I'm not sure it's the correct term to use, but the problem remains. If the key leaks, then all IDs scrambled with that key can be de-scrambled, and you're back to square one.

▲

blackenedgem a day ago | parent | prev [-]

Then that's just worse and more complicated than storing a 64 bit bigint + 128 UUIDv4. Your salt (AES block) is larger than a bigint. Unless you're talking about a fixed value for the AES (is that a thing) but then that's peppering which is security through obfuscation.

▲

cyberax a day ago | parent [-]

Uhh... What? You just use AES with a fixed key and IV in block mode.

You put in 128 bits, you get out 128 bits. The encryption is strong, so the clients won't be able to infer anything from it, and your backend can still get all the advantages of sequential IDs.

You also can future-proof yourself by reserving a few bits from the UUID for the version number (using cycle-walking).

▲

grapesodaaaaa a day ago | parent [-]

I still feel like calling something like uuid.v4() is easier and less cognitively complex.

▲

cyberax a day ago | parent [-]

There are advantages in monotonically increasing UUIDs, they work better with BTrees and relational databases.

	▲	grapesodaaaaa 14 hours ago \| parent [-]
		I just meant having UUIDv7 internally, and UUIDv4 externally if date leakage is a concern (both on the same object). UUIDv7 still works great in distributed systems and has algorithmic advantages as you have mentioned.