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 …
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.
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.
> 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
"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.
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).
Or the Entropy Key, which at just 36 quid is a helluva lot cheaper than those others.
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).
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.
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.
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.
> 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.
//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.
> 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!
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.
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?
> 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.
> 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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
