Feeds

FreeBSD abandoning hardware randomness

'Cannot trust them any more'

Reducing security risks from open source software

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. ®®

Mobile application security vulnerability report

More from The Register

next story
LibreSSL RNG bug fix: What's all the forking fuss about, ask devs
Blow to bit-spitter 'tis but a flesh wound, claim team
Microsoft: You NEED bad passwords and should re-use them a lot
Dirty QWERTY a perfect P@ssword1 for garbage websites
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
NUDE SNAPS AGENCY: NSA bods love 'showing off your saucy selfies'
Swapping other people's sexts is a fringe benefit, says Snowden
Own a Cisco modem or wireless gateway? It might be owned by someone else, too
Remote code exec in HTTP server hands kit to bad guys
British data cops: We need greater powers and more money
You want data butt kicking, we need bigger boots - ICO
Crooks fling banking Trojan at Japanese smut site fans
Wait - they're doing online banking with an unpatched Windows PC?
NIST told to grow a pair and kick NSA to the curb
Lrn2crypto, oversight panel tells US govt's algorithm bods
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
The Essential Guide to IT Transformation
ServiceNow discusses three IT transformations that can help CIO's automate IT services to transform IT and the enterprise.
Mobile application security vulnerability report
The alarming realities regarding the sheer number of applications vulnerable to attack, and the most common and easily addressable vulnerability errors.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.