Phobos randomUUID is not suitable to generate secrets
nospam at example.com
Sat Sep 5 10:41:34 UTC 2020
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
> 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
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/
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).
More information about the Digitalmars-d