I gave away $1,000 to prove UUIDs are secure

A public argument about whether UUIDs can be “brute forced” spiraled into a $1,000 cryptography challenge—and the outcome was a blunt demonstration that UUID v4’s randomness is not realistically guessable in practice when implemented correctly. The dispute began with a design question: if access to data is gated by a public URL containing a “super unique” UUID, does that make the data effectively private, or merely public because anyone can copy the URL? One commenter—Charlie—insisted UUIDs could be brute-forced by trying “all variations,” claiming the search space was far smaller than UUID v4’s real size.

UUID v4 is built to be “universally unique,” with an astronomically large space: about 2^128 possibilities (often cited as ~5.3 × 10^36). The odds of collisions in properly random generation are so low they’re compared to extremely unlikely physical events. The core technical point in the thread is that UUIDs only become guessable if randomness is badly implemented—such as using non-cryptographic randomness or reusing predictable state. The challenge’s back-and-forth hinged on Charlie’s numbers and assumptions. He floated a smaller exponent (2^32) and suggested a brute-force could succeed within hours under optimistic request rates. Theo pushed back that the math didn’t match UUID v4 at all, and that the “attack” Charlie referenced relied on outdated, narrow, and largely mitigated conditions—like specific historical Java randomness behavior—plus browser fixes years ago.

To settle the claim with something testable, Theo created a local decryption challenge. He generated two UUIDs in Node using crypto-random functions, encrypted a file using AES-256 (with a noted mistake: the chosen method could sometimes decrypt into garbage without the correct key), and offered $1,000 to anyone who could “crack this UUID”—meaning identify the exact UUID that produced the meaningful plaintext, not merely trigger a successful-looking decryption. The file was downloadable, and the intended workflow required no network requests: download, then decrypt locally. Charlie declined, arguing the prize wasn’t worth the server costs and raising questions about “proxy detection,” which Theo said were irrelevant because the attack didn’t require hitting an endpoint.

The thread then escalated into a public, interactive “every UUID” site built by developer Nolan. The site lets users scroll through UUIDs and attempts to decrypt the payload for each candidate, effectively turning the brute-force claim into a visible, hands-on experiment. Even with this tooling, no one found the correct UUID. Decryptions with wrong UUIDs produced nonsense or misleading partial results, and Theo added a hint (the first two letters are “th” and the plaintext is a valid English sentence) to filter out obvious garbage. After the challenge window, Theo revealed the plaintext: “There’s a literal 0% chance you are able to get into this file.”

The final takeaway is less about UUIDs being “secure forever” and more about engineering reality: UUID v4’s security depends on using proper cryptographic randomness and not confusing “possible in theory under broken randomness” with “feasible in real systems.” The chaos ended with Theo framing the whole episode as a cautionary tale about misunderstanding randomness, uniqueness, and what brute forcing actually costs in the real world.