Add script: UUIDv4 #175
Add script: UUIDv4 #175
Conversation
Version 4 of UUID is nice and easy because every bit is random (except the version identifier). No need to worry about MAC addresses or chosen namespace identifiers. Fixes #77
|
Kudos, SonarCloud Quality Gate passed!
|
The security hotspot is use of Anyways, I don't think it's a very big deal because people will be generating very few UUIDs inside Boop, compared to a web application that might be used by many people at once. |
|
That's kind of the problem, we cannot guarantee that those UUIDs will be unique enough to be safe for use. Similar to #88, there is a question of whether this feature actually improves security or makes it worse. Crypto not being available makes me a bit worried about those scripts and the potential uses, since they should not be trusted. Your suggestion about it being less likely to collision since it is not running at the same time is a very good point, I just want to make sure that the results are not constrained to only a subset of available UUIDs, being deteministic is not necessarily an issue. I would also suggest we try tweaking the algorithm a bit (maybe by shifting the random number before consuming it?) so that we reduce the likelihood of collision with software that uses that same snippet (considering it's the top result there is probably a huge amount of places that use it as-is). |
|
I think this PR isn't very scary. I will try to convince you.
I think UUIDs and PGP keys have dissimilar threat models. PGP keys are used for cipher operations and generation of cryptographic signatures; UUIDs are not. PGP private keys are commonly reused, and the period of reuse may span years. Discovering a PGP private key causes a breakdown in confidentiality for a (potentially large) collection of messages. UUIDs are typically generated once to identify an object, and do not apply to multiple objects (messages) like PGP keys do.
For what it's worth, I ran 1 million iterations of this script and every result was unique. Of course, that only tests a tiny fraction of 1% of the huge UUID space, so experiments like this aren't a good way of proving that a given PRNG has the desired characteristics. It is worth pointing out, however, that the PRNG in WebKit which underlies JavascriptCore is originally seeded with a cryptographically secure random number. Between 2009 and 2015, WebKit used a relatively weak PRNG called GameRand. (How bad was GameRand? Pretty bad.) But in 2015, WebKit upgraded to Xorshift+ which is really quite good.
Tweaking the PRNG output like this would probably offer no benefit (remember, it's already seeded with a cryptographically secure RNG), and could potentially cause some entropy bits to be discarded, weakening the resulting UUID. |
|
I also created a script for this, but closed the PR as I noticed this was already made and I had the same issue as there isn't an easy way to do secure random. I clearly stated in my script that it wasn't secure for crypto related functions. But my use case for uuids is to generate things like "flags" for challenges, or just random ID's for small scenarios... Depending on the cases that's good enough and better then not having it, in my opinion :) |
Version 4 of UUID is nice and easy because every bit is random (except the version identifier). No need to worry about MAC addresses or chosen namespace identifiers.
Fixes #77