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