back to article FreeBSD abandoning hardware randomness

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 …

COMMENTS

This topic is closed for new posts.
Silver badge
Trollface

I say we take off and look again at Lavarand. It is the only way to be sure.

1
0
Silver badge

With a little bit of integrated circuitry and a noise diode, you could make a random number generator that fitted into a small package with a USB interface, like a USB memory stick or maybe a little bigger. It could have open source drivers that not only read the number but gave it a random 'scrambler' kick every time there was a disk access or whatever. It would be personal and totally unpredictable.

1
0

Done some time ago, e.g. http://www.araneus.fi/products-alea-eng.html

2
0
Silver badge

"You could make a random number generator"

There are some commercial implementation for sale:

http://www.protego.se/

http://www.idquantique.com/random-number-generators/products, html

http://www.westphal-electronic.de/zranusbg.htm

1
0
Silver badge

Re: "You could make a random number generator"

Thank you for those examples! I hope they haven't been awarded patents because the entire thing is 'obvious to anyone skilled in the art' and I'm not even particularly skilled in that area.

1
0
Silver badge
Black Helicopters

Re: "You could make a random number generator"

Of course, to be really sure, you have to solder it together yourself from basic components... After all, who knows what really is in the commercial black boxes.

2
0

Re: "You could make a random number generator"

You could also use something like the audio entropy daemon and listen for atmospheric noise.

0
0
Anonymous Coward

Re: "You could make a random number generator"

Yeah a device that listens for atmospheric noise... that won't set off another round of "the NSA is Bugging our hardware" stories at all...

0
0
Silver badge

Re: "You could make a random number generator"

I've personally grown fond of a webcam entropy generator and have actually been fiddling with it to make it more suitable as an RNG (mostly in finding better ways to scrub). Not that I've actually needed it as a source of entropy, as it seems HAVEGED can do the job pretty well, be it on your computer or your Android phone.

0
0
Bronze badge

Re: "You could make a random number generator"

Atmospheric noise (and other sources) have been done, although I suppose you'd want a plugin device instead of a web site. To quote myself from over a year ago:

