
ChaosKey: a Hardware True Random Number Generator That Attaches via USB - pmoriarty
http://altusmetrum.org/ChaosKey/
======
FiloSottile
These tokens, like the OneRNG, are quite interesting from an engineering point
of view, but as a developer all you ever need to know or do about secure
randomness is to use /dev/urandom and nothing else (unless it's a wrapper for
/dev/urandom).

Not /dev/random, not rand(), not something you found in a library. Just bytes,
read from /dev/urandom.

Here is my CCC talk about why that is, which includes everything from kernel
sources to authoritative quotes:
[https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of...](https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy)

EDIT: the talk is in English, but you have to select it from the video UI, in
the bottom right.

~~~
nine_k
I wonder what to use on Windows. Because sometimes you maybe need robust
randomness on a popular desktop.

~~~
veeti
CryptGenRandom [1] would be the equivalent.

[1] [https://msdn.microsoft.com/en-
us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/aa379942\(v=vs.85\).aspx)

~~~
cpeterso
Or rand_s(), which wraps CryptGenRandom() with a more convenient API:

[https://msdn.microsoft.com/en-
us/library/sxtz2fa8.aspx](https://msdn.microsoft.com/en-
us/library/sxtz2fa8.aspx)

~~~
ryuuchin
RtlGenRandom[1] is probably the most convenient way on Windows. Does require
certain definitions when including the header file for it[2] but otherwise
does not require a CSP context and can generate any number of CSPRNG bytes.

[1] [https://msdn.microsoft.com/en-
us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/aa387694\(v=vs.85\).aspx)

