Re: use of RDRAND in $random_library
Joey Hess wrote:
> I stumbled over a library which has switched to using RDRAND in a new
> upsteam version (not yet packaged), instead of /dev/urandom[1].
>
> I don't have a stong opinion on the security of RDRAND, which is a
> contentious topic in a domain I am not expert in. However, I would much
> rather rely on linux developers to make the right decision on that,
> rather than libraries deciding on an ad-hoc basis. Especially because
> the kernel has a wider spectrum of choices than use/avoid (IIRC it
> currently mixes in RDRAND with other entropy sources.)
>
> Perhaps we should avoid libraries in Debian using RDRAND directly,
> if the library has uses related to security. (Maybe some game or
> simulation library would have a good reason to use it.)
Any program desiring high-performance random numbers has a good reason to use
RDRAND or RDSEED: they produce randomness *far* faster than the kernel, and
with less latency. (For instance, dd if=/dev/urandom of=/dev/disk-to-wipe is
typically gated by the speed of /dev/urandom rather than the disk.) The kernel
should be using RDRAND or RDSEED as appropriate, and it's sad that it doesn't
(or, at least, it's sad that there's no configuration option to do so).
That said, we might want to encourage upstreams to use standardized libraries
that detect the availability of hardware random number generation and
automatically fall back to /dev/urandom or /dev/random (depending on the type
of randomness requested), rather than open-coding such detection/fallback and
inline assembly. That would also help incorporate support for other types of
hardware random number generators, rather than only supporting whatever random
randomness a library author happened to add support for.
> Would it make sense to scan for the opcode?
No, let's not propagate this issue outside the kernel. Anyone wishing to
complain about the use of hardware-accelerated randomness should argue that
upstream with projects that adopt it; Debian should not be taking a position on
this one way or another.
However, just as we encourage projects to reuse libraries rather than
copying code around, we *should* encourage projects to use standardized
randomness libraries rather than hardcoding rdrand (or, for that matter,
hardcoding /dev/urandom).
- Josh Triplett
Reply to: