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.
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.
> 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:
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.
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.
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
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.
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?
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!]
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.
Is "dilute" really what happens? I'm not an expert on this, but my understanding was that you cannot do any harm by feeding predictable data into your entropy pool. The absolute worst case is no improvement over what you had before. In other words, keyboard/mouse/HD/IO/etc. timings plus GPS data is at least no LESS secure than just keyboard/mouse/HD/IO/etc. timings. Is that wrong?
You're correct. You can't dilute it by adding anything to the pool. However if you also increase the amount of entropy that the system thinks is in the pool this can cause issues. The system keeps a log of the amount of entropy that it thinks the pool has. This is reduced when in some cases for example when urandom is used. When the entropy remaining runs out urandom will have to wait for more. You can specifically tell the system "I've added lots of entropy" and then urandom will not stall but may make some not-very-random random numbers. So adding to the pool is a good thing but don't tell the system it has more entropy and don't expect to get random numbers faster.
That is what I meant by "dilute", yes. Not a perfect metaphor, I guess. In point of fact, only /dev/random would be affected by that. /dev/urandom does not stall when it runs out of entropy; it just reuses the entropy in the pool and hopes for the best.
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.
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.
> 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!
>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.
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.
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!
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.
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?
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.
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...
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.
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.
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.
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.
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.
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.
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).
50 comments
[ 0.21 ms ] story [ 135 ms ] threadThat'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...
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]
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.
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)
http://www.lavarnd.org/news/lavadiff.html
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
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?
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!]
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
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.
http://www.wired.com/politics/security/commentary/securityma...
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.
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.
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!
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.
I'm not totally sure as to which algorithms fit this definition but some suggestions might be DSA/ECDSA, Diffie-Hellman, SRP, etc.
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!
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.
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.
- 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.
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.
http://www.wired.com/politics/security/commentary/securityma...
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).