
Cracking Phobos UUID - tux1968
https://breakpoint.purrfect.fr/article/cracking_phobos_uuid.html
======
chromatin
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/](http://mir-random.libmir.org/)

------
ex3ndr
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.

~~~
treve
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.

~~~
rowanseymour
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.

~~~
teddyh
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](https://news.ycombinator.com/item?id=10330331#10334023))

~~~
derefr
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!

------
tgsovlerkhgsel
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.

------
ed25519FUUU
> _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?

~~~
hcarvalhoalves
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.

~~~
hehebbssjj
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

