USB Random Number Generator

http://jayakody2000lk.blogspot.com/2013/09/usb-random-number-generator.html

46 49 13 years ago

jayakody2000lk.blogspot.com

chiph• 13 years ago

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• 13 years ago

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

http://www.sensorsmag.com/sensors/temperature/temperature-se...

jaseg2• 13 years ago

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... 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• 13 years ago

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

jaseg2• 13 years ago

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

zokier• 13 years ago

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.

This sentence reminded me of the recent revelation of some smartcards:

http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in...

Afaik the failure was exactly that there was insufficient HW failure detection.

edit:

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 this reminds me of another anecdote. In math/stats class teacher told us of a experiment where two people were to write a 100 digit random sequence of 0s and 1s on a paper. One person was to use a coin flip, an the other was to just make the bits up. Then the person administering the experiment would take the sequences and guess which one was true random (coin flipped) and which one was human-generated. The trick being that humans tend to avoid repetition, and the one with (iirc) 6 consecutive 0s or 1s was most likely true random.

DanBC2• 13 years ago

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

ape42• 13 years ago

Just use a lava lamp.

simias• 13 years ago

Or a microphone sampling ambient noise.

GotAnyMegadeth• 13 years ago

As long as the physical location of your microphone is secure...

gonzo2• 13 years ago

Or a CMOS sensor in an otherwise perfectly dark environment.

http://www.lavarnd.org/news/lavadiff.html

ape42• 13 years ago

How about a camera looking at the sky/weather. That's pretty random. (The attacker would have to float a blimp over your office ;))

stephengillie• 13 years ago

How about this:

1. a die (D6, D20, etc) enclosed in a clear dome with a base that will pop and cause it to fly into the air and land. The base would ideally be made to pop electronically, maybe by a servo

2. a camera directly overhead the die which feeds into a computing device

3. OCR software that receives the camera input and outputs the number on the die

oakwhiz2• 13 years ago

While Boggle sounds like an interesting method of generating random numbers, I think that a better way would just be to whiten the "random pulse train" output from a Geiger counter next to a weakly radioactive sample and send the resulting numbers over a serial link.

DanBC2• 13 years ago

That would be very slow source of random numbers.

I wonder how well it would last over time? Assuming a normal (not precision casino) die, bought off the shelf from a high street store - would you be able to see any pattern in 1 million rolls? Would deformation of the popping base affect randomness at all?

How about a webcam sampling "snow" from an untuned TV?

dspillett2• 13 years ago

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!]

dbaupp• 13 years ago

The RDRAND instruction on the Intel chips has been a source of much uproar recently. (Concerns that it has been back-doored by the NSA, etc.)

raverbashing• 13 years ago

Rolling your own random number generator should be considered the same as rolling your own crypto

Yes. However, running your own entropy generator looks ok to me (which is then fed to a random number generator)

Unless your entropy generator is only generating "nothing" this shouldn't be a problem beyond possible attacks to reading of the data

mistercow6• 13 years ago

That's not quite true, but I think it should hold for this in particular. Some other counterexamples besides "nothing" would be if it generated a regular pattern like "101010101" or if it picked up some kind of mostly predictable input, like a radio station or GPS data. You definitely don't want to dilute your entropy pool with something that can be predicted.

tiatia5• 13 years ago

"For those wanting a cheap HWRNG, a growing number of CPUs include them now."

Sure they do. I just read a paper how you could make a bias to this hwrng. I think it was even here on HN.

dspillett2• 13 years ago

Any chance of a link? It doesn't come up after a cursory search and that would most probably be an interesting read.

mistercow6• 13 years ago

You certainly shouldn't use its output directly, but as I understand it, if you were to push the output into the OS's entropy pool, it will get automatically whitened, combined with other entropy, and fed into something like Yarrow.

The end result should almost certainly be at least as secure as the default entropy sources of keyboard timing, hard drive read/write latency, etc. If you're using a lot of random numbers, then /dev/urandom would become far more secure, and /dev/random would become far faster, since the entropy pool wouldn't drain as quickly.

nwh• 13 years ago

That's just it really. On its own ou wouldn't trust it, but mixed in with /dev/random can't hurt. XOR random bytes with a constant stream and it's still just as random.

Osmium• 13 years ago

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!

mistercow6• 13 years ago

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.

oakwhiz2• 13 years ago

Many crypto algorithms depend on good random numbers. Even if generating a key using a poor RNG is not a problem, some protocols create nonces which must be randomly selected or the security of the algorithm is greatly compromised.

I'm not totally sure as to which algorithms fit this definition but some suggestions might be DSA/ECDSA, Diffie-Hellman, SRP, etc.

balabaster4• 13 years ago

You know what? I'll take an open source/open hardware implementation of that over a closed source CPU implementation that the NSA may have had their hands in.

In this sense, rolling your own is a good start. It may not be a perfect implementation yet, this version may not even be secure but the fact that someone is making a start on an open source/open hardware version is commendable.

I hope this initiative pans out to something great!

ademarre• 13 years ago

You're the one that added that bit about the Raspberry Pi to the RNG comparison page on Wikipedia? Thanks for the tip! That helped me with a project I was working on at the time. I've since learned that there is also a HW RNG on the AM335x that comes on the BeagleBone Black.

mistercow6• 13 years ago

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• 13 years ago

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

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.

tiatia5• 13 years ago

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

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

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.

balabaster4• 13 years ago

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.

tiatia5• 13 years ago

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.

gonzo2• 13 years ago

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.

tlarkworthy• 13 years ago

My USB microphone agrees

mistercow6• 13 years ago

Atmel has an MC you can get for about 4 bucks that does AES encryption onboard, and if you pushed the data through that, the harmonics wouldn't matter.

alephnil• 13 years ago

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.

tiatia5• 13 years ago

Random numbers and the NSA

http://www.wired.com/politics/security/commentary/securityma...

oleganza• 13 years ago

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

ciderpunx• 13 years ago

Kinda like the entropy key from simtec? http://www.entropykey.co.uk/

USB Random Number Generator

Related Stories