128-bit version for uuidv7

[saolof]

Postgres 18 was supposed to have direct support for uuidv7, and even if it does not gain it uuidv7 is somewhat common as application generated uuids. The downside of uuidv7 vs uuidv4 is predictable generation, Feistel cyphers remove that problem. It'd be nice to have a way to obfuscate a uuidv7 into a uuidv4

[dverite]

Postgres 18 (currently in beta) does have a built-in uuidv7 function
(for earlier versions, I suggest this version in pure SQL: https://github.com/dverite/postgres-uuidv7-sql)

The structure of UUIDv7 being as follows (from https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           unix_ts_ms                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          unix_ts_ms           |  ver  |       rand_a          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                        rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rand_b                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in order to obfuscate the timestamp (which can be extended into rand_a for 60 bits of precision instead of 48), a simple solution would be to encrypt the first 64 bits of the UUIDv7 with a Feistel cypher like XTEA. There is a plpgsql implementation at https://github.com/dverite/pg-uniqrand/blob/master/xtea.sql.
It might be an issue that it would overwrite the ver field with 4 random bits as well, rather than having a value of 4 to signal that's it's now an UUIDv4. For most use cases of UUIDs, I think this would not matter. Whenever it matters, permuteseq as it is now could be used to encrypt only 60 bits instead of 64.
The other 64 bits (var and rand_b) can be left as they are in my view, since rand_b is already random and var should be left to 0b10

In summary: the parts to obfuscate the timestamp in UUIDv7 are there , it's a matter of putting them together.
But I see it being done in the UUIDv7 extension than in permuteseq, since permuteseq is functionally unrelated to UUIDs.