
USB Random Number Generator - fnordfnordfnord
http://jayakody2000lk.blogspot.com/2013/09/usb-random-number-generator.html
======
jaseg
I would seriously advise anybody from using this device. Designing a hardware
true random number generator takes a lot of effort that this design is
evidently lacking. For example, there is no whitening whatsoever. Even worse,
the firmware includes a line of code that ensures that the "RNG" never outputs
the same "random" number twice in a row.

Also, usually HW RNGs include a firmware module that is constantly monitoring
the entropy output and shutting off the generator in case of it sinking below
a certain threshold to detect hardware failure and prevent it from causing
predictable output.

Some more information on this subject can be found at Wikipedia:
[https://en.wikipedia.org/wiki/Hardware_random_number_generat...](https://en.wikipedia.org/wiki/Hardware_random_number_generator#Performance_test)
I do not want to discourage anybody from working on such things. I think this
is a nice project idea and a very good opportunity to learn a lot about random
numbers. Please, though, always put a _big_ warning on any crypto things you
designed youself and do not present them as a finished product.

[edit]s/such a/this/1[/edit]

~~~
bayesianhorse
If noone knows you're using it, the device might even be better than a
software RNG.

~~~
jaseg
I don't think so. The PRNG will at least be less biased.

~~~
msandford
That's only assuming that the PRNG hasn't been backdoored or otherwise
compromised by the NSA. If it has, damn near ANY hardware RNG will be better
than it. If not, then you're right.

------
dspillett
Rolling your own random number generator should be considered the same as
rolling your own crypto: by all means have a play in order to help understand
the concepts, but unless you are an expert in the relevant
mathematics+electronics don't every use your own in production.

Designing a reliably fair and balanced RNG is not as easy a task as it may
seem at first glance.

For those wanting a cheap HWRNG, a growing number of CPUs include them now.
The SoC around which the rPi is based includes one that in my tests reliably
pumps out 550+kbit/sec and passes the test I've thrown its output at - getting
at it is easy so you just need a secure+reliable method for passing the bits
to where you need them. Newer Intel chips also include a HWRNG, though I don't
know if is as easy to expose (with the rPi just enable the relevant kernel
module and read from /dev/hwrng).

[I did add notes on this to the "comparison of random number generators" page
on Wikipedia but "User:Trinitresque" deemed the info not worthy and reverted
the lot, I disagree of course but my day job and other commitments don't allow
time for arguing the toss with Wikipedia editors!]

~~~
Osmium
> Rolling your own random number generator should be considered the same as
> rolling your own crypto: by all means have a play in order to help
> understand the concepts, but unless you are an expert in the relevant
> mathematics+electronics don't every use your own in production.

I'm not sure it's _quite_ as bad as rolling your own crypto. If you have a RNG
you can run it through statistical tests, e.g. NIST's DIEHARD tests. If you
know the physical principles on which your device works, I can't imagine a
scenario where you'd be getting randomly-distributed bits that aren't actually
random. And if you add those bits to your system's entropy pool, rather than
using them directly, then it should be fine. That said, I agree that you still
shouldn't use it in a production environment!

Your suggestion for e.g. the RPi RNG is problematic because (last I checked)
there wasn't information online about how that actually works. For RNGs, I'd
much prefer trusting my own design than a black box which could be outputting
an AES-encoded string of all 0s for all I know!

~~~
mistercow
>That said, I agree that you still shouldn't use it in a production
environment!

I wonder though. There's a possibility that you'll screw something up and miss
it during testing, but I've also seen some scary analyses of expensive off the
shelf RNG hardware.

I'd say that if you're in a position of highly restricted capital that
requires generation of tons and tons of secure random numbers, the ugly truth
is that an open source DIY solution for generating your own entropy
(especially if you can use multiple designs that are separately tested) might
be safer than dumping your limited resources on proprietary unknowns.

------
gonzo
Hrmph.

did one of these in 1993, working with pxn when we were both at Fringeware. It
turned out to be nearly impossible to eliminate a 60Hz signal without going to
pure (D cell) battery power, and a metal chassis.

I'd expect there to be all sorts of harmonics on a USB device.

~~~
alephnil
If this is used as input to a randomness pool and filtered through a hash
function, ideally together with mouse, keyboard and network event timing as in
the linux random device, this should be very hard to break, even with some
biases. I would not have used the output of such a device directly, even if
the output appeared random on statistical tests, just becuase the biases you
mentioned. There will still usually be some randomness in the output, even
when it is biased.

------
DanBC
Hardware random number generators are tricky. This project doesn't appear to
have mentioned any of the tricky parts or how they were tackled. It looks like
a fun project to noodle about with though!

Spotting correlation and skew is interesting. Finding the right balance of
speed and fidelity is tricky.

Here's some previous comment about Entropykey
([https://news.ycombinator.com/item?id=1453299](https://news.ycombinator.com/item?id=1453299))
and here's some stuff about testing and using hardware RNGs that I was reading
a while ago
([https://news.ycombinator.com/item?id=6060636](https://news.ycombinator.com/item?id=6060636))

------
tiatia
I am nearly done building my own. Had a couple of boards etched for me (16
Euro incl. shipping for 4 boards with holes pre drilled) I will lend the
soldering gun from my brother today and build it. Unfortunately I realized I
am short 1 4.kO resistor...

[http://emergent.unpythonic.net/01257868826](http://emergent.unpythonic.net/01257868826)

Too much for you? You can live with security by obscurity? Buy this thing:

[http://www.entropykey.co.uk/](http://www.entropykey.co.uk/)

With both systems you can just feed the noise into /dev/random You should make
some tests from time to time to test reliability. Not sure you can use it with
windows.

~~~
balabaster
Forgive me, I hate to be a pedantic bastard or take away from your message;
but something that's bothered me about a few of my acquaintances since grade
school is their inability to understand the difference between lend and
borrow.

\- If you have something that someone else wishes to use, you lend it to them.

\- If someone else has something that you wish to use, you borrow it from
them.

I don't know why this in particular has bothered me so much, it's just a small
thing. Apologies for any offence, none intended.

~~~
tiatia
You know what? I wrote borrow but changed it to lend. I guess I will never
learn (memorize) it. Something like the difference between schwul und schwül
(gay vs. humid). My English girl friend could never tell which is which and
some days, the weather was gay.

~~~
stanmancan
FWIW borrow was correct in this case

~~~
balabaster
I wasn't trying to be offensive... but rather, helpful. I hope I didn't offend
you by pointing it out.

------
oleganza
How about XOR-ing output from some promising hardware generator with
SHA256(SHA256("user-supplied random nonsense phrase"))? This way we ensure
against both attacks (or backdoors) in hardware and bruteforcing user input.

Generally speaking, if we have 2 to 4 independent sources of random numbers
(/dev/random, user input, external generator, something else), what's the best
way to combine all of them in a single key to ensure that weakness in one of
the? Is XOR enough? Using a cryptographic hash function is not acceptable
because it may have a backdoor (so instead of multiple sources we get back to
trusting only one).

------
chiph
Between the upper & lower limits of it's range (10k, 40k), that looks pretty
random to me. Curious how it responds to temperature changes, though.

~~~
fnordfnordfnord
> Curious how it responds to temperature changes, though.

That's a good point. It is common to use a transistor to measure temperature.
One could control temperature of the 3904 with a peltier if needed.

silicon bandgap temperature sensor
[https://en.wikipedia.org/wiki/Silicon_bandgap_temperature_se...](https://en.wikipedia.org/wiki/Silicon_bandgap_temperature_sensor)

[http://www.sensorsmag.com/sensors/temperature/temperature-
se...](http://www.sensorsmag.com/sensors/temperature/temperature-sensor-tips-
and-tricks-1439)

------
ciderpunx
Kinda like the entropy key from simtec?
[http://www.entropykey.co.uk/](http://www.entropykey.co.uk/)

------
ape4
Just use a lava lamp.

~~~
simias
Or a microphone sampling ambient noise.

~~~
gonzo
Or a CMOS sensor in an otherwise perfectly dark environment.

[http://www.lavarnd.org/news/lavadiff.html](http://www.lavarnd.org/news/lavadiff.html)

------
tiatia
Random numbers and the NSA

[http://www.wired.com/politics/security/commentary/securityma...](http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115)

------
mistercow
Is there a way, without recompiling the kernel or anything like that, to get
this to feed into /dev/urandom's entropy pool so that it can actually be used
effectively?

~~~
mrsteveman1
Yes, there's a kernel interface (an IOCTL called RNDADDENTROPY) specifically
for this purpose, it allows userspace (root user only as far as I know) to
give the kernel random data samples along with an estimate of how much actual
entropy the data contains.

Here's a bit of python code I wrote that could be adapted to do what you're
asking for. It's designed to source random data from smartcards (via PKCS#11
libraries) at the moment but changing the data source to the output of another
program would be trivial:
[https://github.com/infincia/TokenTools/blob/master/token-
rng...](https://github.com/infincia/TokenTools/blob/master/token-rng.py#L142)

There are also a few mature projects designed to do this job (rngd and another
one I cant remember the name of at the moment) that could also probably be
made to work from arbitrary sources if they don't already, but if you wanted
to do-it-yourself on the software side along with the hardware, that python up
there would get you started.

