Phobos randomUUID is not suitable to generate secrets
cpicard at purrfect.fr
Mon Sep 7 07:16:17 UTC 2020
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/
> On small embeeded systems with less entropy sources, it may
> take even longer to properly seed the system random number
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
> 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.
More information about the Digitalmars-d