5 ms·

> 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

by 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.)

by xnyhps 11y ago

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