3 ms·
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)ran
by dfox 7y 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.
- marios 7y agoAlright, 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.
- cyphar 7y agoThe 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/random.c#L2343 https://elixir.bootlin.com/linux/v5.3.6/source/drivers/char/...