Open Source: Hardware (True) Random Number Generator - Page 1
Forum section: electronics / projects

author: fitnessfan
author_rank: Newbie
timestamp: April 14, 2013, 09:47:45 am
content: Hello,Someone feel like to build an Open Source Hardware (True) Random Number Generator (TRNG)?The goal is that everyone can build a cheap and easy TRNG. It should be connect to the computer by USB.We could do something like the Entropy Key (badly available) does:http://www.entropykey.co.uk/res/download/diagram-explanation.pdfFrom my part, I could provide the driver for Linux (and Mac OS X) which will fill the /dev/urandom, so that the TRNG is independent from the software.What do you think?

author: ivan747
author_rank: Super Contributor
timestamp: April 14, 2013, 06:38:29 pm
content: I like the idea, what I don't like is softwareThe electronic part is simple in principle, but all the tests for randomness and entropy are beyond my knowledge. The most complex math I know at the moment is pre-calculus, as I am finishing school. Good luck on thisBy the way wouldn't open source compromise the security of this random number generator?

author: ddavidebor
author_rank: Super Contributor
timestamp: April 14, 2013, 06:48:33 pm
content: no, a HW random if well build in incredibly casual.only things like temperature can influence it.

author: casper.bang
author_rank: Frequent Contributor
timestamp: April 14, 2013, 07:08:57 pm
content: Quote from: ivan747 on April 14, 2013, 06:38:29 pmNope, but some people/companies will wrongfully claim so - typically practitioners ofSecurity Through Obscurity.QuoteTrue random and incredibly casual is rarely mentioned in the same sentence. While it's easy to investigate the entropy (thanks Shannon), it's quite another matter to prove that a random number generator is truly random and not subject to attacks.

author: NiHaoMike
author_rank: Super Contributor
timestamp: April 15, 2013, 12:10:44 am
content: And with Ivy Bridge and newer CPUs having hardware RNGs on the chip (not to mention RNGs in many chipsets dating as far back as the P3 era), it's becoming less of a reason to make an add on RNG.That said, one easy way is to amplify and digitize thermal noise, XOR it with the previous random number generated (on the first start, just use more digitized noise), then use a cryptographic hash or encryption to whiten it. Should be easy to do on a microcontroller for low rates or a FPGA for fast rates.Things would be a lot simpler if we assume the attacker cannot physically access the hardware (very difficult to properly protect against that).

author: ivan747
author_rank: Super Contributor
timestamp: April 15, 2013, 01:37:41 am
content: Quote from: NiHaoMike on April 15, 2013, 12:10:44 amJust pot the hell out of it and seal it with the nastiest silicone you can find. And use security torx and tri-wing screws on the case.

author: EEVblog
author_rank: Unknown
timestamp: April 15, 2013, 04:27:35 am
content: Quote from: ivan747 on April 14, 2013, 06:38:29 pmAnd that's the trick. If the device is to be taken seriously in the market, which I assume would be the ultimate intention?, thenprovingthat it's truly random to the experts might be the hard part?

author: ddavidebor
author_rank: Super Contributor
timestamp: April 15, 2013, 04:54:21 am
content: Why not a simple open source hardware?No one has here the know-how to certificate this things, but is a nice idea.

author: casper.bang
author_rank: Frequent Contributor
timestamp: April 15, 2013, 06:45:22 am
content: Quote from: ivan747 on April 15, 2013, 01:37:41 amEhhh ok I will suggest that you take a look at what a white-hat hacker like Chris Tarnovskyand then extrapolate that to black-hat hacking and government sponsored hacking.

author: EEVblog
author_rank: Unknown
timestamp: April 15, 2013, 06:49:54 am
content: Quote from: ivan747 on April 15, 2013, 01:37:41 amThe whole point with such a hardware design would be to design it so it having access to the hardware makes no difference.

