gen_random_uuid() produces a v4 UUID.
Taking the first 5 bytes of a v6 UUID (time) and last 5 (node) would be a bad random day.
Wait, is this blog actually about how to introduce a backdoor into your Postgres install by rolling your own very bad rng?
Nah, mhio is saying that the blog post has a typo:
> Postgres 13’s gen_random_uuid() which generates a V6 UUID that’s secure...
gen_random_uuid gives you a version V4 UUID, not a V6 UUID (it's even in the code comments in the snipped included in the blog). I don't believe Postgres even has a function to generate a V6 UUID - which, indeed, would be a bad idea to use as a source of randomness.
No, a v4 uuid comes from a good RNG. The blog post just said v6 by mistake when it meant v4.
Exercise extreme caution.
Having your security strategy rely on quirky behaviors of an implementation detail which might change is incredibly dangerous.
UUID v6 isn’t going to change. There’s a reason we have seven of them now. And v8, which would warrant your warning.
UUIDv6 won't change, but what about gen_random_uuid()
gen_random_uuid isn’t going to change either, the entire point is to generate a secure uuid4. At most it’ll get faster due to using platform-specific syscalls.
If you’re shopping for a CSPRNG, one of the items that should be very high on your list is being able to call the setSeed function multiple times and have the inputs compose instead of clobber each other.
You can send half-random input in and then send more half-random input in until you’re satisfied that the RNG has gotten a suitable amount of entropy. Do not chop, rearrange, hash, or bit shift the data trying to make it “stronger” the CSPRNG will do an infinitely better job of doing that for you. Just treat it like a Mr Fusion. Drop a can, a banana peel and the stale beer in and let it cook.
I gave a similar speech to a team trying to initialize SSL sessions on an embedded machine. “But what if we XOR…” No. Stahp.
Can you give some examples of CSPRNG implementations that allow this?