[2]
[https://boringssl.googlesource.com/boringssl/+/master/crypto...](https://boringssl.googlesource.com/boringssl/+/master/crypto/rand/windows.c#26)

~~~
cpeterso
You're right. Calling RtlGenRandom() directly is probably the best option. I
forgot that rand_s() calls RtlGenRandom(), not CryptGenRandom(). Plus both
Firefox and Chrome ran into rare crashes when some bad third-party software
(antivirus or malware) injects advapi32.dll hooks, causing rand_s() to crash
when it tries to load advapi32.dll in order to call RtlGenRandom().

Firefox bugs: [https://bugzil.la/1240589](https://bugzil.la/1240589),
[https://bugzil.la/1167248](https://bugzil.la/1167248),
[https://bugzil.la/694344](https://bugzil.la/694344)

Chrome bug: [https://crbug.com/348400](https://crbug.com/348400)

~~~
ryuuchin
You can also specify the number of bytes you want with RtlGenRandom. rand_s
only gives an unsigned int per call. Not a huge deal but you may be able to
cut down on some function call overhead depending on how stuff gets
inlined/optimized.

------
atoponce
I noticed that this hasn't been mentioned yet, so I'll bring it up here. While
RF-based noise generators can be influenced by outside sources, using an RTL-
SDR with [https://github.com/pwarren/rtl-
entropy](https://github.com/pwarren/rtl-entropy) can be a great way to get
environmental RF noise.

In actual reality, the generator won't be influenced, because it will require
a strong signal, close by, likely transmitting illegally on the frequency you
are listening to (of course, the attacker would need to know the frequency
you're tuned to). Simple monitoring tools and scripts can be used to test the
quality of the generator output. If the quality of the randomness begins to
fail, as would happen with deliberate RF interference, then the script would
stop outputting bits, and alert the administrator. Or, even better, switch to
a different frequency, chosen at random by the kernel CSPRNG.

What's great about using the RTL-SDR as an RNG, is these devices are cheap
(about $20) and can output 3 MiBps, which vastly out performs any USB HWRNG
that I have personally tested for the value (bits per second per dollar).

FWIW, random.org uses RF noise as the basis for delivering random numbers to
the Internet.

Anyway, FYI.

------
nickpsecurity
If you're going to have a blackbox (the SOC), you might as well get a
BitBabbler as they have better design for noise and the black box is dumbest
USB chip they could find.

[http://www.bitbabbler.org/index.html](http://www.bitbabbler.org/index.html)

Needs more peer review and independent testing anyway. It's designed so you
can do it yourself with a logic analyzer or whatever.

EDIT: I should add that, quite interesting to me, BitBabbler folks are
building this for people who already know why a TRNG or analog source is
important. They're not interested in evangelizing or winning anyone over: just
people already wanting one buying it and preferably analyzing it to give them
feedback on esoteric failure modes they haven't thought of. Only contact them
if you're serious.

~~~
tonetheman
This looks cool... but no prices... Are these super expensive or did nerds
design their site :)

~~~
nickpsecurity
They were in the $100-200 range IIRC. Funny thing about your comment on
design:

"If you want to know more about the company where this all started, the
Voicetronix website can tell you all about that, in all its only slightly
updated since the mid 90's glory. We're engineers who build great hardware and
provide exceptional support for it ... Web 2.0 bling isn't quite our favourite
thing to spend time on :) " (source: bottom of Buy page)

Haha. Anyway, I tried to find price but couldn't. If you want one, just email
them at the address in BitBabbler Buy tab for a price quote. That's how they
typically work. Here's the company if you're curious:

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

Their differentiator, per their lead engineer, was quality hardware with free
as in speech software and custom service/support. I found that interesting esp
given it's a 90's era business that predates the OSS HW fads. A model worth
copying perhaps.

Note: I haven't hands on reviewed a BitBabbler or their other products. Not
endorsing them. Just like what I saw and heard vs what I usually see and hear.
Suggesting others review, test, or use the products to see if they live up.

------
jordanlev
Curious how exactly this generates truly random numbers (and didn't see an
explanation in the link). Can anyone explain this in technically-inclined
laymen's terms?

fwiw, I'm a programmer but don't know anything about random number generation
(other than I'm not supposed to rely on the built-in random functions of most
languages/libraries for security purposes because they're not truly random).

~~~
adrusi
We think that cosmic background radiation and certain subatomic mechanics are
truly random. If you attach extra hardware to a computer, you can observe
these and send a stream of bits to the computer.

You don't usually want to use truly random numbers for cryptography though;
/dev/random is more appropriate. I've never understood why, exactly, but
that's generally the advice.

~~~
witty_username
You can use "truly" random numbers for cryptography. /dev/random is not
recommended (except for perhaps long-term keys if you're worried about the
randomness algorithms having a vulnerability), use /dev/urandom.

~~~
floatboth
> except for perhaps long-term keys

On most systems, urandom and random are the exact same thing. Only Linux does
this weird "blocking random" thing, based on some weird estimate of "running
out of entropy" which is not an actual thing.

(u)random is powered by a CSPRNG which is seeded by "truly random numbers"
gathered from multiple hardware sources.

------
voidz
Another project is TrueRNG. They provide a small USB device, and a more
expensive, larger TrueRNG Pro device, via [http://ubld.it/](http://ubld.it/)

------
Animats
Noise-source based random number generators can be vulnerable to interference.
If there's a radio transmitter nearby, the RF may add an input to the noise.
An RF source with a strong carrier will add a periodic value. Not good.

Radiation sources really are random. You get a nice strong signal from each
decay sensed, and the time between those events is random.

~~~
atoponce
Radioactive decay is slow, slow, slow. There are much better performing
sources of randmness, such as beam splitting.

Further, not all noise is RF-based. Thermal noise, for example, is not
influenced by RF intereferrence.

~~~
PhantomGremlin
_Radioactive decay is slow, slow, slow._

Here's a cheap way to generate 800 bits per second from radioactive decay.
[https://www.fourmilab.ch/hotbits/](https://www.fourmilab.ch/hotbits/)

Why aren't 800 honest-to-goodness random bits per second enough for all
practical purposes? If you need more than that, you should be playing in the
big leagues, where using a little USB fob is not the answer!

~~~
atoponce
_Why aren 't 800 honest-to-goodness random bits per second enough for all
practical purposes?_

For seeding the system CSPRNG, that's fine. For securely destroying data, such
as wiping hard drives, or creating underlying noise for encrypted filesystems,
800 Bps is going to take you years to work through a 4 TB hard drive.

~~~
PhantomGremlin
_800 Bps is going to take you years to work through a 4 TB hard drive_

But you don't need to do that. You simply take 256 bits and use them as an AES
key. You then generate a stream of bits and write that to disk. Reading the
disk afterward is equivalent to breaking AES. Or take Bernstein's advice and
use an even better stream cipher.
[https://cr.yp.to/streamciphers/why.html](https://cr.yp.to/streamciphers/why.html)

And even if you re-key every 1 GB (just for grins), you're still hardly using
any random bits at all.

OTOH check out this comment elsewhere in this thread.
[https://news.ycombinator.com/item?id=11560417](https://news.ycombinator.com/item?id=11560417)

IDQuantique sells a product that purportedly generates millions of random bits
per second. If I were gambling at a casino, I'd feel more comfortable with
that than with randomness from an AES stream.

Yeah, I know I'm thinking irrationally. But I'm sure I'm not the only one.

~~~
atoponce
_But you don 't need to do that. You simply take 256 bits and use them as an
AES key. You then generate a stream of bits and write that to disk. Reading
the disk afterward is equivalent to breaking AES._

Completely agreed. I've already mentioned in this post about only using the
Linux CSPRNG to seed a userspace CSPRNG, because the Linux CSPRNG is
horrendously slow, due to its ad-hoc design. However, if the Linux CSPRNG was
AES-128 using the standard CTR_DRBG, with AES-NI, it could go north of 2 GiBps
without breaking a sweat, keeping clean random.c code (it already ships
aes.h), and it's backtracking resistant.

However, if you're going to spend good money for hardware producing random
values, at least for me, I'm going to want the best bang for my buck. If you
look at
[https://en.wikipedia.org/wiki/Comparison_of_hardware_random_...](https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators),
you can spend $35 for the WaywardGeek "Infinite Noise RNG", which outputs 300
Kbps, or spend $24 for an RTL-SDR dongle and get about 2.8 MiBps. The value of
bits per dollar is much higher with the RTL-SDR than the WaywardGeek. This is
considerably cheaper than getting a radioactive sample, coupled with a Geiger
counter.

 _IDQuantique sells a product that purportedly generates millions of random
bits per second. If I were gambling at a casino, I 'd feel more comfortable
with that than with randomness from an AES stream. Yeah, I know I'm thinking
irrationally._

Yeah, that is irrational. The problem with most TRNGs is that their output is
biased. As a casino operator, I might be interested if the bias benefits my
casino, but I would also need to prove to regulators that I'm not cheating the
public. Personally, I'd err on the side of caution when it comes to the law.

So either I would whiten the output with a cryptographic primitive (John von
Neumann debiasing is too costly, losing at least 1/2 the bits), or just write
a userspace CSPRNG, and get the throughput you'll need for the demand. I could
then constantly rekey/rseed the generator with the TRNG if I was tinfoil-hat-
paranoid.

In either case, TRNG or CSPRNG, you'll want exceptional throughput for your
casino. Which brings us back to another example of which 800 bps just isn't
going to cut it. :)

------
gravypod
Has anyone done any cryptographically analysis with these things?

I'd love to get my hands on one of these and do some statistics on a lot of
data pulled off of these.

To be honest, I think that at certain controlled temperatures, I'd bet you
could start to weight numbers for prediction if you are trying to break crypto
keys generated by these.

~~~
DanBC
Here's a very old (1997) examination of 3 devices:
[http://www.robertnz.net/true_rng.html](http://www.robertnz.net/true_rng.html)

I see a few hardware RNGs, and they're usually uncased. I think I'd want it in
a good quality shielded case.

~~~
gravypod
I hate to make anyone feel old, but I'm as old as this study. Does this
information still hold true today?

I'd wonder what big data analysis of this data would show us (IE occurrences
of certain samples of 1 TB of data polled).

------
trothamel
Does anyone know how this compares to the hardware random number generators
built into most computers?

------
teddyh
Looks great! So how do I _buy_ one? Is it still in development?

------
FredericJ
If those kind of devices interest you, I'm quite intrigued by the IDQuantique
ones that are based on quantum physics to generate randomness. They have a USB
product that has a random stream of 4Mbits/sec and is used by lotteries and
gambling sites.

[http://www.idquantique.com/random-number-
generation/quantis-...](http://www.idquantique.com/random-number-
generation/quantis-random-number-generator/)

~~~
Cyph0n
Intel has a patent on a TRNG that has a throughput of 2 Gbps+. They published
a paper on its operation in JSSC a while back [1]. It passes all NIST RNG
tests and is PVT tolerant. Too bad it's patented...

[1]:
[http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6...](http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6339068)

------
kabouseng
Would have been nice if they posted some of the output of the RNG's as well as
the results from some tests on the randomness of the output like Die hard[1]:

[https://en.wikipedia.org/wiki/Diehard_tests](https://en.wikipedia.org/wiki/Diehard_tests)

------
cm2187
Is there any reason we don't have hardware RNG in modern CPUs/MB? It sounds
like an obvious feature to have as a standard, when we think of the efforts
required to create a decent software pseudo RNG, and the fact that crypto is
absolutely everywhere.

~~~
stegosaurus
[https://en.wikipedia.org/wiki/RdRand](https://en.wikipedia.org/wiki/RdRand)

Choice bits:

>> RDRAND is available in Ivy Bridge processors

Theodore Ts'o:

>> Relying solely on the hardware random number generator which is using an
implementation sealed inside a chip which is impossible to audit is a BAD
idea.

------
SFJulie
well, it makes a lot of man in the middle : the HW USB susbsystem, the USB
driver, the OS, the driver or the electronic doing the interface. Plus it
makes a lot of electromagnetic vulnerabilities (reading/influencing with a
magnetic field)

A purely paranoid person would really prefer something with an antenna (to get
some noise by detection), some RLC, a defective/chaotic oscillator on the dye
of an a SOC that makes it embedded and you can verify by looking with a
microscope that you shield in a Faraday cage.

And no, deciphering logic of a microchip with a microscope is not that hard ;
almost anyone can do it with a tad of training and some education.

------
petra
Good project.

A question: Is there value in cryopto-signing the random numbers this emits ?

------
homero
These are awesome but we need vps's to add these

~~~
witty_username
Why? Once /dev/urandom is seeded, you can use it for an unlimited amount.

~~~
homero
That's not a trng

~~~
witty_username
Not philosophically random, but practically random (i.e. impossible for an
attacker to predict the values).

------
JacksonGariety
"truly random" is an oxymoron, folks

~~~
atoponce
I don't think so. In the terms of "random that does not follow a known
deterministic algorithm or formula", both chaotic sources like lightning
strikes, and quantum states, like photon spin, can be so random, that for all
definitions of "truly random", they fit the bill.

