Cracking Phobos UUID | Hacker News Reader

Cracking Phobos UUID

breakpoint.purrfect.fr

52 pointstux196814 comments

Fascinating article. I did note that the template function signature includes RNG, which me as I may pass a different PRNG function; those found in the Mir [1] library are excellent. Libsodium is also available in D.

[1] http://mir-random.libmir.org/

I am not sure why UUID is really not that "secure" since the security properties are coming mostly from used PRNG. v4 is mostly just random 16 bytes that is the same as key length for AES-128.

As mentioned in the article, the specific implementation of UUID in this case usually relies on Mersenne Twister 19937 for its PRNG, which isn't cryptographically secure. Given enough samples, the author demonstrates how future UUID's can be predicted.

I'm always a bit suspicious when people use UUID for secrets, because there's no requirement for UUIDs to be unguessable. They just need to be unique.

In a V4 UUID, 122 of the bits are required to be random, which as long as you're using a good RNG, should be unguessable.

Yes, but “should” is the operative word here. I don’t think most UUID libraries use good randomness, and the UUID RFC standard actively argues against using UUIDs as anything which has to be kept secret.

(I actually wrote this about UUIDs here on HN five years ago: https://news.ycombinator.com/item?id=10330331#10334023)

It's my impression that most of the people who use UUIDv4s for their unguessability, aren't actually using UUIDv4s at all (i.e. aren't using a distinct UUID library or runtime UUID datatype), but rather are pulling 16 bytes from a CSPRNG, and then formatting it manually into a UUIDv4 serialization format and calling it done.

Sometimes, but not often, the developer will remember that UUIDs have a structure, and so will mask out the relevant bits from the CSPRNG output to replace them with the right static tag-bits to define the serialized identifier as a UUIDv4.

But usually, developers aren't expecting the other end of any conversation to actually try to understand the UUID, but merely to hold onto it as an opaque 128-bit-packed or hex-string-encoded binary. Which is a valid expectation in practice! Even DBMSes with a UUID type don't actually validate the tag bits on the UUIDs inserted into such a column. There's no DBMS I know of that has a means to impose a constraint on which version of UUID a UUID-typed column should hold, or a constraint on the domain for a UUIDv1, or any of that.

A UUID might be an ADT with four distinct generation algorithms—but after generation, in practice, they become just opaque uint128 values, that nobody ever unwraps or parses or expects to mean anything, ever again.

Which means that, in practice, there's nothing stopping people from just taking 128 bits of CSPRNG randomness, and calling that a "UUID." And so that's mostly what they do!

> I don’t think most UUID libraries use good randomness, and the UUID RFC standard actively argues against using UUIDs as anything which has to be kept secret.

Windows core system libraries, and by extension .NET, SQL Server, etc. have used the system CSPRNG for type 4 UUID generation since at least as far back as Y2K.

If you don’t use a CSPRNG for type 4 UUIDs you get collisions from the small seed size of insecure PRNGs, which are traditionally seeded from the system clock. The number of UUIDs required to observe collisions was surprisingly low thanks to the birthday paradox.

These collisions were common enough back in SQL Server v7 that, as I recall, they changed the UUID generation mechanism NEWID() to use a CSPRNG in a service pack.

There is no guarantee that v4 UUIDs are generated by a secure CSPRNG. Some implementations have such a guarantee (notably Java), but most don't document this.

A common case that may be hit by this could be document IDs in combination with "link sharing" where knowledge of the document ID gives you access to the document.

> Contrary to other languages, D's current standard implementation of UUID4 isn't cryptographically secure

It's hard to imagine a language designer choosing not to make such an import part of the standard library cryptographically secure. Is there a story behind this?

Relying on a client not being able to guess the next UUID is an attempt of security through obscurity, no? I don't think it's part of the requirement.

Relying on a client not being able to guess a random number is also important for Diffe-Hellman and like, all private key generation AFAIK. I don't think anything says private keys are security by obscurity because they require you to locally generate random numbers

UUIDs aren't supposed to be secure. They're aren't supposed to be unguessable. They're just supposed to be very unlikely to be duplicated. They have one use case: as universally unique identifiers. That's it. Any expectation or off-label use that goes beyond that is misuse. In other news, most hammers are found to be unsafe to use as toothpicks.

Reply on news.ycombinator.com