 Wait for Zane to sit down. Sit down, Zane. Thank you, guys. Hi. My name's Jim. This is Paul. Some of you know who we are for purposes that should make sense. Who we are doesn't actually matter in lots of ways. You need a hearing aid? I'll do this. I'll help you out, right? OK. So we've got a project called 1RNG. It's a small USB connected device, which will basically help you produce random numbers in large quantities for lots of good reasons. You have your own reasons for doing this. So I put a bit of work into it, trying to get a small affordable device. There's been a few of these on the market. There's quite a few people have had to go at these over the years. There's some very good ones. There's a very good one that I was happy to promote a couple of years ago at previous LCA's on similar topics called the Entropy Key, produced in the UK. It is no longer produced. It will not be produced again, sadly. It's a nice device, very cheap. Or you can spend a lot of money on buying a professional device for several hundreds going up into the thousands of dollars. We're not interested in that. We have a small device with a tinfoil hat, because this is for crypto and privacy. You can keep your own tinfoil hats, but we've got one for this device. The tinfoil hat, of course, comes off, so you can find out what's underneath the machine. The reason you do this, of course, is so you can inspect what you've got. We're not expecting anybody to trust a device where you can't open it up and look at what's in it. If you buy something for your own personal crypto security purposes, and it comes in an injection-molded case that can't be opened, and when you do, it's full of epoxy, and all the serial numbers have been scratched off, all right? Really? You're in the wrong game. So what we're doing, okay, we've got a great project name one random number generator, but actually we're not generating random numbers. We're generating entropy, which you then use to generate random numbers with. We use the unpredictability of physics to come back and say, here's an avalanche diode circuit. This, well, if you point your, well, it's a fundamental description I use. If you get the two diodes, you point them back to back where they shouldn't work, and you keep increasing the pressure on them and wait one day, sooner or later, depending on quantum mechanics and temperature effects and stuff like that, suddenly you'll get a pulse out of the circuit. That's about right. You just don't know when. We don't know enough about physics to know when, therefore it's unpredictable. We know we can probably affect it and bias it a little bit. Temperature-related effects will change things, but we still can't actually predict what it's going to do. There's a little bit of a bias in that. So before we go off and you can get access to that data, by the way, or just come through. If you want to read the raw data that's coming off this device, you can read the raw data. Normally, you'll take that data and push it through a hash function to whiten it, so it is better distributed, I think is the way to put it, better distributed and more useful. Now we're using a really, really rotten, old, simple function, the old CRC-16 to do this. We have an AES hardware module inside the chip that we're using. If anybody with three or four letter acronyms wants to ruin your day, that's the part of the machine that they will have ruined, so we don't use it. We don't need it. If we wanted to be a fully-sealed, random number generator of the highest possible quality, then yes, we probably would use that. I think more importantly, we don't know how to trust it, so we can't. We can test a CRC-16, because it's well-behaved over a small state space. Yeah, yeah, cool. So it's in there. It's in the hardware. We haven't written the firmware to use it. You should be free to do so if you want to. Now we've got this stream of data that we've whitened up. We stick it in a pool. We've got about seven-and-a-half K of RAM in there, so we keep mixing new data in there all the time. If you don't use it for some value of theoretical, your entropy pool gets better over time. That's the same. Still can't predict what's in it. You've got a little LED on the board just to reassure you that the machine's working. That LED will not be lit up until the pool is full of good data. We have a halfway state on the light, don't we, Paul? No, it just gets dim when you start taking it out, because it keeps filling up. Right. So if you're pulling data too fast for the machine to keep up, you can visually see that something's gone wrong. That's not terribly important, but it's nice to be reassured that the machine is changing state when you're playing with it. Everything should have a blinky light. That's very simple. By default, what we will do when you get the system, when you implement it the way that we generally recommend, all the data goes straight into DevRandom. We don't intend you to consume this directly. That's fine. It is an additional entropy source for your machine. Your machine's quality of entropy gets better. Of course, DevViewRandom is where you read all your data from if you're on Linux. This thing is completely OS agnostic, because it sits on the USB. Other operating systems have other challenges about how you get your data. But for Linux purposes, unless you're Peter Guttman or somebody like that, you just use DevViewRandom and never use DevRandom. And I'll probably riff on that later on. And there's more. We have another source of entropy on the machine. We have an RF circuit on there. Potentially, I guess, there are more ways an attacker could affect your RF circuitry. It really should not happen in practice. It's theoretically possible. So we just don't switch it on by default, but it's there. But it gives you more options. It lets you mix the two together. Theoretically, the RF circuit makes slightly better noise. But at the same time, it's potentially slightly more open to being compromised. So by default, we turn it off. But we let you turn it on if you want. We can turn them both on. I think there's one of the things that we probably have assumed that I haven't put on the very early slides. This is open hardware and open source, obviously, because we're here at LCA. But we're also expecting people to be able to get involved and change and hack on their own devices. If you don't like the things we've given you, this is the framework to start building more on. So sure, I'll hold that microphone a wee bit higher then. That's cool. So the overall diagram of what's there by default for you to play with is two sources of entropy over on one side. The avalanche diode circuit, which we use by default. The RF receiver, which we don't. I mean, that thing randomly hops, doesn't lock itself into a station, takes the least significant bit of what's available, should be really difficult to compromise. But switch it on if you want to. Goes through a whitening function, which you can choose to not use. So if you want to actually measure the behavior of the avalanche diode circuit over time to make sure that it hasn't become unusable, then just read the raw data for a while to confirm that the device is still operational. And then put the whitening back on and start using its data after you have verified that it's still working the way it was when you bought it. Go into the data pool, pull your results out, roll the dice, win at the casino, whatever it is you want to do. So partly, this is a nice reminder of why we actually want random numbers at all. Computers, of course, are mathematical devices and are perfectly deterministic. The same input conditions should produce the same output every single time. And that's not very good for the sort of people that want the unpredictability, the randomness. And who are they? Cryptography is the easy answer. You need the cryptography parts of your system to be providing you with good quality data, good value work. The more you do encryption, the more entropy you need to consume. There are devices, for example, the Android, which had a very bad random number generator in the operating system. People were using the RNG to do their, I believe it was wallet security on Bitcoin. And as soon as somebody said, Android has a broken random number generator, with this tiny bit of predictability about it, people ended up actually losing their Bitcoin. I didn't say they lost money. I said they lost coins. I'm not entirely sure about the relationship of Bitcoin and money, but random number generators is now actually affecting people for real within the last few months. So it's not just the very paranoid. It's the people who aren't paying enough attention to their machines. The lovely astronomy mini-conference reminded me the standard Wikipedia page as who uses random numbers, cryptography, statistics, gambling, I think there was somebody else, but the science guys, I don't know much about science, right? So I talked to those astronomers at Astronomy Boff and they say, yes, we consume large amounts of random data for our simulations, for our large-scale simulations. So one guy there was doing every single possible variation of stars within the galaxy, and I've got 1,000 galaxies, and not only that, all the stars are going to be binary, so I've got to do every single possible combination of different stars, different combinations and evolve the whole lot. We need a lot of random numbers. He doesn't need them to be security-style randomness. He just needs numbers that aren't going to repeat and aren't going to ruin his simulations by giving the same conditions here and the same conditions there when it should have been different. They're aware of the risks, but hey, they consume a large amount of random numbers. They could do it from the old-fashioned, rand printed book of, here are a million random numbers. That was out in the 60s. Now you do science, you do that science off that and that's perfect. The gaming industry, that's the casinos. If they're found to not be fair, then they lose more money to the government than otherwise. So they try hard to be fair. They probably need these things, but I don't know enough about them, so. Doesn't stop me normally commenting on people, but yeah, so just a quick side on the difference between the hardware, the unpredictable, physical random numbers and your random function in your favorite language. Read the man page and it always says don't use it. And they mean it. If you do use it, you've got to know exactly how and why you're using it. If you knew exactly how and why you're using it, you wouldn't have been reading the man page. So this is the same thing. You're on Linux, go to DevU random every single time. If you know better, then that's fine, but you don't know better. I certainly don't. I'm building random number generators. So yeah, it's cool. Don't use anything else that ever sounds like it might have been unpredictable because pretty much all of these things are at some stage to some attacker predictable and they'll cause you a problem. DevU random, you sit back and say, yes, but my random function is a cryptographically secure. So do you run the number generator or a DRBG distributed random bit generator? It is good and perfect for my needs. Yes, sir, but it is an algorithm. It is deterministic. It is perfect if the value you seeded it with was truly random. That's great. So now you need to have a good source of seeds. Yeah, that's what we do. We're a good source of seeds. The last comment just pops up. If you're deploying a Linux box image from scratch, it has no entropy. You put it in a virtual server where it has no hardware available to it. It has no way of collecting entropy. And then a couple of seconds after it started up, it starts generating its SSH host keys. This is probably the worst possible time for you to be using a value that's going to have the lifetime of the machine in front of it. So if you don't have one RNG or anything else plugged into your machine or any other way of improving your machine status, after the machine is up and started, give it a couple of minutes and then regenerate your long-lived keys. Regenerate your SSH keys. Please don't use the ones that you got by default at the beginning in hardware that doesn't have a good entropy source. And I'd sort of argue at one stage, or I've said this a couple of times before, and I think I was proved wrong by a cryptographer, was why bother using PRNGs at all? If you've got lots of entropy, just use lots of entropy all the time. And it turned out there's a couple of good reasons to do so. One of them is the amount of trust that you put into your random source. If you're going to use it for crypto reasons, trust and verification are very important topics. Get as many sources as possible, mix them together. And the PRNG should be referred to as a CS-pring or the DRBG, which is, this is the thing which mixes the sources together and makes sure that if one of those sources is bad, it doesn't ruin your day for you. So, sorry. I should turn it on, shouldn't I? Well, everyone knows that just because you're paranoid, maybe they're out to get you. We've learned from Snowden that they are in fact out to get us knowledge of that, but they're recording everything we do. And that's honestly scary. One of the reasons I got involved with this was I got really angry about the whole Snowden thing. And I really think that we should be doing more open-source crypto. I mean, we need to own our own crypto at some level. So, there are lots of open-source crypto projects. I'd like to encourage everyone to support as many different ones as you can. Some of them are going to fail, but some of them will succeed and we'll all end up better off. So, don't just support us. Please support other people too. We know there's been some very bad stuff happened. We know that the RSA Secure ID tokens were breached. We know the CA system is kind of... Meh. We don't really know who's running it. The NSA paid RSA to put bad crypto and sell it to all their customers. We know that the dual EC-DRBG that's an open SSL was probably compromised by the NSA. No one knows whether they can trust Redrand on their Intel chip. That doesn't mean it's bad. It just means we don't have a way to know it's not bad. It can't be turned off remotely or something. It's all scary. We also know the NSA will stop laptops as they're being sent to people and mess with them and install stuff on them and then pass them on as if they've not been touched. We've tried very hard to design stuff into this product to make sure that we can tell if someone is tampered with it. There's a whole bunch of other stuff. Does everyone know about the whole Vodafone thing in New Zealand? And I believe Australia? One of the things that Snowden announced was that the NSA had access to... Was the NSA or GCSB? I don't know if it's GCSB. No, it was NSA. It was an NSA document that said they had access to 43% of New Zealand's telephone network. And when some local activists looked back, they discovered that at that date, Vodafone had 43% of the subscribers exactly in the country. They also said they had, I think, some other similar percentage of Australia. And when you look back at about the same date, Vodafone had that same percentage of the Australian. So they can go read my phone. I have a Vodafone phone, a Vodafone SIM card, and I probably should change, but I have no idea who to change to. Who do you trust? We don't know, so we sort of have to take it into our own control. Well, as I said, everything Snowden's told us seems to be true and what Evan said the other day, just made me think, yeah, yes. So how are these fixed? Basically, you either have to push them up or down the stack. They have to require some trust somewhere. And I think in the end, we have to be responsible for our own stuff. We have to may have solutions that are end to end that are not being done in the middle because we can't trust anyone in the middle anymore. Not if some big bad wolf is watching our every bit. And frankly, I want to make it hard for them, even if I have no secrets to keep. So how does it help? Well, we provide you entropy so hopefully your crypto keys are unguessable. One thing about having a random number generator in your kernel is that it continually leaks information about its internal state. So if it doesn't have some genuinely random entropy, entropy source, then it has internal state that is slowly leaking its internal state out to the world. The TCP, your TCP connector, what's the TCP header field? The session IDs, there are some timing information. There's all sorts of information that's slowly leaking out into the world from your system. And theoretically, and I say theoretically because they have a lot more compute power than we do, you're learning something about people's state. So we want to keep stirring more and more random data into the pool that the kernel uses to create data for dev random and dev view random. We also want to make sure that our board is verifiable. So you shouldn't trust this device. You shouldn't trust me to write the good code. You shouldn't trust me to write safe code. You should look at the code that I've shipped. You should compile it and make sure that it makes exactly the same image that I send you. That's exactly the same image that can be obtained from in here. You should also lift the lid and compare the circuit in here with the one that we published that says this is what we shipped you. Just in case what you received wasn't what you shipped, what was shipped. There is an API in here that lets you extract the firmware and it's come signed. So you can tell whether someone's messed with it. So you can extract the firmware. In fact, boot time, it goes out and does a, here we go. Okay. So yeah, so this is how you do the hardware verification. We must have a software. So to do software verification, you basically dump the firmware into a file. You confirm that you got all the data. You validate the GPG signature and the data that's inside it, which is signed, because the actual code base for this is about 6K but there's 256K of flash. We sign the entire thing and we fill it with a fixed random stream. It doesn't have to be a secret random stream so that it can't be compressed. So someone else can't put their own code in there and then deliver up our image. We have a Python script to boot that basically does all that for you. Every time it comes up, it verifies itself. And if it doesn't work, it doesn't turn it on and you get logged. So what does it tell you? It tells you that what you got is what you ordered. It's what we're shipping. Just a warning, we will be shipping other versions that look different, that function the same and we'll document them. And that the firmware is used matches the source and tampering should be detectable. We want to know that there's something in it. If you're doing an open source crypto project, you all need to be thinking about this. You need to make sure people can tell if they've been messed with. Right. So what does one RNG provide under Linux? It provides more entropy. It can provide early entropy if you want to go do the work to do it. We haven't worked hard on that bit yet. If you're doing really independent crypto, you really should be doing this stuff yourself. We provide scripts that start up RNGD, which is the standard Linux kernel demon to feed. If the feeds the kernel. Our scripts are architecture independent, so we're not shipping any binaries that you can't look at. They're Python scripts and shell scripts. You can sit down and read them, which is great because it also means when we package them, we don't actually have to compile anything. Our entire pack, there's just one package. And we don't get involved in your choice of a knit demon because frankly, I can't ship anything these days that includes a knit demon because I don't know which one is running. So we avoid knit demons completely. We have an ID assigned from OpenMoco. If any of you are doing USB development, those guys will happily give you your own USB ID from their range. There is a bit of a chicken and egg situation with them. You have to release your software first before they'll assign it. But of course, to release your firmware, you need to have a USB ID. So you have to release it and then ask them and then fix it up. So I have two or three. One of them is assigned to this. The other one's assigned to the programmer that we're selling for working with it. On insertion, we've got a firmware. So there's a Udev script that starts up. Udev doesn't let you run demons. So it doesn't let you start demons directly. So we use at, at now, to start a demon rather than going through it and an init manager because we don't know which ones are running. And at that point, we go and validate it on removal. When you pull the thing out, we stop the demon and shut everything down. Which brings us to some interesting things. It turns out Udev is pretty broken as far as removing devices is concerned in most, so not most, in some systems. Debbie, in particular, I'm talking about you guys. One of the problems with pulling a device out is that the device won't go away until you've shut down all the apps that have got the devices open, right? And there's a chicken, another chicken and eggy sort of thing where Udev gets a bit confused and doesn't tell you what device it is you pulled out. So you get given a string that's supposed to say TTY, so and so, and it says some bizarre other thing. Red hats seem to have fixed it. The problem is that no one uses Udev scripts to handle removal of devices. It's probably because it's broken. And once you've got this thing in, why the hell would you remove it? You want it, so keep it in. No, no, but you're gonna write good code that does the right thing, that you pull it out and all the apps that are running go away. And when you plug it in again, that starts them back up, well, you can plug in three of them and get three feeders going into the kernel. It scales, because once you get the code working right, I just kind of guess that that part of Udev isn't tested because no one uses it, but no one uses it because it doesn't work. Serial over USB is also problematical. It's a great interface and I've been building lots and lots of devices, but our friend, motor manager, that runs on most of our laptops and our systems wants to go up there and mess with your serial port and do stuff and try and decide whether you're actually running a, whether you plug your cell phone in or not. And this could be a real pain. I believe the newer motor managers that will come out will actually blacklist the entire OpenMoco user ID because it turns out most of them are not cell phones anymore. Yeah, so I plug my phone in, my network works. Yeah, so repeat that for the video, I'm sorry to do anything useful. Yeah, his question was, did the motor manager do anything useful? In my case, yes, it does. It make, when I plug my cell phone and I get my internet connection. Anyway, however, it's a pain. We don't really have a speck of how you should deal with these things and everyone just sort of stomps on everyone else. We've solved it for us by doing some Udev stuff and that's not, well, I could write a custom USB driver, but I wanna use a CDC driver because if I do that, then I work on Macs and I work on Windows and I work on. The solution is not be able to. Yeah, but then you have to write custom drivers everywhere. How do you know it's off just like this? Yeah. I'll switch off to me, right. So I had a nice image in my mind of how I thought the whole random infrastructure on the next worked, which turns out to be wrong. So I spent a bit of time telling everybody to use DevViewRandom, but I still thought DevRandom was needed for something. So I started engaging a few people and I started chatting to Ted Cho, and although I haven't quite finished working out to my personal satisfaction exactly how it works because I'm not sadly qualified to read the source, we've got some nice comments from him. The blocking behavior of DevRandom is basically because when they implemented the char1 as the random bitstream generator, they were not trusting this NSA gifted lump of code. So the DevRandom blocking behavior is a defense against the possibility that char1 was broken. We don't have an indication that char1 is broken for this purpose, but it turns out they did break an algorithm that they wrote and gifted to the rest of the world, so. And that's sort of like the known badness. Yeah, we know we have proof that they are doing things. They're messing with us in ways that we don't have good defenses against. I thought DevRandom was qualitatively different from DevViewRandom. It's not, it's the same thing fundamentally. As long as your machine has got a really good source of entropy in there, they're actually going to be fundamentally identical. So you plug one of these guys in or one of the ones that Keith and Beal are making or one of the other products out there and continue using DevViewRandom, you'll be fine. There are a couple of people who will know better and that becomes their problem now because I don't know enough to explain to them why it's not and they actually may have a really good reason for let's avoid the entire kernel completely because we're using random numbers for some other purpose. I'm thinking of some of the financial crypto people would not bother trusting the operating systems code because they're the mathematicians and they're writing their own stuff. So I had a lot of thought. Yes, you should be using DevViewRandom, but you've got lots of code written from the people who misunderstood the fact that they're the same for the last 20 years and they've written their code to use DevRandom and when DevRandom thinks that there is insufficient entropy in the system, it will not give you any data. It will block and wait. So if you've got a lot of apps that are all talking to DevRandom which they shouldn't be, at the same time you don't have enough entropy, your machine will generally block and wait. So one sort of unproven assertion at the moment is if you have way, way enough entropy coming into your box, perhaps it might run for some value faster. So talk to our friends at Catalyst who are the one of our emperor sponsors for the LCA. We have to keep, rah, rah, they've done a great job here. And a couple of guys in there decided that they're gonna put up a massive big workload of open stack firing off loads and loads of machines all generating their keys, all getting started and time it properly and then time it with our key plugged in the front. It doesn't matter whether it's ours or someone else's. Just to actually give some data to this assertion. So one thing to realize is that DevRandom blocks when it runs out of entropy but DevURandom also takes entropy from the entropy pool and can cause DevRandom to block as a result because basically if there's enough entropy they both work the same. They have different internal data and you'll see different results but both of them will consume entropy if it's present. The only difference is that DevURandom will keep running if there isn't any entropy present and will keep producing data. Yeah, so you can actually cause DevRandom to block by using DevURandom. So basically they're gonna go off and quantify it and publish it and then I'll know on a large scale whether this assertion is true or rubbish and they'll publish it and it has nothing to do with us because it should be independent of us. This is, you know, if I'm wrong I will apologize the next time I'm speaking on this topic and in between on Twitter and email and everything because this whole thing is a learning exercise for me. It's a learning exercise for Paul. We've got core skills that do 70% of it. We don't have the other 30%. We don't need it because this is an open community and other people help us. So thanks to Ted. I still don't understand the rest of his email yet. That's okay. And one of the comment there about sources of entropy. The more sources of entropy you have the better. Linux Kernel does a lot of work to try and collect unpredictable timings in as many places as possible. Well great, you should do the same. If you're gonna plug in a random number generator get more sources as well. If you actually need to have use of your Linux box with lots and lots of entropy in it get more entropy sources, not just one. And there's four other projects currently in various levels of maturity which are current and being loved and looked after. Paul Warren presented his RTL entropy running off software defined radio at the last LCA in the mini comps. B Dale and Keith have got their project which is very, very close to I believe a good release. They'll probably tell us later on. The Venerable Turbid, which is basically a, oh he's got one, he's got one, great. We'll definitely be looking at that later. The Venerable Turbid is a big software based architect. You should read everything about that project because he really goes a very explainable way into the maths, into the reasons, into what you can and can't do. Also at the last step comp was the noisy, random number generator was mentioned. I don't know the guy, but it seems like he's very well known. There's another device. It is not expensive. It is going to be useful to you. So what did we do? We actually ran a Kickstarter and we announced at KiwiCon, and who does product announcements at KiwiCon? What a crazy idea. To our amazement, we got funded in six days. So there's obviously people who think this is important and I want to thank everyone. Well, I know there are people here who've ordered them so I want to thank those guys. And a large part of this, as I said for me, is political. These are what we're offering just to give you an idea of the range of things. We started off with only the top four things, maybe five things. I kept getting people who wanted more and more and Kickstarter won't let you sell more than 10 of anything. So we ended up offering 10 because people really wanted it. This is how we've been funded. We're still open. You can still go and order one. We expect to hit roughly maybe $32,000 which for this project is an awful lot. We're completely amazed by the whole thing. He thinks 400%, I don't think that's true. That was just a real optimistic hit. But as of, we hit $27,000 as of lunchtime. Somebody at lunchtime called Nicholas in New Zealand. Was that you, Nick? Thank you. You've got us over that 27 mark, thank you. Pushed us over the limit. Pushed us over the 27,000. I think we're probably going to do one extra thing to encourage people to build more. I have a design, it's a paper design. The boards are being fabbed as I speak of a one-up version designed to be put internally in servers so you don't have to have it sticking out the back which is kind of a security issue in itself. If you can keep it in the server you've got an extra layer of metal protecting you from being sniffed. And there's one of my colleagues in Wellington who's a small PC builder for small businesses open source all the way. He just came back and said, look, I want it internal. I just want to put one inside every single machine I give to people, whether they ask for it or not. They're just going to get one. So I'm probably going to offer those as an incentive to get us maybe to 35K if we can. One of the goals here is to get this being manufactured in China so we can get the prices down and we can end up selling them long term. So they're not a product like the one from England. Manufactured in China. Pardon? Manufactured in China. Yes. We can't trust them. Well, here's the deal. We're signing everything. We can validate it. Even if they mess with you in China you'll find out. Where I'm actually planning on building a system that will go with them and will program them and will have to talk back to the home office every time it programs one. Sorry, will we keep the option of the New Zealand built ones? We'll have to think about that because I'm building the first run on my pick and place machine at home. But it's hard work. I'd also call back on that and say, why should you trust Paul to build one better than the Chinese when it's not the Chinese or Paul that's going to be compromising the device? Well, no, it could well be the Chinese, to be fair. But probably not the Chinese guys I get to build it, who are great. I just want to shout out, we're waiting to turn the dot camera on. We've got a couple of units in various states of disassembly and not going too well. Let's see how well I can hold that. It hasn't switched. It hasn't switched. Okay, don't worry. You come and have a look at it. There is one item on here which is a dense block of silicon, which is the CPU. This is an old, venerable chip. It's not the best possible unit to use for this sort of thing, except it is old, venerable, and ubiquitous. It's a part that's used in television remotes. So seriously, if you want to mitigate the threat of somebody compromising the Texas Instruments chip that we're using there as a result of what we're doing, number one, they'll have compromised the AES and we're not using it. Don't worry. Go and get an old TV remote control and pull the old chip off it, don't break it, and put it in here and then ask yourself, did the NSA compromise your use of that unit five years before the use was invented? There is only so far you can go with hardware, right? If you want to find out, is that chip actually what it's supposed to be? You can slice it and stick it under the microscope and find out that, yes, it was fine if I hadn't broken it to look at it. So quite apart from that, it's not your hardware, if you don't really own your hardware if you can't hack on it, right? One of the things we're selling as part of the Kickstarter is a programmer. It's a tiny USB thing with a cable. It's kind of expensive. I was explaining before because the cable costs more than the board does. What it means is you can write your own code for it. The firmware is open source. The hardware design is open source. I want you to write your own firmware for it. It's a pain to write. We'll help. And just a good kick on there, of course, one of the reasons that we're using that is so that by default when you get the machine and you've validated the firmware is the right firmware, you can't reprogramming over USB. Yes. That's one of the things that we wanted to mitigate against and it's raised costs and objections at a different part of the project. We do not want the machine to be able to be reprogrammed over the USB from somewhere else. So we chose that route. Other people have different approaches to that problem. That's fine. So anyway, I think we're done. Do we have questions? We're gonna have to pass this one around, right? So the firmware itself is signed. You can verify that. But when you start receiving random numbers, is that signed as well? So the question is, is the stream of random numbers coming over the USB bus signed or in some way encrypted? And the answer is no. And largely it's because the CPU in there is dinky. It's an 8051. It's something with an age like an Apple II. Basically the power of this thing is about an Apple II. It does have an AES unit, but as I said, we can't trust it. So we don't use it. But if you want to program it, go for it. Okay, this might be a complete noob question and I probably should have gone to the Open Hardware MiniConf. You say that your hardware is open and yet I noticed a copyright symbol on the slides. What's the story with that? So in order to GPL something, you have to copyright it. And that's the, simply that. As a rule, my hardware is GPL and the firmware is LGPL. If all you're doing is providing entropy for the kernel, why are you whitening it? I know you can remove it to have a look at it, but why whiten it at all? Sure. And so the data that comes off of the default random number generator, which is an Avalanche diode, is slightly DC biased. And the reason for that is because we could tweak the resistors on every board we build to get it perfect, but then they would cost $1,000 each. We want a $50 board. Something so everyone can have one. RNGD, the demon that feeds the kernel does some analysis and it sort of throws its hands up and says, oh, this doesn't look good. All we do by running it through a CSC doesn't increase the amount of entropy, but it does get rid of the DC bias. There's also a lot of statistical testing on using diehard or another stuff online for people who want to look at the quality of the numbers we're getting. Oh, sorry. I've had some recent experience dealing with supply chains in China and getting fake chips. Have you thought about actually getting a few of the chips which you're gonna get in your bought manufacturing run and actually confirming there what they say they are? Yeah, I'm going to, I've actually had bad experiences with other variants of the 25, 33s where I've got early versions which return the wrong values and stuff. So yeah, I think it's much more a matter of sitting down and spending some personal time with them at the factory when we start manufacturing. The code I have to do programming and setting the firmware up is gonna do that for us anyway. Yeah, sorry, follow on using smaller words so I understand it. The bias in the avalanche output makes the random number part of the kernel think there's less entropy than there actually is. So that's all you're doing is you're removing them. No, no, no, no, it doesn't think there's less entropy than there actually is. There is less entropy because of that but it's seven and a half bits per byte of good entropy and half a bit per byte of bad entropy, right? So that's still way better than no extra entropy. And if I can feed you 500 kilobits per second of entropy, 7.5 bits per byte of good stuff, then that's way more entropy than the kernel can get from anywhere. It's internal stuff which is in the order of bytes per second. Does that answer your question? Okay. It's the rate of what you can produce a unit time. So I'm normally quoting 350 kilobit per second of entropy data. Recently though, I tweaked the firmware and I'm getting about 500. But I'm still quoting 350 because I don't want to. I'd rather be low than be called out for being too high or not being quite right. Just curious about your Kickstarter options. So what's the actual main difference between the manufactured one and the one that you guys are hand making? Oh, so basically in order to try and fund the thing, we weren't sure whether we would have the volumes to go to China. So what we're doing is we're going to basically build, we're talking about bulk manufacturing and a hand-built unit. It's not really hand-built. As I said, I have a pick and place machine. But the idea was we would build some really quickly. If you want some in a couple of months, you pay the premium. If you want to wait until we get the manufacturing chain up and running, then you'll have to wait. And you pay half as much. So that's really all there is to it. So I'm just wondering, once the one RNG is in bulk manufacturing off in China and all the firmware is stable, maybe one HSM as the next project. Actually, the current next project is a USB, not a USB condom, because people already make something like that, but basically a firewall that lets you plug a device in and only passes the descriptors for the thing you want. So if you plug in a random device and someone snuck a keyboard, a fake keyboard controller onto it, and it looks like, and you think you're plugging in a storage drive, we'll have a little thing like that that you can use on your USB that will let you plug it in and only let the parts that pretend to be a short storage drive go through. So it'll only let through the descriptors and only let through the endpoints that are part of the storage drive and won't let people fake out other evil stuff. So that would be the next project, I think. Speeds like 350 kilobyte a second doesn't really mean much to me, I think most people. How does it compare to say that the native entropy generated by a typical Linux PC just using network traffic, for example? I compare to a what? To a typical Linux PC that uses its network traffic and interrupts for... So I believe that you're receiving in the order of bytes per second. Maybe tens of bytes per second of entropy, is that right? So you're saying it's about hundreds of thousands of times faster? Yeah, it's many, many, many times faster. Okay, thanks. Which is why having an imperfect entropy source that's not making 99.999% is great because you just feed all that crap in and just keep stirring the pot in the kernel pool as fast as you can. If you wanna buy a thousand of them, we're gonna have to see what we see in China. It's likely to be down and probably under $20, I'm guessing. But that's purely a number pulled out of nowhere. We'll have to see how that works. Okay, no. So, and he wants to wreck 99% of them. To test, let's go, okay. Randomly. Yeah. Anyone else? No one? Okay, come down and poke at Haber, if you like, if we have time. Yeah. So, thank you for that very interesting presentation.