Phobos randomUUID is not suitable to generate secrets

[Cym13]

On Sunday, 6 September 2020 at 08:12:56 UTC, Johannes Pfau wrote:
> 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.

Booting on real systems is rarely an issue besides the very first 
boot because the system seeds itself from a random blob that it 
regularily saves on disk. But yes, on some systems and especially 
embedded ones it can be an issue.

Phobos can't reasonnably expect to manage all cases perfectly by 
default. There's no solution that fits all. But there's a 
solution that fits 99% of cases, and that's what should be 
implemented. This does not present any change for people in the 
minority case that already had to implement something specific 
before.

> 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.

Informed decision by itself doesn't work in security. What works 
is providing sane defaults that cover the 99% case (which is what 
defaults are for) and leaving open the possibility to use 
something else. I see no reasonnable reason to take something 
that isn't safe and replacing it by something that works just as 
well and is safer.

An important note here: I'm not even advocating to advertise that 
UUID are secure (I would prefer a dedicated, separate function to 
generate secure tokens of more than 122 bits), but we need to 
make sure defaults are sane. There's nothing to be lost in this 
case: it's replacing an "always unsecure" by "secure in all cases 
except that very specific one".

Most people are not able to make an informed decision when it 
comes to security. It's a bit like informed consent in the 
medical field: sure you can give your opinion but it doesn't 
change the fact that you would need years of training to actually 
understand the consequences of what you're choosing. I'm not 
saying not to explain the situation, but it should never be a 
justification for not providing safe defaults. The lack of safe 
defaults is the reason why this whole thing became an issue in 
the first place.

Leave corner cases where they are: corner cases. They should not 
impact the default.