Ask HN: We just had an actual UUID v4 collision... • Hacker News Board

Re: Ask HN: We just had an actual UUID v4 collision...

#201

Post by jandrewrogers » Fri, May 08, 2026, 7:58 PM UTC

erikerikson wrote: post #194

jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

Super simple to detect and try again.

A collision is simple to detect but it requires you to actually check, which is expensive at scale. The entire point of UUIDv4 is that you don't have to check for collisions because it should never happen. But if you don't check and it does happen you are in UB territory which is generally very bad.

A risk of collision before it happens is non-trivial to detect but this is really what you'd want.

Re: Ask HN: We just had an actual UUID v4 collision...

#202

Post by Groxx » Fri, May 08, 2026, 7:59 PM UTC

jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

Yep - I've seen legitimate-looking dups on bad hardware, and "there are a ton of trailing zeros" is also an incredibly common duplicate mode for some UUID libraries (like earlier Go ones that didn't validate the "requested N bytes, returned 3, you must re-request to get N-3 more" return values. it doesn't happen on most hardware or OSes, so people never check it, so it just comes up in production some day with tens of thousands of collisions).

Re: Ask HN: We just had an actual UUID v4 collision...

#203

Post by FuriouslyAdrift » Fri, May 08, 2026, 8:04 PM UTC

euroderf wrote: post #177

victorbjorklund wrote: post #166

Earlier quoted context omitted.

If I understand it the Lava lamps are 90% PR/fun. They have a lot of other sources for entropy that scales better.

Ant farm ? Hamster wheels ? Anything critter-driven should provide some entropy.

https://www.idquantique.com/random-number-generation/product...

Re: Ask HN: We just had an actual UUID v4 collision...

#204

Post by Hizonner » Fri, May 08, 2026, 8:04 PM UTC

jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

> UUIDv4 is explicitly forbidden for a lot of high-assurance and high-reliability software systems for this reason.

Hmm. What do those systems do for cryptography? Just assume it won't work and not rely on it at all?

Re: Ask HN: We just had an actual UUID v4 collision...

#205

Post by smokel » Fri, May 08, 2026, 8:05 PM UTC

Multiple times have I blamed compilers, cosmic rays, quantum effects, or at the very least an obscure kernel bug, before realizing that I was the source of a bug.

A collision at 15,000 records is so unlikely that I would first suspect something else. Duplicate processing, replayed requests, reused objects, misleading logs, or another code path reusing the identifier.

Could you share a bit more of the surrounding code so we can check?

Re: Ask HN: We just had an actual UUID v4 collision...

#206

Post by otherme123 » Fri, May 08, 2026, 8:09 PM UTC

matt-p wrote: post #175

thecloud wrote: post #113

Earlier quoted context omitted.

Thanks for the insight! Mind expanding on what alternatives are being used in high reliability systems instead of UUIDv4?

UUIDv7 is arguably better, because it is entropy plus time.

It is what I usually use for its sorting, but some people don't want to leak time info.

Re: Ask HN: We just had an actual UUID v4 collision...

#207

Post by __s » Fri, May 08, 2026, 8:14 PM UTC

LocalH wrote: post #141

jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

This is why CloudFlare has done what they did with the lava lamp wall. Not that the wall is such a great source of entropy on its own - I'm sure it's not their only source, but you can never have too many sources of entropy - but it makes it visible in a way that can grab those who don't fully understand the concepts of RNGs and how entropy plays into that. The more sources of entropy, the more closely you approach "…

Old games are RTA viable to RNG manip: https://m.youtube.com/watch?v=Bgh30BiWG58

Re: Ask HN: We just had an actual UUID v4 collision...

#208

Post by LocalH » Fri, May 08, 2026, 8:18 PM UTC

unilynx wrote: post #184

BSVogler wrote: post #181

Earlier quoted context omitted.

I once read that noise of camera in total darkness is apparently a good source.

The noise probably makes the lava lamp wall just as effective as pointing the camera at the Mona Lisa - the lamps themselves are not that unpredictable frame-to-frame.

For the record, the lamps and camera are present in their lobby afaik, so you can actually go there, stand in front of them, and slightly affect the entropy.

A cool parlor trick, certainly.

Re: Ask HN: We just had an actual UUID v4 collision...

#209

Post by jandrewrogers » Fri, May 08, 2026, 8:18 PM UTC

Hizonner wrote: post #204

jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

> UUIDv4 is explicitly forbidden for a lot of high-assurance and high-reliability software systems for this reason. Hmm. What do those systems do for cryptography? Just assume it won't work and not rely on it at all?

In these kinds of systems the cryptographic components often aren't even accessible from the software. It isn't a thing you need to worry about.

This makes it easier to audit for use of entropy sources in the software since there really isn't a valid use case for it.

Re: Ask HN: We just had an actual UUID v4 collision...

#210

Post by kdps » Fri, May 08, 2026, 8:23 PM UTC

dgellow wrote: post #48

AndreyK1984 wrote: post #42

Why not to have timestamp-uuid instead ?

How confident are you that your machines clocks are in perfect sync? What about the risk of clock drift + correction, or hardware issues?

I get why sync of mutiple machines matters for ordering and causality, but why is it a problem for uniqueness?