I put SLIDE parameter there so it is possible to slide different offsets if needed, Including standard 16 bytes. It loses some speed but still very fast.
I don’t think that the generator can be called cryptographically secure while it allows a user to reuse bytes from previous UUIDs.
Random::Secure stream doesn’t looks like a good idea too, as it makes it vulnerable to side-channel attacks.
I agree. In case if you need to use UUID for something unique and totally random then it is better to use standard UUID that uses Secure::Random. If you need some unique UUID only then my approach works too.
According to the spec (section 6) there’s no reason for it to actually be secure. It was only meant as a randomized, unique string.
It’s up to you if it’s meant to be secure – but of course that’s only as good as your RNG.
If you wanted to be secure with this implementation, you can bump the “slide” back up to
16, yielding a fresh slice every call.
I think for the JS version I will go back to 16-byte jumps and then also offer the 1-byte slide as an opt-in “insecure” variant.
Unfortunately UUID’s have been used as “security capabilities” out in the wild, hence the stdlib making them all secure by default.
Couple related links:
However for benchmarking purposes it might be nice to have faster options available, nice, thank you!
I have wondered if there’s a way to make faster cryptographically secure random’s in OS X but haven’t figured out one yet… [different algorithm seeded by urandom?]. Also crystal will get rid of fork “some day” so hopefully it’ll be at least simpler to understand at that point (or maybe they’ll keep it forever, it has some nice properties, who knows…)
You can pass in a different random number generator.
Also I thought at one point someone mentioned that UUIDs where suppose to be cryptographicly secure by the spec but after some quick searching I cannot find the comment or the documentation in the spec. Could we use a faster source of randomness that is pseudo random to increase performance?