Re: use of RDRAND in $random_library
Josh Triplett <email@example.com> writes:
> At least two reasons: because a random number source that doesn't
> require kernel privileges should not need to take the performance hit of
> going through the kernel,
I'm very dubious that this performance hit is substantial enough that it
should have an influence on our decision. If we really care about good
random numbers, we're probably in an application where, given a
performance versus security tradeoff, we should always choose security
without a second thought. The small number of applications for which
random numbers are in the performance-critical path are generally crypto
applications where security is paramount.
So the remaining question is if the Linux /dev/random is more secure than
using the hardware random number generator.
> and because many userspace applications will not want to follow the
> kernel's rejection of hardware random number generation.
I've never seen a convincing argument that the kernel /dev/random is
likely to be *less* secure than the hardware random number generator.
It's either more secure or the same level of security. Given that, it's a
risk analysis, and the fact that we have absolutely no idea what the
hardware random number generator is doing, it would be quite possible to
insert a mathematical back door into it, and there's no way to audit it, I
understand why people want to put a software randomization layer that we
*can* audit in front of it.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>