Feeds

FreeBSD abandoning hardware randomness

'Cannot trust them any more'

Securing Web Applications Made Simple and Scalable

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

The smart choice: opportunity from uncertainty

More from The Register

next story
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
How long is too long to wait for a security fix?
Synology finally patches OpenSSL bugs in Trevor's NAS
Don't look, Snowden: Security biz chases Tails with zero-day flaws alert
Exodus vows not to sell secrets of whistleblower's favorite OS
Roll out the welcome mat to hackers and crackers
Security chap pens guide to bug bounty programs that won't fail like Yahoo!'s
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Researcher sat on critical IE bugs for THREE YEARS
VUPEN waited for Pwn2Own cash while IE's sandbox leaked
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.