Phobos randomUUID is not suitable to generate secrets
cpicard at purrfect.fr
Thu Sep 3 13:23:39 UTC 2020
On Wednesday, 2 September 2020 at 16:49:30 UTC, Joseph Rushton
> Thanks for highlighting the issue. One query about your
> article -- you state:
>> Phobos' randomUUID() follows these lines perfectly, using
>> non-secure randomness.
> ... but actually, the code example you posted doesn't
> inherently use non-secure randomness: it accepts any uniform
> RNG. It's therefore the user's choice whether or not to
> provide an RNG that is cryptographically secure or not.
Yes, you can provide it manually with a random number generator
that is cryptographically secure. I've never seen that, not even
once. All usage I've seen without exception just calls
randomUUID() which uses the default PRNG which is the one
It is always possible to opt-into security, but security doesn't
work if it's not by default as shown in multiple cases of
projects that had vulnerable code.
> This by itself seems in line with the RFC as you describe it:
>> Note that the RFC does not require the use of cryptographically
>> secure random numbers, but it does warn against using UUIDs for
>> sensitive values if normal randomness is used.
> In other words, the code as written (and as posted in your
> article) gives the user the choice about what their
> requirements are.
Indeed, as I said the code is perfectly in line with the RFC. The
issue is that the RFC predates usage, and isn't in line with said
usage. Nowadays people expect UUIDs to be cryptographically
secure, whether that's a fair assumption to make or not. While I
could see an argument to put the blame on developers, it would
not be a pragmatic one: there will always be new people coming in
and falling into the same pitfall. Avoiding that pitfall entirely
is possible and not too hard, therefore I personnaly recommend
fixing it rather than just shifting the blame onto developers
even though I think there is some truth to that.
Security only works if it is by default.
> There is however an issue about the overload that does not take
> an RNG as input, which defaults to using `rndGen` (the default
> RNG, which on most platforms is indeed the Mersenne Twister).
> So it feels like fixing the issue is not about the
> implementation posted in your article, but about what RNG is
> used by default if the parameterless overload of `randomUUID`
> is called.
> Or have I missed something?
You have not missed anything. Of course randomUUID itself just
takes whatever the RNG provides. The point of the article was
however centered arround randomUUID because while attacking RNGs
directly is fairly common, I had received doubts that this could
be attacked in practice in the context of UUIDs. I wanted to
prove that, yes, even though the attack is harder, it is possible
to attack a bad PRNG in this context.
> A related issue is whether Phobos provides _any_
> cryptographically secure RNG, whether of its own implementation
> or by access to some other API.
Indeed, it is the heart of the issue. I think quite strongly that
Phobos must provide access to the system's CSPRNG.
More information about the Digitalmars-d