Other sites that have done this: Lavarnd (<http://www.lavarnd.org/>, yes, randomness from a lava lamp), Hotbits (<http://www.fourmilab.ch/hotbits/>, "Genuine random numbers, generated by radioactive decay"), and Random.org (<http://www.random.org/>, which uses atmospheric noise).

1
0
Silver badge

Re: AVEGED

> it seems HAVEGED can do the job pretty well, be it on your computer or your Android phone

Yes, but HAVEGE originates from a French institute (http://www.irisa.fr/caps/projects/hipsor/index.php) and so is likely to fart in your general direction, you son of silly persons.

* Attached to the Uni I got my Master from, as luck would have it

2
0
Bronze badge

Re: "You could make a random number generator"

Or the Entropy Key, which at just 36 quid is a helluva lot cheaper than those others.

0
0
Anonymous Coward

Re: "You could make a random number generator"

But unfortunately not really available at the moment:

"We've gone through a major crisis, but are still here... just. To say any more in public at this stage might be unwise from a legal standpoint. We currently have no manufacturing capability for ekeys but are working towards getting things up and running again. There's no timescale on that yet, I'm afraid."

http://lists.simtec.co.uk/pipermail/entropykey-users/2013-July.txt

I wish they'd set up a kickstarter or indiegogo project to get the funding (assuming that's what's lacking).

0
0
Silver badge

Re: "You could make a random number generator"

"But unfortunately not really available at the moment:"

Their phone number is disconnected. That's not a great sign.

1
0
Bronze badge
Devil

Re: "[explaining is] unwise from a legal standpoint"

Curious. I wonder which law that might be?

Has Simtec become the victim of a patent troll?

Thankfully I bought my Entropy Key years ago.

0
0
Silver badge

Re: AVEGED

"Yes, but HAVEGE originates from a French institute (http://www.irisa.fr/caps/projects/hipsor/index.php) and so is likely to fart in your general direction, you son of silly persons."

It's not like it's being used directly. In Linux, it's used like most other HW generators are: shoveled into the kernel entropy pool where the kernel then does the scrubbing. In that context it's at worst harmless and at best quite useful.

And failing that I can go back to the webcam generator, since I've been monkeying with the code personally, I know what's going on. The original code did plenty of whitening, but in my tests using a cheap webcam with the lens taped over (and just to be sure, it's face-down) it couldn't pass FIPS 180-2 tests until after I gave it a further parity scrub. Beats waiting on an Entropy Key.

0
0

It's not just the silicon

You have no reason to trust virtual silicon either, how about asking hypervisor makers some hard questions about their implementation of RDRAND and if the NSA etc' have been in their ear?

4
0
Anonymous Coward

Nature

Useful mathematical concepts often occur in nature. For example, cicadas that emerge at prime-numbered year intervals find themselves relatively immune to predator population cycles, since it is mathematically unlikely for a short-cycled predator to exist on the same cycle.

Similarly, true randomness is quite useful, so you would think that it would occur somewhere in nature.

0
0
Silver badge

Re: Nature

Of course. Just take an alpha emitter for example and clock the number of decays detected. Intel's implementation uses a "a self-oscillating digital circuit with feedback", fed into some verification and AES magic.

0
0
Silver badge

Well you should never use the direct output of a random source...

As random sources can be "correlated", e.g. if you have a diode acting as a noise source it will not have infinite bandwidth. This means that the chance of a bit change is a bit less than 50% since the output cannot quite move as fast between 0 and 1 as it would be on an ideal generator. Effectively this means that you have a bit less than one Shannon per bit.

That's why you typically take your random sources, put them into a pseudo random generator and stir them. You carefully count how much enthrophy you put in there and how much you pull out. If you run out of enthropy you wait until you have new one. If you don't trust one source, you simply assume you got less enthropy from it and carry on.

3
1
Silver badge
Linux

Re: "Not everybody believes that RDRAND falls into the same category"

Yes, everybody does. The FreeBSD guys did what Linux was already doing, i.e. feeding the hardware number into a software generator as just another source of entropy. That's why they needed a change, and Linux did not.

7
0
Anonymous Coward

Re: "Not everybody believes that RDRAND falls into the same category"

My understanding is that pseudo random number generators have nothing to do with providing entropy which is what this is all about. What Linux does is XOR the rrand provided values with other sources of entropy and a commentator here http://security.stackexchange.com/questions/42164/rdrand-from-dev-random says that may not be a good idea either.

0
0
Silver badge

Re: "Not everybody believes that RDRAND falls into the same category"

> My understanding is that pseudo random number generators have nothing to do with providing entropy which is what this is all about. What Linux does is XOR the rrand provided values with other sources of entropy

Mmmmyes, and that's what I wrote, isn't it?

> a commentator here http://security.stackexchange.com/questions/42164/rdrand-from-dev-random says that may not be a good idea either.

Messing with the XOR instruction so that it behaves differently when used with RDRAND as an input is a different issue that was brought up mainly by the tinfoil hat brigade; it would be hard to implement, trivial to detect, trivial to defeat and would be an awful lot of investment for something bound to target only one implementation of one system. Plus, it would be pure commercial suicide.

3
0

Re: "Not everybody believes that RDRAND falls into the same category"

//Messing with the XOR instruction so that it behaves differently when used with RDRAND as an input is a different issue that was brought up mainly by the tinfoil hat brigade; it would be hard to implement, trivial to detect, trivial to defeat and would be an awful lot of investment for something bound to target only one implementation of one system. Plus, it would be pure commercial suicide.//

However, messing with the XOR instruction isn't the obvious attack.

If the attacker can access the stored pool, merging input with it by XOR makes it trivial to create whatever output the attacker desires. This includes sequences which look random, but arn't - in any subtle way the attacker needs.

0
0
Anonymous Coward

Re: "Not everybody believes that RDRAND falls into the same category"

> Mmmmyes, and that's what I wrote, isn't it?

Indeed it is, apparently I've misread your post as talking about pseudo-RNGs.

Also, I've since learnt that RDRAND is not pure entropy, that's apparently what RDSEED is for. I shall stop now for I do not have enough of a clue!

0
0

Linux wasn't using RDRAND directly

Linux never used RDRAND directly, it used its own random number generator then XOR'd the result with RDRAND output. The effect of this is that if EITHER the Linux algorithm output is good, OR the RDRAND output is good, THEN the final output is good.

He knows what he is talking about, those criticising didn't.

1
0

Re: Linux wasn't using RDRAND directly

"if EITHER the Linux algorithm output is good, OR the RDRAND output is good, THEN the final output is good"

... provided that the two are uncorrelated, and that the XOR instruction hasn't been modified to recognise when it is working with RDRAND output.

0
1
Anonymous Coward

Re: Linux wasn't using RDRAND directly

Subverting the XOR instruction to give anything other than the correct result would be so easy to detect, and would have no possible plausible deniability as a 'bug', that it would be Intel's suicide note to implement.

4
0
Silver badge

Re: Linux wasn't using RDRAND directly

Question 1: How would the processor know it is dealing with RDRAND output if the data becomes one degree removed (ex: MOV'd into a general register before XORing)?

Question 2: How would the Linux RNG, which IINM relies more on various CSPRNG techniques that are well-removed from RDRAND, be compromised so as to correlate to RDRAND without it appearing in the source in some way?

3
0

Re: Linux wasn't using RDRAND directly

oh FFS, XOR is an instruction that directly maps to the hardware microcode and directly acts on the registers, there is naff all intelligence in it...

2
0
Bronze badge

Re: Linux wasn't using RDRAND directly

That's what they want you to think.

Processors are much bigger physically than 8x the size they were in 1983, even though they've only gone from 8-bit to 64-bit. Coincidence? The voice in my head tells me not.

0
2
Silver badge
Pint

Re: Linux wasn't using RDRAND directly

> Processors are much bigger physically than 8x the size they were in 1983

ORLY? the iAPX 432 die was 345 mm². Times 8 that's 2760 mm², or a bit more than 5x5 cm, for the processing die alone, not the package. Ivy Bridge is 160 mm²... a bit less than half the size of iAPX 432.

So whatever the secret NSA-addeed instructions may be, they must be written in a somewhat smaller case than the iAPX ones were.

2
0
Silver badge
Thumb Up

Re: Linux wasn't using RDRAND directly

the XOR instruction hasn't been modified to recognise when it is working with RDRAND output

Excellent trolling, the same people who unlock the backward compatibility on XBOXONE must fall for this.

1
0
Anonymous Coward

Re: Linux wasn't using RDRAND directly

> Linux never used RDRAND directly

I think you're wrong on this:

"Intel engineers had the Linux kernel using RDRAND directly as the output to /dev/[u]random for about a year before I took back that change" -> Theodore Ts'o on his Google+ ... uhm... page/blog/thing.

0
0

Schneier blog already went into all of that

https://www.schneier.com/blog/archives/2013/10/insecurities_in.html

Theodore Ts'o, the original developer of /dev/random, also chimed in on the thread.

1
0
This topic is closed for new posts.

Forums