author: codeboy2k
author_rank: Super Contributor
timestamp: April 15, 2013, 07:51:45 am
content: It would be fun to do this project. At first it seems easy to do, just use the avalanche noise in a transistors PN junction heavily reverse biased... At first it sounds easy enough, but it's not that easy to actually get a true, unbiased stream of 1s and 0s. Theres lots involved, really, and getting it truly random can be hard to achieve.This page has some good info, and there's lots more on his site too:http://www.robertnz.net/hwrng.htmThe test for randomness is not that hard... you have to collect about 10-15 million bytes or so from the device, in a binary file. Then feed that to theDieHardsuite of tests.. it will run a bunch of statistical analysis and give a metric for each test. The DieHard tests are well recognized. But the page I linked above said his testing has shown that it's not sufficient to pass the DieHard tests. There may still be some non-randomness in the generator, or a programming error might cause something that can still pass the tests but has a slight bias still. It's a kinda black art still

author: casper.bang
author_rank: Frequent Contributor
timestamp: April 15, 2013, 08:26:18 am
content: Since you can not actually prove randomness (only show that you are not able to detect patterns and/or bias within a given subset), for the device to be convincing, it would need to base the random seed from several external sources. The popular site random.org uses atmospheric noise, others make use of radioactive decay. If one believes in Heisenberg/Schrodinger/Bohr, the ideal seed would come from the non-deterministic inner world of quantum mechanics, but I reckon only institutes like CERN are able to harvest this potential.

author: BiOzZ
author_rank: Regular Contributor
timestamp: April 15, 2013, 08:31:31 am
content: i have made somthing similar beforethe Q1 and Q2 produce the random numbers and the flipflop (used a different one than shown) stores the data untill the clock sends it backfor me 128khz exactly produced 60-40 randomness ... not perfect but it worked

author: EEVblog
author_rank: Unknown
timestamp: April 15, 2013, 08:31:34 am
content: Quote from: casper.bang on April 15, 2013, 08:26:18 amQuantum mechanics is true whether or not you believe it, just like evolution

author: BiOzZ
author_rank: Regular Contributor
timestamp: April 15, 2013, 08:35:52 am
content: Quote from: EEVblog on April 15, 2013, 08:31:34 amto quote Neil deGrasse Tyson "The good thing about science is that it's true whether or not you believe in it."

author: casper.bang
author_rank: Frequent Contributor
timestamp: April 15, 2013, 08:40:16 am
content: Quote from: EEVblog on April 15, 2013, 08:31:34 amTrue!Unless you're among the40% of Americans who believe in creationism.

author: BiOzZ
author_rank: Regular Contributor
timestamp: April 15, 2013, 08:44:15 am
content: Quote from: casper.bang on April 15, 2013, 08:40:16 amXD "There are 2 things that are infinite, the universe and human stupidity ... and im not sure about the universe!"Eisenstein XPreligion is taking the easy way out of thought in a complicated worldyou dont learn much by taking the easy way outEDIT: than again Eisenstein did not believe in quantum mechanics because it interfeared with his religious beliefs ... ah well science 1 religion 0 XP

author: houdini
author_rank: Regular Contributor
timestamp: April 15, 2013, 10:13:35 am
content: I remember a quote along the lines of "Nature doesn't give a damn about you beliefs" in one of jim william's books i do believe.Also the whole security through obscurity is just silly. If you have ALOT of people looking at it and fixing it there is less likely to be an error. Its like saying windows is secure because its closed source its just not true.

