Phobos randomUUID is not suitable to generate secrets

[Johannes Pfau]

Am Thu, 03 Sep 2020 13:31:01 +0000 schrieb Cym13:

> On Thursday, 3 September 2020 at 13:23:39 UTC, Cym13 wrote:
>> On Wednesday, 2 September 2020 at 16:49:30 UTC, Joseph Rushton Wakeling
>> wrote:
>>> ...
> 
> I feel that answer was confused, let me reformulate.
> 
> You are correct when you say that randomUUID() alone just takes whatever
> the RNG provides and isn't broken by itself. Should you provide
> cryptographically secure randomness it would be OK to use. However I
> have never seen randomUUID() used with a PRNG other than the default one
> (and I searched), which is what I attacked in that article. The reason
> why I focus on UUID generation and not just breaking the default PRNG on
> its own is twofold: first I saw much more bad usage of randomUUID() than
> of uniform() itself, and second some people had expressed doubts that it
> was exploitable at all in this context. My main goal with this article
> is not to change randomUUID itself (as you pointed out, it does not
> present any bug), but to change the default PRNG used for randomUUID()
> to be a cryptographically secure one because this is the only way to
> prevent more people to fall into the same trap of expecting it to be
> secure.

As the "original author" of that module I can probably add some 
background information on this issue:

The UUID module is mostly a 1:1 port from boost.uuid. I don't remember 
exactly which boost version was used and whether it included a function 
which used the library default random number generator. Current docs in 
boost however also use mt19937 without explicitly warning the user this 
is not cryptographically secure: https://www.boost.org/doc/libs/1_62_0/
libs/uuid/uuid.html#boost/uuid/random_generator.hpp

So this is where the problem originally came from, although it might have 
been my mistake to provide a default overload using the system RNG.


Unfortunately, we can not silently replace this overload to use a secure 
RNG: On linux, would we use random or urandom? And the system rng can 
block on low entropy, which could cause regressions in some applications. 
Also some applications (like vibe.d) would probably rather block a fiber 
than a thread, which complicates things more.


I propose the following:
1) Deprecate the version using the system RNG. Add a hint in the message 
that this function is not cryptographicallly secure. Add a reference to 
documentation how to update code.
2) Update documentation examples to show how to provide the phobos 
default RNG. State that this is not cryptographically secure.
3) Optionally: Implement a Secure, System based RNG. 

I'll open a pull request for steps 1-2 today, so that the immediate 
problem is solved. I'll also have a look how difficult it is to do 3).


-- 
Johannes