Feeds

FreeBSD abandoning hardware randomness

'Cannot trust them any more'

Top 5 reasons to deploy VMware with Tegile

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

Beginner's guide to SSL certificates

More from The Register

next story
'Regin': The 'New Stuxnet' spook-grade SOFTWARE WEAPON described
'A degree of technical competence rarely seen'
You really need to do some tech support for Aunty Agnes
Free anti-virus software, expires, stops updating and p0wns the world
You stupid BRICK! PCs running Avast AV can't handle Windows fixes
Fix issued, fingers pointed, forums in flames
Regin: The super-spyware the security industry has been silent about
NSA fingered as likely source of complex malware family
Privacy bods offer GOV SPY VICTIMS a FREE SPYWARE SNIFFER
Looks for gov malware that evades most antivirus
Patch NOW! Microsoft slings emergency bug fix at Windows admins
Vulnerability promotes lusers to domain overlords ... oops
HACKERS can DELETE SURVEILLANCE DVRS remotely – report
Hikvision devices wide open to hacking, claim securobods
prev story

Whitepapers

Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
10 threats to successful enterprise endpoint backup
10 threats to a successful backup including issues with BYOD, slow backups and ineffective security.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
The Heartbleed Bug: how to protect your business with Symantec
What happens when the next Heartbleed (or worse) comes along, and what can you do to weather another chapter in an all-too-familiar string of debilitating attacks?