author: casper.bang
author_rank: Frequent Contributor
timestamp: April 15, 2013, 10:48:54 am
content: Quote from: houdini on April 15, 2013, 10:13:35 amI fear though it's more common than we'd like to believe. Just recently while trying to interface with a 3-phase household electricity meter (denied access to the company's "open source" API and "open protocol" documentation and thus having to reverse engineer it), I discovered that the password is just 2 bytes and that it takes no more than 24h to brute force your way into reprogramming it.I'm sure many people on this forums have experienced similar kinds of lousy security, however it's relatively new to me to see this in hardware.

author: ddavidebor
author_rank: Super Contributor
timestamp: April 15, 2013, 11:28:15 am
content: If it work, is safe.Dot.

author: hlavac
author_rank: Frequent Contributor
timestamp: April 15, 2013, 11:39:22 am
content: Problem is USB is ouright hostile towards open source hardware.Thanks to politics of USB-IF that denies compliance to anyone but their little club of companies, demanding lots of money for vendor id registration that nobody but for profit company can justify.They dont want hobbyists and open source projects to use their precious captured market share...

author: c4757p
author_rank: Super Contributor
timestamp: April 15, 2013, 11:47:10 am
content: Quote from: hlavac on April 15, 2013, 11:39:22 amRS two-three-fking-two. Time for a revival. Tell the greedy bastards to bite OSH's shiny metal ass.

author: ddavidebor
author_rank: Super Contributor
timestamp: April 15, 2013, 11:54:57 am
content: Good damn, think about how to generate random number!First the important things!

author: casper.bang
author_rank: Frequent Contributor
timestamp: April 15, 2013, 12:24:52 pm
content: Quote from: ddavidebor on April 15, 2013, 11:54:57 amThat's the easy part, thinking about it no?Occurs to me that the absolute simplest way would be to use a USB camera pointed towards the sky and then hash the pixels once a second and let this be the seed for /dev/random. Nothing is as random as the weather, right? (At least here in Europe where I am!)Or taken a step further: Use an outdated Android phone hanging in a plastic bag outside could be quite a cheap way of trying to achieve true randomness. These are loaded with active sensors like camera, compass, GPS, GSM, 3G, wifi, microphone, gyroscope, acceleration, proximity, temperature etc.

author: 8086
author_rank: Super Contributor
timestamp: April 15, 2013, 12:39:56 pm
content: I made an ADC based random number generator when I designed my random die project. Just a bit of fun...

author: c4757p
author_rank: Super Contributor
timestamp: April 15, 2013, 01:19:15 pm
content: Quote from: ddavidebor on April 15, 2013, 11:54:57 amThat's easy, it's a solved problem. There are established algorithms to whiten noise sources, now all you need is a source of thermal noise, a reverse biased junction or whatever. The rest of it is more interesting.

author: free_electron
author_rank: Super Contributor
timestamp: April 15, 2013, 04:01:41 pm
content: Make two white noise generators by running two zeners in avalanche breakdown mode.Feed noise 1 to an A/d convertor and use noise 2 as the clock for the a/d.You now have random data at random intervals. Doesn't get more random than that...Avalanche noise pushes away 'controllable noise' like, shot noise(current dependent) or thermal or flicker as it is caused by the random electron flow during the avalanching.A few stupid 1n759 zeners and a wideband amplifier do the rest

author: BiOzZ
author_rank: Regular Contributor
timestamp: April 15, 2013, 04:24:43 pm
content: Quote from: c4757p on April 15, 2013, 11:47:10 amSending HID packets is simple and RS232 is dead and fucking stupid ... now TTL UART ... THATS some shit i will jump back in on!

author: c4757p
author_rank: Super Contributor
timestamp: April 15, 2013, 05:15:13 pm
content: That's just 232 with different levels. The reason I said 232 is that most desktops already support it, and adapters are readily available for laptops. If you don't care about ubiquity, then also forget TTL and go with a differential interface like 422/485. Properly designed, you can get impressive speed.Even better, if designed from scratch, the host could be made to work with both diff and TTL levels. But I think an existing system is the way to go, even if a bit harder to use.

author: ddavidebor
author_rank: Super Contributor
timestamp: April 15, 2013, 06:04:28 pm
content: When you have ttl uart you can go with anyone of this ftdi cheap and well documented usb to serial converter

author: BiOzZ
author_rank: Regular Contributor
timestamp: April 15, 2013, 06:28:13 pm
content: I use the FTDI chips when i can ... there are many others that are faster, smaller, exc but the FTDI chip is by far my favoriteand you can bitbang from the thing!

author: firewalker
author_rank: Super Contributor
timestamp: April 15, 2013, 06:47:41 pm
content: Use a radioactive substance+detector to create random event. Is the material found in smoke detectors suitable?Alexander.

author: kfitch42
author_rank: Frequent Contributor
timestamp: April 15, 2013, 07:08:12 pm
content: We could always try something like this:http://en.wikipedia.org/wiki/LavarandI am a software guy (so I might be talking out of my Arse) ... but since these seem to be leveraging analogue-ish stuff, would we have to worry about things like component aging?Diodes (which have been mentioned several times) can fail. If something fails it might not be immediately obvious from looking at the data coming out of the whitener. So, any production level version of this would need some very paranoid firmware. I don't know if I would trust it until I saw how it reacted (in the real world) to a failure. It is always amazing to see what really happens when things fail. It is almost never what you expected.If we are using USB, then any attempt to make it secure against physical access is silly. An attacker with physical access could just replace it with a 'special' version.

author: ve7xen
author_rank: Super Contributor
timestamp: April 15, 2013, 08:41:56 pm
content: Quote from: kfitch42 on April 15, 2013, 07:08:12 pmChallenge / response could work. Then the attacker would need to break into the connected machine (or retrieve the key somehow), which means you've lost anyway. Though with physical access, that's pretty much a given.

author: ddavidebor
author_rank: Super Contributor
timestamp: April 15, 2013, 10:05:42 pm
content: II think diodes are the best solution

author: BiOzZ
author_rank: Regular Contributor
timestamp: April 15, 2013, 10:26:32 pm
content: KEEP IN MIND most computer CPUs have a type of true random number generator ... in my case with the i7 it uses a thermal noise quantum number generator along with a similar 2 transistor method i posted earlier but with a strange fet config and it produces true random number generationif you want hardware it will be moot if you have one of these unless you also include some other encryption tech in the hardware thats software on the PC ... like AES encryption of the random string ...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 15, 2013, 10:38:12 pm
content: Quote from: hlavac on April 15, 2013, 11:39:22 amI think "ambivolent" rather than "hostile". They just don't care enough to make provision for smaller users. These days nobody cares about seeing a USB logo on a product, so strict compliance by using an officially allocated ID is no big deal, and there are several ways round it, like inventing a number, using a dead manufacturer's ID or use theOpenMoko donated allocationIt seems like only the people who see OSHW as a religion get upset about it - everyone else just gets on with it.

author: andersm
author_rank: Super Contributor
timestamp: April 15, 2013, 10:52:37 pm
content: Quote from: kfitch42 on April 15, 2013, 07:08:12 pmIn addition I'd be concerned about immunity to environmental factors. The generator must not exhibit bias depending on heat, humidity, RF interference (intentional or accidental) and so on.For practical use it's hard to beat ICs like Atmel'sATSHA204, but of course you ultimately have to trust the manufacturer which may or may not be a good idea.

author: codeboy2k
author_rank: Super Contributor
timestamp: April 16, 2013, 03:51:19 am
content: Quote from: andersm on April 15, 2013, 10:52:37 pmDue to those environmental factors, and even others that you didn't name, there will always be some bias in the output. You always need to de-bias and de-correlate the bit stream (this is calledwhitening)Here's a thought... create multiple bit streams. Use different physical processes, for example, avalanche noise, thermal noise, shot noise, etc. Whiten each stream. Mix two of them (from different processes), use that to seed a crypto-PRNG, mix that PRNG's output with a 4th stream, clocked by a 5th stream. Do that all in a small FPGA (except the noise sources).Finally, as a last measure, collect the output stream one bit at a time into RAM, and run statistical analysis on it. if it fails any randomness tests then discard that block and keep going.Serve USB requests for smaller blocks of random bits carved up from RAM data that passed the test, while building up another area of RAM for testing next. How much RAM would a small USB device need to accomplish this? Would flash be better ?? maybe FeRAM ?? whatever is used, it would need to be inter-leaved memory so that we can a pull a word at a time out of the memory array for the USB controller to send out. There is still many unanswered questions, but those are my thoughts so far.Even after all this, is it truly random?? we'll never know.

author: free_electron
author_rank: Super Contributor
timestamp: April 16, 2013, 04:41:32 am
content: Quote from: kfitch42 on April 15, 2013, 07:08:12 pmAnything can fail. But adding a sanity tester is trivial. The zeners will only avalange in a certain current range. Simply look at the voltage drop across them. If the voltage drops below zener level the diode is fried. Is it goes far above zener level the diode failed 'open'There you. Add an or gate and you have a 'avalanche fail' detector.To make the usb u it more tamper proof :The ftdi chips have an unalterable serial number. Read it , encrypt it and store it in. A TPM.Verify during run.

author: codeboy2k
author_rank: Super Contributor
timestamp: April 16, 2013, 05:00:01 am
content: Quote from: free_electron on April 16, 2013, 04:41:32 amcould do it this way yes.QuoteVerify during running is the key, and will even catch the failed open/short diode. There is at least one commercial hardware RNG (TRNG) on the market does block-level statistical analysis as I described. If the statistical analysis fails N times in a row, where N is 2 or 3 usually, then the devices shuts down and fails to serve bits anymore.Another device has two CPUs cross checking the random stream produced by the other one. Failing statistic analysis twice in a row shuts it down. Failing a block that the other CPU has passed will shut it down. Theres other tests too, but I can't remember since I read it long long ago..

author: westfw
author_rank: Super Contributor
timestamp: April 16, 2013, 05:10:38 am
content: QuoteSo I've often wondered; is the reverse biased junction thing "random enough" that you can throw a bunch of them (say, 128) onto an IC die and generate lots of randomness in parallel? You can combine ("mix") them (assuming each one generates some sort of bit stream) using the same sort of HW encryption algorithms that are in common use, which ought to make a lot of crypto people reasonably happy.)

author: NiHaoMike
author_rank: Super Contributor
timestamp: April 16, 2013, 05:17:38 am
content: Doesn't Bitcoin use SHA256 hashes? Maybe some obsolete Bitcoin hardware would work great as a "whitener" for a RNG...

author: ddavidebor
author_rank: Super Contributor
timestamp: April 16, 2013, 05:20:49 am
content: So random that 1 is enought.But the idea someone here had sad to use one for time and one for values of fantastic!

author: codeboy2k
author_rank: Super Contributor
timestamp: April 16, 2013, 05:48:40 am
content: Quote from: westfw on April 16, 2013, 05:10:38 amI'm no crypto expert, but there is some benefit to mixing more than 1 stream, yes. no matter what, each stream needs to be de-biased and de-correlated, and streams are mixed with other streams, and mixed with LFSR or a crypto-PRNG to do this. And you need a few streams to accomplish this. In the end you have 1 stream from 2 or 3 source streams. And it's been slowed down. So you could, in theory make a 256 bit very fast TRNG by combining 768 (or more) streams to make 256 individual streams that are used in parallel to make a single 256 bit wide stream; But I wouldn't use all zeners, it needs too much power. Probably a mix of zeners (avalanche noise) and resistors (thermal noise - see re: Intel below)Quote from: ddavidebor on April 16, 2013, 05:20:49 am1 is enough, but has too much bias and correlation to nearby events. So often more than 1 is used to try to de-correlate the stream. The goal is to have one truly random stream that is not dependent upon (i.e. can not be correlated to) something in the environment (temperature, radio waves, vibrations, voltage (50/60hz... nice and periodic)... etc.QuoteIt's common, I'd even say it's necessary, to use more than 1 stream. Intel produced a TRNG from 2 noise sources, one for data, one for values, and put it on the CPU silicon. Both streams measure and amplify thermal noise from unpowered resistors placed on the die in two different places of the die, and and rotated 90 degrees. It uses the first stream as the data stream, and the other stream as a frequency control input to a low frequency VFO. The VFO, now as a frequency changing clock, is used to latch bits from the main data stream. The VFO is about 10 times slower in frequency than the main stream, so it randomly samples about 1 out of every 10 bits from the main stream. Could be 10, could be 11, could be 9, etc. the sample point randomly deviates.

author: alank2
author_rank: Super Contributor
timestamp: April 07, 2017, 05:08:43 pm
content: Quote from: andersm on April 15, 2013, 10:52:37 pmI was thinking of using the ATSHA204 as a TRNG, but one thing has me wondering. The data sheet says:Random numbers are generated from a combination of the output of a hardware RNG and an internal seedvalue, which is not externally accessible. The internal seed is stored in the EEPROM, and is normally updatedonce after every power-up or sleep/wake cycle. After the update, this seed value is retained in SRAM registerswithin the device that are invalidated if the device enters sleep mode or the power is removed....The ATSHA204A can generate high-quality random numbers and employ them for any purpose, including aspart of the crypto protocols of this device. Because each 32-byte (256-bit) random number is not dependent onpast numbers generated on this or any other device, their inclusion in the protocol calculation ensures thatreplay attacks (i.e. re-transmitting a previously successful transaction) always fail.What is the point of the internal seed value?