FreeBSD abandoning hardware randomness
'Cannot trust them any more'
In yet another washup from the Snowden revelations, the developers of FreeBSD have decided to take several steps backwards in their crypto work, to stop using hardware random number generators (RNGs).
The two hardware RNGs singled out by the FreeBSD developers in this post are Intel's RDRAND (in Ivy Bridge processors), and VIA's Padlock.
The decision was made at the FreeBSD Developer Summit, held in Malta in September, but the decision to pull the hardware RNGs didn't attract any attention at the time.
“For [FreeBSD] 10, we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random. It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more”, the post states.
One solution on offer from Polish developer Pawel Jakub Dawidek, the post states, is to use the time it takes to attach devices at boot time, and feed these numbers into /dev/random: “it turns out that one can get about 4 good bits of entropy from each device”.
Among the many things Edward Snowden's documents have suggested is that the NIST's crypto standardisation efforts were nobbled by the NSA. This confirmed long-standing knowledge that the Dual Elliptic Curve Deterministic Random Bit Generator is weak, leading to RSA abandoning it in September.
Not everybody believes that RDRAND falls into the same category. Linus Torvalds, for example, dismissed concerns about the instruction, telling the author of an online petition to yank the command from Linux “we actually know what we're doing. You don't”.
In that debate, Torvalds pointed out that RDRAND isn't the only source of entropy for values streamed into /dev/random in a Linux implementation.
Last year, this paper was published by Cryptography assessing Intel's approach, and giving it a pass mark. The Register has approached Intel for comment. ®®
Sponsored: Data Loss Prevention & Data Theft Prevention