 So, I'm here to try and tell you how to build a quantum true random number generator in the next 20 minutes. So, you're going to have to forgive me for speaking quickly. Now, before we begin, we have to start with a description of what true randomness is. And the take home lesson is that true random data is unpredictable. And what this means is that if you have any amount of true random data, an arbitrary amount of processing power and time, and perfect knowledge of how it was generated, you cannot predict the next bit with better than chance. And to meet this gold standard, your data has to be unbiased and not produced by an algorithm. And most of you probably know that computers use algorithms to generate pseudo random numbers. What some of you might not know is that even numbers that you generate in your head do not meet the standard. These numbers are interesting because they're useful for cryptography, scientific applications, and drinking games. So, if you wanted random numbers, you have two basic approaches you can take. You can use a pseudo random number generator, which uses an initial secret starting condition, and an algorithm to generate a deterministic sequence of numbers, which is considered for most applications a good enough approximation to the random distribution to be used for many purposes. Or you can use a true random number generator, which is almost wrong to say that they generate random numbers. What they really do is they sample random numbers by taking a chaotic physical system and measuring variation in that system and then using that to generate the numbers. No matter what you do, it is very easy to make a mistake in your design and very hard to find it, so you have to always doubt yourself at every step. Now, among true random number generators, there are two sorts. I'm going to start by describing non-quantum true random number generators. These sample a complex and chaotic system. I use chaos and entropy interchangeably, and use that measured entropy to generate random numbers. Now, these are not that hard to design if you think very carefully. For instance, you can use minor differences in user input timing. You can sample air pressure or temperature over very small time scales. But fundamentally, what you're doing is you're sampling a system that has a lot of inputs, and you have to ask yourself whether the complexity of the output is the same thing or as good as random output. Because since you have many inputs, it's very difficult to prove what all of them are, let alone whether some of them are defined by an algorithm or biased in some way. And if you have a quantum true random number generator, the main difference is that you've sampled a very simple system of high entropy, such as the behavior of single particles or photons. Now, this is interesting specifically for a sealed radioactive source because it has no inputs and still has outputs, and that's great because it makes it very difficult to attack. Now, these type of sources you typically end up with low bandwidth because you don't like dealing with things that emit a lot of radiation. And it's also very difficult to detect subatomic particles or single photons using equipment that you have around your house. However, if you overcome these obstacles, the output should be truly random, and I say should because there's a lot of mistakes you might make, and I'm going to go over a couple of these. The first most tempting mistake to make is to use more than one detector for your entropy source and have one of the detectors output zeros and the other one output ones. Now, on paper this is nice, but in practice the detection efficiency of your detectors and where they are located relative to the source will make it such that one of them is going to be more likely to detect things than the other. So you will have some sort of bias involved. And the person who came up with this method also described a correct method of doing that. I should just say it because this paper was very nice. The second mistake to make, which is probably worse, is to use a counter on some microcontroller or computer and then use the particle detector or a particle detector I should say as a CPU interrupt and then it outputs whatever number the counter is at. Now the problem with that is that when you deal with particle detection statistics the time between detections is defined not by a random distribution but by a Poisson distribution. And this means that there's some average value of time between the particle detection events which is more likely than other times. So the numbers you output, the difference between them is defined by a Poisson distribution which is very bad. Now the last thing you should not try to do is try to calculate the expected time between particle detection events because it's going to vary over time and you don't know exactly how many atoms there are and you don't know your detector efficiency with absolute precision. So not only will you have a bias, you will no longer know what it is. Now our design doesn't have that many groundbreaking developments. It has two things which are very convenient however. It has a solid state particle detector, so let's use sane voltages. It's much easier to deal with than vacuum tubes, like Geiger-Muller tubes I should say. And secondly it has a dedicated microcontroller that does the sampling so you don't have to worry about complex timing issues in a multi-tasking operating system you might connect this to. So you just plug it in, sample it and it works fine. This is a circuit diagram which you may not be able to see very well. Basically the first part to the left is the primary detector circuit which I'll describe more later. It has to be enclosed in a Faraday cage to block out external noise which would completely drown out the signal otherwise. Then you have two more operational amplifiers that make the signal a usable voltage. There is a potentiometer that compensates for DC bias. However this is a bad design decision and I regret doing it. However it does work. Finally you have pulse shaping and sampling stages afterwards. Now the circuits I made are a flex PCB because it's great for rapid prototyping and I've included here a couple of nice pictures of some boards just because they're very pretty. Now the core of the particle detector is a pin photo diode and this is like a small solar panel. If you apply something of enough energy to one end you knock loose a few electrons and you could detect this as a voltage difference between the two ends. So use a differential, what's called a transimpedance amplifier which is basically an op amp to amplify that difference to a usable signal which you can see as an oscilloscopes trace on the stream. You have a spike and then a logarithmic decay. There we go. Afterwards when you have this usable voltage you do a little bit of pulse shaping to make it easier to sample and for this I just use a Schmidt trigger hex inverter. So you see that when there's a spike which would be hard for the microcontroller to catch it translates into a bit bigger logic pulse. And I have a nicer, this is what it looks like on a bigger sample. It's very pretty. Now the sampling algorithm is where things get, you have to pay more attention. Basically what it does here is it measures the time between two particle detection events and then it does that again. So you have two times between particle detection events and you compare them together. And if the first time is larger you output a one. If the second time is larger you output a zero. I didn't come up with this myself. Several other people have done this before. It works very well and the reason is the time between particle detection events is defined by a Poisson distribution but the time between two particle detection events have a very, very similar Poisson distribution so you can compare the two to get a nice random distribution. The demonstration won't be happening because the microcontroller died on its journey here. However if you'd like to play with the detector later that will be possible. Now once you have output you need to analyze it otherwise you might find out that it's meaningless and you start by creating basic frequency charts to make sure you have no missing numbers and you can also try to recreate the binomial distribution by plotting the frequency of averages of sets of numbers. And while doing these things you have to keep in mind that proving randomness is impossible using traditional hypothesis testing statistics. What you're really doing is looking for problems that you expect to have and then fixing them if they come up. This is a frequency chart for the first 60,000 random numbers generated with the generator and we didn't see anything unexpected. Then I took 10,000 means of six digits and graphed them and we get approximately the binomial distribution so everything seems to be working fine in terms of simple distributional problems. So I subjected it to a more advanced analysis using the NIST test suite 2.0 which is very nice and well documented and easy to use I should add. And I subjected 100 megabits of random number generator output to these tests with an alpha value of 0.01 which we'll get to later. Although I couldn't get the last test working the 188th test so I just sort of ignored that. Now the thing about alpha values is when you're talking about hypothesis testing statistics it's the chance of random data let me start that one over because it's an important point. If you have an alpha value of 0.01 it means there's a 1% chance of in this case true random data failing that particular test for non-randomness and so you actually have an expected failure rate for random data and so given 187 tests run 100 times on one megabit each we expect 187 failures and we observe 205 which is not a significantly different number so things seem to be okay on that point but much more importantly the failures didn't cluster on any specific test so there seems to be no specific problem with the output as measured by this test suite. Now I was originally going to talk about this a bit more but I only found out recently that the people from NIST are actually just down the hall and they have a really cool system that's a bit better than this and if you haven't seen it yet you must go it's really neat however I still think there's a possibility for hobbyists to build a quantum true random number generator based on single photon detection using photomultiplier tubes which unfortunately are vacuum tubes so they, well, okay, slash fortunately if you like that sort of thing but it requires high voltages and some tricky electronics but you should be able to detect single photons with an efficiency of about 30% if you choose your tube carefully and other advantages are that you can increase the bandwidth drastically the bandwidth of the device I built if you tune it well is about 75 bytes per second the one they have in the room a couple of doors down is 6.2 orders of magnitude faster so this is a very attractive method it's more expensive though alright well finally I'd like to thank I'm from Fulab, the Montreal Hacker Space and I'd like to thank them for providing a space to work in and friends to work with and finally my friend there, Fx who helped me design a driver for the true random number generator as well as some data management scripts that saved me many hours of work if you want to make one of these yourself I'm trying to make a board that is suited to experimenting with this sort of thing so I'm going to try to make it available or at least information about it available at this website within about a month yeah it is blue on black, that's very unfortunate I thought it would look better, it doesn't it should say LegionHeavyIndustries.com but the presentation is available for download my references are similarly difficult to see but they're very interesting and you should go check them out and it's of entertainment specifically the photodiode data sheet is particularly interesting thank you very much and for the remainder of the time left I'll field any questions until they kick me out yes, over there oops, could you speak up just a little bit are you asking whether I can't quite, can you speak up a bit more he's asking whether when detecting single photons you would have problems with electronic interference from nearby devices and yes you would but you actually have even more complicated problems when you deal with detecting single photons because there's a background noise that you can't eliminate which I don't understand very well but at the very least you'd have to build everything in a faraday cage again yes, over there oh, okay, I thought somebody might ask that would you like to guess I have no idea okay, it's the AMRA-C241 from a smoke detector yeah, it's no special license required yes, over there oh, thank you do we have any other questions okay, well if anybody would like to join me to play with the particle detector which does work I will meet you outside this room and we'll find somewhere we can sit down I brought my oscilloscope what does it look like the next one it's on your map good excellent