
The Raspberry Pi’s Hardware Random Number Generator - DanBC
http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/
======
PeterisP
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.

~~~
tptacek
If you don't trust a chip vendor's remote patching, there's nothing you can
trust on the chip cryptographically at all.

~~~
ooorlllyyy
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?

~~~
tptacek
Yes, if you think the NSA has backdoored all mainstream Intel chips, then
certificate pinning and forward secrecy are not particularly meaningful.

~~~
ooorlllyyy
(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.) :-/

------
hamburglar
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?

~~~
wodenokoto
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.

~~~
steevdave
Actually most ARM processors do have a hardware RNG, just that few companies
write a driver for them

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

~~~
DanBC
I found the link on Reddit. They're asking similar questions.

So far Reddit hasn't got any answers; someone posted a link to a mailing list.
Here's a similar link.
([https://lkml.org/lkml/2013/3/24/144](https://lkml.org/lkml/2013/3/24/144))

> _This adds a driver for random number generator present on Broadcom BCM2835
> SoC, used in Raspberry Pi and Roku 2 devices._

Here's a github for the blob source
([https://github.com/raspberrypi/linux/blob/rpi-3.6.y/drivers/...](https://github.com/raspberrypi/linux/blob/rpi-3.6.y/drivers/char/hw_random/bcm2708-rng.c))

It's a frustrating lack of information. :-/

(I posted here partly because of the Intel RdRand stuff the other day, but
also RPis are fun and this could be a fun experiment.)

~~~
Scaevolus
Some of these comments are particularly worrying:

    
    
        /* 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.

~~~
lambda
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.

------
steve918
A good number of Intel processors have hardware rngs.

[http://software.intel.com/en-us/articles/intel-digital-
rando...](http://software.intel.com/en-us/articles/intel-digital-random-
number-generator-drng-software-implementation-guide)

Of course they're not on $35 boards, but the server machines you are using may
already have this.

~~~
shawnz
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.

~~~
mahyarm
Broadcom is a similarly huge USA company in ARM computers & networking, are we
sure they haven't been involved with the NSA either?

~~~
PeterisP
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.

~~~
btian
Intel processor can be remotely patched?! Then why did Intel spend $475m to
fix the FDIV bug?

~~~
ethomson
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.

------
e3pi
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?
...)?

~~~
EvanKelly
Here are the NIST recommendations referenced in the FIPS 140-2 approved RNG
appendix:

[http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A...](http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf)

~~~
e3pi
Thank you. For the last few days, I've been looking for the The NIST
Statistical Test Suite, not in C#, have you a link?

~~~
EvanKelly
Sorry, I just found the above from a quick google search for "FIPS 140-2 rng"
which I noticed referenced in the rngtester output in the article.

------
trebor
Is there a way to seed /dev/urandom and /dev/random from it?

~~~
moonboots
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].

[1] [http://www.gnu.org/software/hurd/user/tlecarrour/rng-
tools.h...](http://www.gnu.org/software/hurd/user/tlecarrour/rng-tools.html)

[2]
[https://news.ycombinator.com/item?id=6040975](https://news.ycombinator.com/item?id=6040975)

------
teeja
For those looking for something a little less than formal perfection (whatever
that really is), FM receivers can be a useful source of rands.

Discussion:
[http://www.ciphersbyritter.com/NEWS5/FMRNG.HTM](http://www.ciphersbyritter.com/NEWS5/FMRNG.HTM)

------
codezero
What barriers keep thermal random number generators from being widely
available? Or are they actually?

~~~
DanBC
Sometimes they're not very good. Sometimes they're just very expensive.

There are a range of different hardware devices available on various plugin
boards. And processors have started to include them as well.

Here's a very old (1997?) examination of 3 hardware devices:
([http://www.robertnz.net/true_rng.html](http://www.robertnz.net/true_rng.html))
and he has some nice information here too:
([http://www.robertnz.net/hwrng.htm](http://www.robertnz.net/hwrng.htm))

Here's my list of recent reading, not all of it relevant.

([http://csrc.nist.gov/groups/ST/toolkit/rng/documents/nissc-p...](http://csrc.nist.gov/groups/ST/toolkit/rng/documents/nissc-
paper.pdf))

([http://www.paulm.org/random.html](http://www.paulm.org/random.html))

([http://www.cryptography.com/public/pdf/IntelRNG.pdf](http://www.cryptography.com/public/pdf/IntelRNG.pdf))

Build one yourself:
([http://www.labbookpages.co.uk/electronics/hwRNG.html](http://www.labbookpages.co.uk/electronics/hwRNG.html))

Here's a list of devices:

([http://www.westphal-electronic.com/](http://www.westphal-electronic.com/))

([http://www.trng98.se/shop/index.php](http://www.trng98.se/shop/index.php))

([http://www.comscire.com/](http://www.comscire.com/))

([http://www.idquantique.com/random-number-
generators/products...](http://www.idquantique.com/random-number-
generators/products...))

([http://www.letech.jpn.com/](http://www.letech.jpn.com/))

And someone upthread posted a link to EntropyKey.

~~~
codezero
Thanks, very helpful.

------
schrodingersCat
Perhaps this is a new application for the pi? A dedicated entropy appliance
could be useful

~~~
ChuckMcM
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)

~~~
jfb
Similar in spirit to SGI's Lavarand [1]

[1]
[http://web.archive.org/web/19971210213248/http://lavarand.sg...](http://web.archive.org/web/19971210213248/http://lavarand.sgi.com/)

~~~
justin66
Awesome. Thank you for sharing that.

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

~~~
technimad
That's why I use the BeagleBoard.

------
cpeterso
Here is my proposed RNG for network devices that don't generate much entropy
of their own:

    
    
      strace -Tiv -ttt nice curl -Lv --raw $URL 2>&1 | shasum | dd bs=1 count=2 2>/dev/null
    

Possible values of $URL might be
[https://news.google.com](https://news.google.com),
[https://en.wikipedia.org/wiki/Special:Random](https://en.wikipedia.org/wiki/Special:Random),
or the Twitter Firehose. :)

~~~
wodenokoto
If you are connected to the internet, why not get your randomness from
[http://www.random.org/](http://www.random.org/) ?

~~~
marshray
This thread is a joke, right?

~~~
Dylan16807
What's a joke?

There is nothing ridiculous about using network timing as random, that's how
/dev/random already works.

There is nothing ridiculous about using random.org, though that should be
https.

~~~
nwh
> There is nothing ridiculous about using random.org, though that should be
> https.

Everything is wrong about this.

• You can not trust SSL to protect your source of entropy.

• You can not trust an external, unverified source of entropy.

~~~
Dylan16807
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.

~~~
nwh
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.

~~~
Dylan16807
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.

~~~
marshray
> Don't use it to generate a root certificate, but it'll work for general
> purposes.

"General purposes" is exceedingly hard to quantify.

~~~
Dylan16807
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.

------
TerraHertz
So OK, the Pi has a thermal RNG. Next question - does this:
[http://www.damninteresting.com/random-event-generators-
predi...](http://www.damninteresting.com/random-event-generators-predict-the-
future/) (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.

