UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash-masked timestamp)

Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by JimDabell on Wednesday September 17, 2025 @01:45PM (#45279010)

There’s a whole bunch of use-cases where the ability for a user to mess with the timestamp is not a problem. Who cares if a user screws up the ordering of items in a collection only they see? But if you can attack the private key by generating many different ciphertexts for the same rand, that might let you defeat the purpose of this masking.

[ Parent | on HN ]

Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by move-on-by on Thursday September 18, 2025 @09:38AM (#45289553)

I concede my above comment was speaking in generalities and has plenty of exceptions. However, I do prefer to fallback on safe defaults, and letting the client choose the UUIDv7 could certainly have some unsafe consequences.

[ Parent | on HN ]

Re:UUIDv47: Store UUIDv7 in DB, emit UUIDv4 outside (SipHash... by lazide on Friday September 19, 2025 @05:56AM (#45299828)

What if a broken client implementation uses the same client ‘generated’ UUID (or very similar) for all client requests?

[ Parent | on HN ]