5 ms·

The problem highlighted here is not so much UUIDs, but instead the use of poor PRNGs (i.e. things other than /dev/urandom or getrandom(2) on Linux). All of the

The problem highlighted here is not so much UUIDs, but instead the use of poor PRNGs (i.e. things other than /dev/urandom or getrandom(2) on Linux). All of the issues with the example libraries are around of the use of PRNGs from math libs, not crypto libs. A "secure token generation" library might have the same flaws (and many do!). A correctly generated v4 UUID (S4.4 of the RFC) should be acceptable for use as a secure token, given it has 122 random bits. The trouble with UUIDs, if any, is that only v4 UUIDs are really suitable for use as secure tokens, with v1 through v3 being entirely unsuitable. Personally, outside of DB PKs in Postgres (or similar), I prefer to base64 encode 256-bits from /dev/urandom for tokens, as they're a little shorter (and Go makes it easy enough to do that).

netheril96 11y ago
Boost.UUID suffers from the same problem, at least at the time I checked.
xnyhps 11y ago
> A correctly generated v4 UUID (S4.4 of the RFC) should be acceptable for use as a secure token, given it has 122 random bits. No it's not, from §4.4: > Set all the other bits to randomly (or pseudo-randomly) chosen values. I can use a PRNG with a cycle length of 8 and it would be fully correct according to the RFC, but it would be trivial to brute-force all the values.
- viraptor 11y ago
  Kind of... you're technically right and and practically not. Nobody would describe a PRNG with cycle length of 8 as random. It's just reading numbers off of a list. In the same section of uuid RFC: "See Section 4.5 for a discussion on random numbers.", and then: "Advice on generating cryptographic-quality random numbers can be found in RFC1750 [5].", so it's not like authors were unaware of the implications of trivial PRNG. It's just up to the implementation whether CSPRNG is required (user-visible security tokens), or just a PRNG (internal identifiers).
- Natanael_L 11y ago
  Correctly generated implies not having such a computationally weak correlation
  - xnyhps 11y ago
    Obviously I'm interpreting "correctly generated" to mean "generated in accordance with the RFC", so no, it does not.
    - derefr 11y ago
      "Correctly generated" also means, at the very least, "useful to the people implementing it." If you can't use a given UUID implementation without generating collisions in the first 100 items, you won't use that UUID implementation. There's an "implicit spec" behind each spec of what people will or won't actually bother to do. Generating correlated v4 UUIDs isn't wrong, but it is stupid in the sense of being self-defeating: nobody who wants to generate v4 UUIDs wants them with insufficient randomness, and will have no reason to not consider a bad random-number source to be a bug, because it's interfering with getting them the thing they want to get by generating v4 UUIDs in the first place. (The real point of the explicit UUID spec, meanwhile, is in saying what constitutes a valid UUID—and it's certainly valid to generate a UUIDv4 using insufficient entropy. There's no way for a peer receiving such UUIDs to guess that they're maybe-predictable-with-enough-effort and reject them on that basis, which is all "validity" can ever mean: what can or cannot be technically enforced by protocol peers.)
johnhenry 11y ago
I agree. From the title, I would have thought that there was something about the format, and not the generation method, that made it insecure.
deleted 11y ago
[deleted]
- dragontamer 11y ago
  I'm not sure what the SHA512 buys you. If the source was crypto-random from the start, the only thing a Hash gets you is the potential for a birthday attack. Fortunately the birthday attack (assuming SHA512 is secure) is at 256 bits. So I don't believe you've lost security in this case... but it would seem that you've almost certainly lost performance.
FabChickenFeet 11y ago
> A correctly generated v4 UUID (S4.4 of the RFC) should be acceptable for use as a secure token, given it has 122 random bits. No, you're missing the point. Security requires more than randomness, it also requires unpredictability. The RFC Section 6 is very clear about this: "Do not assume that UUIDs are hard to guess; they should not be used as security capabilities". I don't know how many UUID generators have cryptographic properties, but it is wrong to assume that it it suitable for security just because the randomness appears good. You can speak to any cryptographer about that.

netheril96 11y ago

Boost.UUID suffers from the same problem, at least at the time I checked.

xnyhps 11y ago

> A correctly generated v4 UUID (S4.4 of the RFC) should be acceptable for use as a secure token, given it has 122 random bits. No it's not, from §4.4: > Set all the other bits to randomly (or pseudo-randomly) chosen values. I can use a PRNG with a cycle length of 8 and it would be fully correct according to the RFC, but it would be trivial to brute-force all the values.

viraptor 11y ago
Kind of... you're technically right and and practically not. Nobody would describe a PRNG with cycle length of 8 as random. It's just reading numbers off of a list. In the same section of uuid RFC: "See Section 4.5 for a discussion on random numbers.", and then: "Advice on generating cryptographic-quality random numbers can be found in RFC1750 [5].", so it's not like authors were unaware of the implications of trivial PRNG. It's just up to the implementation whether CSPRNG is required (user-visible security tokens), or just a PRNG (internal identifiers).
Natanael_L 11y ago
Correctly generated implies not having such a computationally weak correlation
- xnyhps 11y ago
  Obviously I'm interpreting "correctly generated" to mean "generated in accordance with the RFC", so no, it does not.
  - derefr 11y ago
    "Correctly generated" also means, at the very least, "useful to the people implementing it." If you can't use a given UUID implementation without generating collisions in the first 100 items, you won't use that UUID implementation. There's an "implicit spec" behind each spec of what people will or won't actually bother to do. Generating correlated v4 UUIDs isn't wrong, but it is stupid in the sense of being self-defeating: nobody who wants to generate v4 UUIDs wants them with insufficient randomness, and will have no reason to not consider a bad random-number source to be a bug, because it's interfering with getting them the thing they want to get by generating v4 UUIDs in the first place. (The real point of the explicit UUID spec, meanwhile, is in saying what constitutes a valid UUID—and it's certainly valid to generate a UUIDv4 using insufficient entropy. There's no way for a peer receiving such UUIDs to guess that they're maybe-predictable-with-enough-effort and reject them on that basis, which is all "validity" can ever mean: what can or cannot be technically enforced by protocol peers.)

johnhenry 11y ago

I agree. From the title, I would have thought that there was something about the format, and not the generation method, that made it insecure.

deleted 11y ago

[deleted]

dragontamer 11y ago
I'm not sure what the SHA512 buys you. If the source was crypto-random from the start, the only thing a Hash gets you is the potential for a birthday attack. Fortunately the birthday attack (assuming SHA512 is secure) is at 256 bits. So I don't believe you've lost security in this case... but it would seem that you've almost certainly lost performance.

FabChickenFeet 11y ago

> A correctly generated v4 UUID (S4.4 of the RFC) should be acceptable for use as a secure token, given it has 122 random bits. No, you're missing the point. Security requires more than randomness, it also requires unpredictability. The RFC Section 6 is very clear about this: "Do not assume that UUIDs are hard to guess; they should not be used as security capabilities". I don't know how many UUID generators have cryptographic properties, but it is wrong to assume that it it suitable for security just because the randomness appears good. You can speak to any cryptographer about that.