5 ms·

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

by ex3ndr 6y ago

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.

tux1968 6y ago
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.
treve 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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!
    - tatersolid 6y ago
      > 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.
CodesInChaos 6y ago
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.
deleted 6y ago
[deleted]

by ex3ndr 6y ago

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.

tux1968 6y ago

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.

treve 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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!
  - tatersolid 6y ago
    > 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.

CodesInChaos 6y ago

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.

deleted 6y ago

[deleted]