Josh Triplett <j...@joshtriplett.org> 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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/878up2jb9y....@windlord.stanford.edu
