Hacker News new | ask | show | jobs
by dfox 2421 days ago
From cursory look at the code wireguard relies on Linux's get_random_whatever() internal APIs, which are kernel-space interface to same PRNG as userspace (u)random/get_random()/get_entropy(). It even seems that there is not a single line of x86_64 assembly in the whole WireGuard.

On the other hand it is somewhat worrisome that brokenness of RDRAND can affect output of Linux's RNG that much.
2 comments
cyphar 2421 days ago
The problem is that the "right kernel API" (get_random_u32) will return whatever the hardware-provided RNG returns if it's available[1].

There is assembly in WireGuard for the crypto primitive implementations, but those are generated by scripts and are based on either formally-proven implementations or highly-vetted ones.

[1]: https://elixir.bootlin.com/linux/v5.3.6/source/drivers/char/...

link
marios 2421 days ago
Alright, so that would mean that it's not WireGuard that's broken because it's trying to be more picky about the RNG, but rather the Linux CSPRNG that's broken when RDRAND is misbehaving. As you said, worrisome.
link