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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140611224541.GA12701@jtriplet-mobl1
