Phobos randomUUID is not suitable to generate secrets

[Cym13]

On Wednesday, 2 September 2020 at 16:49:30 UTC, Joseph Rushton 
Wakeling wrote:
> 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 
attacked.

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.