It may well be that small hardware could be better for generating keys, as it is much easier to audit the total system, and I'd trust it more than an Intel processor with known remote patching capabilities.
If you're security-sensitive then it could be good having a small, dedicated system like the Pi, and make sure that your private key never leaves it.
Wait a second, wouldn't this statement imply that things like cert-pinning and PFS are completely useless?
Does skepticism of remote patching while trust of the original chip not protect you against being specially targeted if you assume that the chips aren't being wholesale manufactured with back doors built in?
(I mentioned PFS and CP because I perceive them as paradigmatically analogous to the threat model I described - suppose that not ALL of DDG's queries are MITM'd, and yours weren't when you first connected, but you're afraid of the NSA MITMing the queries coming from your connection starting at some date after you made your initial connection to DDG's server, when they start targeting you. If you trust the initial connection, then CP prevents that. Or, again, post facto to you starting to use DDG, the NSA could obtain DDG's SSL private key and decrypt your queries, but if you use PFS, then this is mitigated.
So in each case, it seems, whatever trust you have in the initial transaction -- be it a SSL cert presentation, the particular SSL sessions based on it, or just the purchase of your hardware -- being malice-free, then in each case the pinning/PFS/lack of remote patching abilities guarantees the extension of this trust indefinitely, and prevents the other party from going back after the fact and screwing you, it locks the trust in, so to speak.)
(I realized after typing this that I actually have no idea what specifically remote chipset patching refers to or how it's performed, but I assume that it's what it sounds like.) :-/
Let's say I don't think the NSA has backdoored all the mainstream fablines, but have reason to fear being individually targeted, and assume that the NSA has the power to coerce cooperation from Intel. In that case, would skepticism of post-purchase remote patching not be prudent?
The article is a bit vague about what exactly they're trying to say. What was unexpected? I read it three times before I decided they're comparing a lousy homegrown software RNG to the Pi's hardware RNG, which turns out to be good. Yes? Why would that be unexpected?
The impression I got was that the existence of a hardware random number generator was unexpected.
The rest was just demonstrating that it works, and produces pretty reliable random output. In order to do that, they used a standard tool that tests randomness. But it's nice to make sure your randomness test tool is actually good; so using it on a known-bad RNG, and seeing that it does fail, is a good way to demonstrate that.
The way I read it was that it is surprising that it is there at all.
Apparently a lot of android devices don't have one, and don't have time to collect pseudo random data for their software rng to make secure certificates when you boot it for the first time, which posses a security risk for android devices.
That's how I read the article in relation to recent news.
I'm guessing not everyone on HN is a huge fan of “Strictly Ballroom”, as the title is a key quote for dance movie otaku. It was also a weak joke about testing for random numbers; I'm imagining a little subroutine in a constant state of surprise when it encounters the next random number.
While I'm not sure if I implemented it correctly, RANDU isn't some ‘lousy homegrown software RNG’. It was the standard RNG for IBM mainframes in the late 1960s.
Especially confusing is when the article suddenly says "This is not random". But oh what it means is that the upcoming part of the article, on a completely different topic from the Pi, is not random.
Does anyone have a link for a spec for the RNG? Specifically, where does it get its entropy from? Couldn't find it in the source link. Only mention I could find is a vague mention of "thermal noise" which could mean anything.
/* double speed, less random mode */
#define RNG_RBG2X 0x2
/* the initial numbers generated are "less random" so will be discarded */
#define RNG_WARMUP_COUNT 0x40000
A black box random number generator with some numbers being vaguely "less random"? That seems like an exceedingly poor idea.
I'm not sure that's worrying. Remember, this is hardware. Hardware takes time to turn on and get into a steady state. Many hardware random number generators are based on thermal noise. But in order to get in the correct range for the values to flip, you need to wait for the circuit to warm up to operating temperature.
A classic source of white noise is to reverse-bias a diode or the base-emitter junction of a transistor[1]. This produces shot noise[2] though, which is independent of temperature, so I guess it's not what they are using.
Intel's RDRAND is mentioned in the article as well, near the end. I suspect this article is doing so well because of the recent realization of Intel's involvement with the NSA, and the high potential for backdoors to be included in such a technology.
We can't be sure, but it should be much easier to audit a small system like Pi, rather than an Intel processor that, above all, can be remotely patched.
Huh? Much easier to audit a Broadcom SOC? Than what, auditing deliberately obfuscated hardware designs like the modern DirecTV smartcards?
The idea that it's in any sense easy to "audit" the Raspberry Pi's hardware is head-explodey. No you can't.
This is pure back-rationalization. You like the Raspberry Pi. You don't like Intel Corporation. So you come up with a reason why the R-Pi's hardware RNG might be more trustworthy than than the hardware RNG in a modern Intel computer. It's a crazy reason, not least because the R-Pi's core is produced by another giant semiconductor company.
I'm going to go out on a limb and suggest that the FDIV bug - or heck, even the much more recent (1997!) F00F bug - might not be so contemporary or represent the state of the art of Intel processors.
Being naturally suspicious, I can't help wondering why the Broadcom chip on the Raspberry Pi doesn't have full technical specs publicly available. Seriously, why not?
Their customers are device makers, not small time developers or end users. They just don't want to disclose the information to people without various agreements (and hard sales leads) in place.
For this particular chip, you'd think they'd make an exception. But nooooooo.... Can't have those damned hackers actually knowing the register names, addresses and bit functions. That would be unthinkable.
Do hw rng's get a test suite certificate(NIST's?), like a Swiss watch, or like a optical sextant's `Certificate of Errors'? Tables of mean, standard deviation, etc, for expected physical dependent parameters(what: speed? temp? ...)?
Rng-tools [1], mentioned in the article, can use a hardware rng's output as input to the kernel's prng. However, it needs to be configured correctly to avoid potential problems [2].
Though I can't speak to they're adoption in actual hardware, thermal noise generators are apparently a common way to generate random numbers (https://en.wikipedia.org/wiki/Hardware_random_number_generat...). I would be interested to hear details on how the pi's generator works.
Heh, there was a company that offered just such a beast, basically a network socket and an API to fetch a random number. I thought it was a really subtle joke (like that time I carried around a Diet Coke as my Halloween costume) but once people connected the dots between "Ok, you care so much about a cryptographically secure random number generator you buy an appliance that does nothing else, and then you talk to it over the network..."
As I was building IR beacons for mobile robots at the time, it led me to suggest an IR LED that was connected to a thermal emission source, then you could pick up random numbers by sampling the IR spectrum for a some period of time in your area. At least that way you don't know when the randomness was sampled (well not exactly), and your sniffer has to capture all radiated IR in all directions to ensure it has a complete history if it wants to back correlate it. Harder but still not as simple as just putting it in your machine. (which if you care enough you will do)
What I found unexpected about the Raspberry Pi, was that the CPU chip is closed - very little data available on what's in it. Suddenly 'discovered' hardware RNG being a case in point.
I was waiting for someone to offer offsets to Pi. (Pick a number, count that many digits of Pi, start using the rest of the digits as your RNG numbers.)
Pretend for a moment that you have isolated hardware with no trusted random sources. And this hardware already depends on large secret binary blobs to run at all. At this point trust is already hard, and random.org is a hell of a lot better than nothing. If you mix network jitter with external randomness sources that's just about the best possible job you can do. Neither half is perfect but they help.
Every linux distro has /dev/random as a good, cryptographically secure source of randomness that is refilled by as many sources as possible. It can and has been audited by many developers to ensure this. The main issue you will have is having multiple identical instances of a linux VM built from a single source, or something like that.
Alternatively, you suggest a sole remote source over a public internet connection. Assuming an eavesdropper, the source could be compromised or the strength of the resulting cipher be reduced. Assuming a malicious entity with network control, you're pretty much screwed.
If you don't trust your hardware, you can't be working with encryption.
Software can only do so much without good hardware sources. A small embedded box, barred from networking, has roughly zero entropy available. But if you combine microsecond network timings, only vulnerable to local attack, with third party random data that is safe from mitm, you get resonably good random numbers. Don't use it to generate a root certificate, but it'll work for general purposes.
How about this: it's much easier for an attacker to physically compromise the device than it is for them to attack your network AND attack random.org.
Is that not good enough? It's about as secure as your average desktop. You can't make a device more secure than the access to it, and there is no such thing as perfect security.
So OK, the Pi has a thermal RNG. Next question - does this:
http://www.damninteresting.com/random-event-generators-predi... (and google for related articles)
supposedly only happen for some types of hardware RNGs? Nuclear decay based RNGs? Or all types - thermal, semiconductor shot noise, wind-chimes or whatever?
Sounds like a candidate for large scale experiment.
If you're security-sensitive then it could be good having a small, dedicated system like the Pi, and make sure that your private key never leaves it.