Phobos randomUUID is not suitable to generate secrets

[Steven Schveighoffer]

On 9/6/20 4:12 AM, Johannes Pfau wrote:
> Am Sat, 05 Sep 2020 21:17:59 -0400 schrieb Steven Schveighoffer:
> 
>> On 9/5/20 6:41 AM, Johannes Pfau wrote:
>>>
>>> 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.
>>
>> 1. The default should be changed, even if it's not as performant. There
>> is no promise about randomUUID's performance.
>>
>> 2. vibe.d does not depend on this, so there are no worries about
>> blocking a thread.
>>
> 
> 1) This is not about performance. geturandom, /dev/urandom on FreeBSD and
> other cryptographic random number generators can block if they have not
> been seeded with enough entropy yet. There are well-known bugs caused by
> this when programs in early boot use these interfaces, block and
> therefore cause the whole system boot to fail: https://bugs.debian.org/
> cgi-bin/bugreport.cgi?bug=897572
> https://wiki.debian.org/BoottimeEntropyStarvation
> 
> On small embeeded systems with less entropy sources, it may take even
> longer to properly seed the system random number generators.
> 
> Silently changin randomUUID() to use such an interface means some
> programs which do not care about UUIDs being secure might block, which
> could cause catastrophic effects as in the above bug reports. Although
> it's unlikely such low-level tools are written in D, we can not simply
> assume that.
> 
> Because of that, the only valid solution is to remove the default
> overload and let the user make an informed decision.

How is that the only valid solution? Another valid solution is -- change 
the (most likely not-existing) application that absolutely cannot block 
to use a defined PRNG that doesn't block, while benefiting the security 
of every other application that is not hampered by system startup 
entropy starvation.

This isn't even changing something that will break code or create a 
situation where randomUUID will produce a different code path, or 
different outputs that may break something. I see no reason to go 
through this pain for a theoretical problem that likely doesn't exist.

I will note that the most likely result from the changes you are 
proposing is that people go from using randomUUID() to 
rndGen.randomUUID(), and I don't see that being the correct result. 
That's even what your PR recommends!

It should be: "If you don't care about the random number generator that 
is going to generate your UUID, I'm going to use a secure one."

The more I think about this, the more I feel like the solution you have 
arrived at is completely backwards.

-Steve