 Thank you all very much for coming. This is the talk, Security Not by Chance, the Altus Metrum Hardware Random Number Generator. I'm Tom Marble, and some of you may know me. I want to say it's great to be back at DebConf. I missed last year, unfortunately. I'm really happy to be back. Informatik is my company. And today, I'm going to talk about random number generation, in fact, specifically a project that we're calling USB TRNG, TRNG for true random number generation. So these are the things that I want to talk to you about today, give you a sense of what we're thinking. First of all, why do we care? Why do we care about randomness? What's the point? How does this apply to GNU Linux? A little bit about the design that we've got with Altus Metrum for this hardware random number generator, ways that we can measure its quality and effectiveness, and then think about where we're going, where the next steps could be. And that's where we're hoping to get some good questions from you and get some good feedback. For those of you that may be on the stream, you can join us at debconf-room329. And hopefully, somebody's on IRC and keeping an eye on questions that might come in. We're glad to take those. And I just want to shout out to the Debian video team. I think it's really awesome that we can livestream all of the talks. So why do we care? Random numbers are actually a really important component of security. Random numbers are used to make encryption keys you may have noticed when you generate your GPG key. It takes a while because the system needs to have enough entropy to create a random key for you. More frequently, whenever you use SSL, you go to an HTTPS website. There is a unique session key that is created between your browser and the server, which is used to encrypt the session using a traditional cipher. But that password, that session key is actually coming from the random number generator. And if we can guess what it is, that's going to compromise security. And of course, randomness is used in a lot of other places in the kernel and elsewhere for security applications. So it actually ends up being an important element of security overall. And I think that we all know that security is becoming increasingly important in everything that we do. Just a little bit of background on random number generation. Typically, there are two different kinds that we need to talk about or talk about how TRNG is different from PRNG. PRNG refers to pseudo random number generators, which are basically varieties of algorithms that take a certain seed or input and then have a formula for generating a sequence of bits, which to as much of a statistical measure as possible appear like the random, but they're not actually random. If I start a PRNG with the exact same seed, I will get the exact same sequence of numbers out of it. Sometimes that's really helpful. For example, if you're testing software and you want to test different elements of software, you may want to have something that is sort of random, but that regression tests can catch any changes in the output. In that case, a PRNG is perfect for that. You might argue that there are other kinds of testing that would be a little bit more dynamic, like generative testing or property-based testing, which might be better. But there are some good uses for PRNGs, and in particular, they're fast. So we can get a reasonably random number from a PRNG quite quickly. Getting true entropy or randomness requires a hardware random number generator, because what we're really looking for is to get randomness that's based on some physical process, some brownie in motion, some source of variability that is not at all deterministic, that could not be anticipated or guessed by any other means. Many of you may be familiar with DevRandom in the Linux. Kernel, which will block until the kernel has made an assessment that there's actually enough entropy to release more bits. So what are the risks involved with random numbers? As I mentioned, session keys are created with random numbers often. So the significance of this is even if we have a fantastic public key infrastructure in RSA keys, instead of having to break an RSA key, a 4K RSA key, if all someone has to do is guess your session key, they could decrypt your traffic, potentially. So again, as you all know, security is often dominated by the weakest possible link. And what we're doing here is we're trying to shore up the randomness as one of the potential vulnerabilities in our security. So there was an interesting post by Greg K.H. earlier this year, which is pointing to a blog post by Thomas about myths about your random. And this is important because if Greg K.H. says something, people are going to pay attention and they're going to listen. So in this blog post, Hune is talking about how people are rallying against Dev your random, which is the pseudorandom number generator, if you will, in the kernel. It's often used in many Linux applications because it does not block. It's often seeded from DevRandom, but it is actually a sequence of pseudorandom numbers that are provided for you for the kernel. It doesn't block. It's very fast. The downside is it has all of the downsides that could come with a pseudorandom number. And so people were debating about the differences between DevRandom, which blocks, until the kernel makes a determination there's enough entropy or not. So it's a very interesting post, and there are a lot of good points that come out on it. But the thing I wanted to tell you, the thing you should take away is that the entire argument is predicated on this one comment. And that is that the outcome or the security is depending upon having enough randomness or entropy at the beginning. Maybe 256 bits is enough. So let's think about that. Do we know that we have enough randomness at the beginning? What if we don't? What if we don't have enough randomness in the beginning? I want to share with you an interesting research paper from the University of Michigan and other sources. Heinegger have a great paper on weaknesses in security specifically due to weaknesses in randomness. This is specifically talking about the weaknesses of DevRandom. And in this paper, they talk about the existence of a boot-time entropy hole that leaves systems vulnerable, especially in headless and embedded devices. So let's think about all the servers that are running web services on the web that you maintain probably fall into this category, especially if they're in the cloud. I won't go into all the details of this paper. It's really interesting. I'd highly recommend that you read it. And I will make my slides available so you don't have to jot down URLs or anything. In the paper, they examine over 10 million sites and they found by just doing simple scanning that there were a lot of duplicates and keys that were available on the net. And the short takeaway is that there are many keys that they found to be vulnerable due to a lack of randomness. And this includes SSH keys and RSA keys. So this is the picture that I want to show you. This is the entropy loophole. In this example, in this graph, what you see is time from boot. Going from zero to 70 seconds and you have different events that are happening. This line here is the actual entropy that is coming, is being collected by the kernel in dev random. This line here is 192 bits. The kernel will not release bits out of dev random until there's this threshold of randomness. This crossing of the threshold happens in this study at 66 seconds. But let's look at what happens before 66 seconds after boot. This dotted line is the amount of bytes that are coming out of dev u random since boot, the pseudorandom number generator. And the event that you should really care about happens here at four seconds. What happens then? SSH uses dev u random to seed its own internal key generation. So what this means is that SSH doesn't actually have enough entropy at four seconds to have a completely unpredictable set of keys. So this is a concern. I wanted to put this note in here and this is mainly for when you review the slides later. This paper is interesting because what it says is the kernel's estimate of entropy is actually fairly conservative and it's pretty good. So we can use that. But this problem of random number generation and security has been discussed quite a bit at South by Southwest. Edward Snowden made this comment which was picked up by Matthew Green who you might know as a cryptography researcher at Johns Hopkins. And after this tweet, Green goes on to make a blog post and I have the URL. Don't try to write it down, you can get it from the slides. How do you know if a random number generator is working? And it's a great blog post because it highlights a lot of the challenges that we've got in security related to random numbers. One of the things that I learned which I thought was interesting is that Intel's Ivy Bridge randomness actually gives you bits that are the output of a pseudo random number generation process, not the entropy directly. So there's a concern about that. But what Green does is he talks about statistical tests that we can use to measure if something is actually random enough. It's a very hard problem. Related to this, and in a separate blog post, Green also talks about something I'm sure you're familiar with, those of you that are in security, is the use of the dual ECDRBG random number generator that has became a NIST proposal. For those that aren't familiar, this was an elliptic curve-based random number generator that was proposed by NIST as a standard and found to have potential backdoors based on the way elliptic curves work. And curiously, the NSA paid RSA security a million dollars to make dual ECDRBG the default RNG and all of RSA's security products. So this at least should raise a question in our minds about the Cypher suites and the random number generators in particular that we're using when we're generating security-related material. So now after hearing this, would you like some entropy? Yeah. Well, we've got some challenges with TRNGs. They can be expensive. They can be out of stock. They can be based on close designs. Many of you I know are aware of the SIMTEC entropy key. And this is one of the early places that I went to. Yeah, right. Sorry. Well, so I mean, I had to put this, this is on the website. So I had to put this up that we don't have any at stock and we don't know and we'll have more. I actually have about four, but you can't have them. Well, that's the problem. So that's why we're here. And I don't know if Nibé is here in the audience. There he is. But he contacted me and let me know that he's working on a project. Maybe he can say some words about his RNG later. But there's a nice website there, not all in Japanese. So there's some stuff in English there too. And a very important Madeleine called to my attention that at LCA, I believe was earlier this year. I think it was at least a year ago. Maybe it was a year ago. So maybe I've got the year wrong. No, no, it was this year. It was this year? Yeah. Okay. All right. There was a discussion of RTL entropy, which is really interesting using a DVB dongle with software defined radio to use radio as a source of entropy. And so I think it's an interesting approach. And one of the things that I said in talking with my friends about this is that one thing that we could do and should do is when we have good sources of randomness that we can really trust, we ought to have secure ways of mixing the sources together because that actually makes the quality of the randomness increase. And there are cryptographic ways of doing that. It's fairly straightforward. So do we want more entropy? Yes, we do. So why do we want to go and make yet another hardware product? Well, because it's fun, because we can. So I was thinking about this and thinking who do I know that does hardware and software believes in freedom. So I was thinking of our friends at Altus Metrum that do some really cool hardware designs, open hardware designs with free software and fly them in rockets. And they actually got me excited in doing this and I'm going to be flying this in a rocket this weekend. So I'm very excited about it. And so I talked to my friends at Altus Metrum and then learned that they have actually a lot of experience in this. I tried to count and I don't know exactly how many open hardware designs there are, but at least over 15 on many different architectures and a marvelously free real-time operating system with some really neat features that's actually very easy to understand and program. So let me introduce to you B. Delgarby and Keith Packard who are my friends at Altus Metrum and that I'm partnering with to do USB TRNG. So a little bit about the design. I'd say NXP Cortex-M0, typical USB key based on the bandgap voltage reference. There's noise amplification and we can have B. Delgarby say a few more words about the design at some point. It's boring. Oh, this didn't show up so well. This is the schematic which is all available on the Altus Metrum website and this is the interesting part with the diode and the op-amps and stuff and going in. The rest is classic. Is that only one noise generator? The first, is this on? Test one, two, three, four, five, okay. The first hardware prototype has a single noise generator and it is afflicted with low frequency noise injected through the power supply that needs to be dealt with which is part of the reason I'm not like handing out samples to folks to play with this weekend. There was a point in history where we thought the right thing to do is to arrive with enough of these to just hand them out to everybody but well, life intruded. That's the interesting bit. It's also the part I'm not happy with yet so there'll be more work. You guys know a lot about this problem. So about how we solved it. I would love to have that conversation. That'd be wonderful. The only... Give me the schematic. Yeah. Yeah. Brilliant. Give. Yeah. I don't want to video or anything. Yeah. Yeah. So the only thing I'll claim to have done that's at all novel in here is the choice of the quote unquote Xenor device. There's some interesting parts out now that are actually being ungap voltage references. You can get away with a high HIV transistor. Yes, I know. That works much better. Okay, well let's have a conversation with it. I would love to improve that part of it. And as I say, what we have right now, which Tom's going to show in just a moment, are what I would affectionately refer to as version O dot one, you know, produce. Beta. No, they're not beta. They're not beta. Well, so one of the nice things about having open hardware is you can go and grab things like, you know, the PC board design. So this is, you know, just a quick snapshot of the PC board design which I wanted to have that image in mind of the front, you know, the front and the back of the part so that when I show you the picture of version 0.1, you would sort of see that it sort of lines up. You've got all the cool bits there and you've got the nice logo here and the version 0.1 there. And that's what it looks like. It's a little USB key that you plug into your computer and gives you good random numbers. It's too small. Too small. Early prototype. So what's cool about this, for all of you, I don't need to, you know, believe at this point, but it's based on free software and open hardware using licenses that you're very familiar with. You know why, you know, it facilitates community collaboration and enables independent implementation and discussion, which is actually part of the reason that we're here because this security, I think, is very much in need of free software. I don't think we can get to really good security without freedom. So having independent implementations is great and to my surprise, Keith told me that there is a professor here at Portland State that has taken their design and re-implemented it and he's got it, but he couldn't find it to bring it in today. It's too small. It's too small. Okay, but I thought it was really cool. I thought I would do a shout out to Bart Macy for actually re-implementing the design. There's a lot of different ways to analyze the quality of a random number generator. Actually, the fifth standard is pretty modest. Basically, I think it's effectively telling you is this thing alive or dead. We can do, I think we can do much better. There are a number of test suites. I'd love to hear everyone's opinion about test suites that we can use to evaluate randomness. I put test user one up, which is one that has become very popular. Green's blog post mentions a number of other ways in which testing is tricky and needs to be thought out carefully. Obviously, that's an important thing to do. The idea, I think, is to leverage what Simtech did, the idea of connecting with the Entropy Key Demon and EGD so that other applications can take advantage of the entropy pool. So that's the plan. The current status, as BDL pointed out, is we have an early prototype. We're designing the software, life kind of kept me busy, too, so we're still in the design phase. I'm really keen on getting the test suites available to test not just our hardware solution for random number generation, but anyone that we might come up with, and I guess for extra credit, it'd be great if we could get these things in the archive so anyone could use them. And so I have here the URL for the project on altosmetrum.org. It's USBTRNG. There's already an altosmetrum IRC channel. It's on our own OFTC network, hash altosmetrum. And there's a mailing list that we've just created for this project on list.jg.com. So please come and participate. Give us your ideas, give us your feedback. What are we gonna do next? Well, we're gonna continue to test the hardware, make some revisions, take your feedback, tweak it, revise it, work on the software to integrate it, think about potential attack vectors, try to evaluate which ones are most likely, try and mitigate those kinds of attacks. Josh was telling me just at LinuxCon last week he learned about, or he was aware of KRNGD, which is I believe a daemon inside the kernel or a service inside the kernel that manages entropy or provides entropy for different things like, I think sequence numbers for networking. And I saw Tulliff earlier and I told him I was gonna make this plug. I found a really interesting blog post that Tulliff put out in 2009 about distributing entropy. So if we go back to this thing about it, well how many of us manage web servers or other services in the cloud that don't have the typical sources of entropy that a desktop might have, and we might not even be able to plug a USB key into them, how do we get good quality entropy into them? And so Tulliff was talking about it the way that he was doing that at that time and I found that to be really interesting, including Tulliff had some numbers about how much entropy was needed and how much was available and consumed. So I thought that that was particularly interesting and very upper-pull, including some issues, and I don't know if this issue still exists about EGD, about clients reconnecting. I think that's a fact. I think that's not bad, not on that. But I think you reported the verb and I think it's different. Yeah, that's not what I meant. Okay, fantastic. So with that, I'm ready to ask any questions, answer any questions that you might have. This is my blog site. I will put the slides up on my blog, tmarble.info9.net, and as I mentioned, the mailing list is list.gag.com. This is my cat cuddles. Every presentation should have a cat. Or a rocket or both. We got both in this one. So what do you think? Keith, do you want to say anything about Altos? Okay. Barely simple implementation of this, for this particular project. So one of the interesting hardware hacks here was that we have a bits sequence coming out of the comparator and we're just shoving that into a spy input port on the processor. So it takes very little hardware overhead to actually read a stream of bits out of the sequence and then nicely clocked by the CPU. So we're actually able to generate, we can saturate a USB link with random numbers in theory if we can actually generate random numbers that fast. Yeah, if they are actually random, that would be awesome. So this is a nice little USB compatible processor, the NXB LPC-11U14. They're not very free software, free hardware friendly company. I would love to find a better processor, but this one costs a dollar and 48 cents for an ARM processor. So that is a kind of a compelling reason to use them. I would love to switch to, and they're physically very small. I would love to switch to something which is a little more free software. They have actually, there's actually software in the part that runs at boot time that we don't have source to. They have a closed source development environment, which is how they try to get you to put stuff onto their part. And when somebody posted information about how to use an open source, open hardware dongle to get software onto the part on one of their fora, they actually deleted all of that data. Oh, that's not very nice. Yeah. I think if you're prepared to go up to about $1.90, $2, the STM32F10348 PIN QFP was what was the QFP was the one that we used on the entropy key. And I have, what for LQFP48? You already said that was too small. The entropy key is about what? Twice as long in the same width? Huge. Well, the entropy key is about three times as long in the same width. Okay, right. Well, it has two noise junctions. Yeah. But that's my point. What? Well, we can talk about that, but you can get a 36 PIN QFP version of the STM32. And more importantly, I have an open GCC-based Dev environment for it. Also, we... Well, sort of, yeah. It's indebted. Yeah. At least the 32, I'll hold it. Right. So 32, that would be okay. Well, let me ask, let me ask Taaloff, let me ask you a question. How are you handling entropy these days? To, it depends on which hat you're asking. If you're asking my DSA hat, we're actually still using the entropy keys because we got, either we bought a bunch or we got a donation, I can't remember. And yeah, something like that. And so yeah, we're using that for my personal stuff. I actually don't use entropy keys at the moment and just cope. That's, as you point out, it's not a terribly good solution. So if you had one, you might use it. Exactly. In some cases, I've used the UBHSM, which is a, it's an HSM device, which is slightly more expensive at $500. But the nice people at UBICO gave me one for free. So... That's nice. But it also can do a random number generation, so. Pretty good. Here. So what I wanted to say, I not so facetiously mentioned earlier that we had thought at one point that we might just make enough of them to bring in hanamata-debcon to sort of getting some things into the market. But what we've really been talking about because we have absolutely no idea how to gauge the level of actual interest from people who would actually spend money to buy one of these, is this is a classic example of something that we ought to use the Kickstarter-ish kind of model for, one of those sites. And so my hope is that some number of months from now, once we've had a chance to go through another couple of hardware revs and get to something that we actually would not be ashamed to take a little bit of money from people for, that we can do one of those crowd sourcing things. And just see, Keith and I have a fairly well-oiled machine for doing small batch product assembly. The thing that we have not tried to do is deal with what happens if we have a success disaster in one of these. It would be an interesting learning experience actually to find all of a sudden that we needed to figure out how to build 10,000 of something. But for doing hundreds or low number of thousands, we have a pretty well-oiled process for doing that and it's not expensive. So I think if we can get to the point where we have some kind of piece of hardware that we're happy with, turning that into something that people could actually just go buy one of and use and have it be 100% open hardware, open source is not at all difficult for us to achieve. I'll also mention in passing that our most complicated product to date, something that we call TeleMega, which is a six-pyro channel, lots and lots of sensors, flight computer. This past weekend at a launch out Eastern Oregon, we had a chance to take a look at one that some random guy took all the design data off our site, had a couple of raw boards made, taught himself how to hand play surface mount parts at home and got three working boards, one of which was flown out in Brothers Oregon last weekend. So wow. If you ever doubted the veracity of our assertion that all of our designs are 100% open hardware, open source, he actually used our build materials metadata to know which distributors to buy, which parts from the load the board. It really is all out there. So whatever we end up with here will be in exactly that same category. And if we can end up not having sort of little hidden binary blobs in the parts we're choosing so much better, but whatever we end up with, it will be completely reproducible by whoever wants to hack on them. I think you might find it very difficult to find a microcontroller without a hidden binary blob. I think they all have a boot drum and you're not going to get the source for it. The only bits that exist inside the part on the STM32L, we don't ever let execute. So, Nibbe, would you be willing to say a couple of words about your project? I will have my session. I will have my session Thursday morning. Okay. And that's mainly for my GNUG token, but I will also address my random number generator implementation, which is also free software under free design, free hardware design. Okay, great, thank you. I've got a question concerning the SSH problem that it started too early. Can this be fixed if I reboot the SSH daemon later if the kernel has much more entropy? I think so. And then maybe this should be made a default or... Maybe it's as easy as a system desetting. So I thought systems tended to store some entropy on shutdown so that they could load it back up on boot. You can't trust it, it's just a mixer. Right, okay. From our experience, obviously, when I wrote EQD and put that together, I did a big bunch of profiling, which is actually much harder than it ought to be, because this is pre-perf and all the other nice things we can do now. But effectively, the kernel, because it uses random numbers for everything from every time the process starts, it grabs 12 bits. I have the pool so it can change the stack base and do all the random placement. Every time it starts a TCP session, it goes away and creates a new session thing and it grabs three bits. What I discovered was is that a headless system or a system where there are no large-scale sources of entropy for it, often it will never ever actually get enough bits to start the system. It will never get above its minimum doll-out level. So it might get to an up196 and then give it all away and that's the end of the lesson. So when you had the entropy key, how quickly does the entropy become, does the actual entropy become available to the kernel after a boot? Well, we dump it into dev, we write it to dev random. As soon as we are started, I mean, we can pull 20 kilobits a second off. It's 35 on the final product. 35 on the final product. So we can get 35 kilobits in a second. So, but the first four kilobits of that will, we actually physically get out, the first packet dumps straight into the kernel. And I think I set ECD to start very, very early. So it's as soon as it's run, the kernel has more than ever. The problem was we were always overfeeding the dev random pool because of this problem of figuring out who wants the entropy. So if you just send 35 kilobits a second straight into that pool at all times, no one will ever run out with the idea. So I think what should be clear, it's certainly clear to me, is that just plugging a cute little piece of hardware into a USB-figure and launching ECD doesn't completely solve the problem. We have this issue of winter things being started in the system. What's the state of the entropy pool at the time? Various PRNGs are getting seeded and so forth. And so I would hope that maybe part of what we end up talking about as we work through sort of what we ought to do to develop this piece of hardware and have it become something lots of folks want to use is all those ancillary things of okay, what issues do we have in the set of sort of normally launched demons? And should we be changing boot sequencing? Are there things that ought to be kicked sometime later? I'd love to see all of those things kind of get worked on in parallel. It's not enough to just have a piece of hardware and inject more entropy. So I actually have no idea what that has been thought about but has anybody put any work into coming up with a standard USB protocol for these types of devices? So we can have a single driver that gets loaded immediately. If I was a USB device, I don't have to worry about demons or anything like that and get randomness right off the bat. I believe one of the BSTs, I can't remember which one, actually did a kernel implementation of the E-key protocol in order to achieve that so that they could hold off kernel boot beyond starting the USB stack and finding an entropy key. They couldn't authenticate the key but they could use it for sufficient entropy to get the system booted. That's one of the things that we've been thinking about is a way for the kernel to be able to trust the key and how to do that. It's kind of tricky because it's physically connected in its USB and there's all these sorts of things but we have AES on the chip and there's some perhaps some clever things that we can do to secure the actual communications between the key and the kernel. But you're right, it's really gonna be interesting to see how big of a delay is it if we make certain things wait for entropy to come online. And maybe we can profile that and get that time down. There has actually been a little bit of interest in doing that with a special target for system data. I mean, some people are saying system data can probably solve that problem and it can at least help a little bit with it. And the other thing is if you use socket activation for SH then your SH demon is likely to start a bit later which means that you actually won't run into the problem which was shown on the graph. One thing that we did face when we did this the first time when we put the QD out there was there was a very within the sysadmin community there's this thought that this just doesn't matter. You've produced a very good presentation with all the papers and the majority of people who don't get it immediately will turn around to you and say, I can just use, they literally just link you random to Dev random. Well, I mean, if you look at the bits coming off they look random, right? That is exactly what they say, you know. I don't doubt that's exactly the result that's exactly what you get told. So it's more of a, and I got told that from, I'm implementing this within Debian and I get told that a lot from a lot of, you get a lot of pushback. So just be aware that when you come to do that you're going to get a lot of, it's about a political and a social thing of all bits look random until they're not. Again, to go back to one of your comments about needing to be able to monitor and understand the quality of what you're getting off these devices it's exceedingly hard to measure true randomness at the moment you have done any processing on those bits. Yes, that's correct. And so within the entropy key we had two generators and we were actually doing analyses at the bit stream that was coming off each generator. The X oring of the two bit streams in order to do correlation analysis. Then we were doing de-biasing of the bit streams. This will be producing a very biased bit stream. There's no two ways about it. It's an electric circuit. So you're waiting algorithm on the chip. So there's de-biasing to whine. Then you have to analyze that. Then we would mix and be analyzing at that point but the moment you start to mix you need to switch from the algorithms designed to monitor the quality of entropy in random streams to the algorithms designed to monitor the quality of pseudo random strips. Because the moment you have software performing operations on it you're actually behaving like a pseudo random generator and not like a true random generator. And that's fine. You just have to know to switch algorithms for monitoring. And FIPS 140-2 is a very weird thing because it behaves a bit like it's monitoring a true random generator but the algorithms are keyed more towards pseudo random generation. So on the entropy keys we were performing the FIPS 140-2 monitoring after we were mixing things into a hashing state. So again, we'll talk about this a little bit more later but it's really worth having two generators because you really need them for what you can trust. Okay, fantastic. Stephen, do you want to say something? Yeah, as an example of how people don't get this there was a long open bug in Launchpad that a number of us have followed up to where there was a wish list bug opened against the hardware R&G tools package specifically asking people to basically to plug in devU random as a default. At which point. So, you know, and a whole slew of people trying to chime in to explain to the person who asked for this in the first place why it was a bad idea. And we're not trying to be condescending. We're not trying to tell you you're stupid. We're trying to explain to you why this is a bad idea, no matter how expedient you think it might be at the moment. So it doesn't, if you go and get yourself a very, very quick PGP key generation, if you're using PGP without useful randomness you may as well not bother in the first place but people don't get this. That's a really good point. The education here is not trivial. I mean, so yes, I suspect we're going to run into a lot of pushback. So I think it depends. I think if you feel that it's necessary to convince everybody else out there running any kind of service that they need to care about this then you have an incredible piece of rope to try and push. On the other hand, I have this sense that if we come up with a useful piece of hardware that generates real entropy and we can make it inexpensive enough and we do the sort of cool thing of running a Kickstarter-y kind of campaign on it and we get sort of the right people in our extended community to go point at it and go, wow, this is cool. Whether you understand it or not, you really want one of these. Then it might very well be the case that we make enough of a positive effect on sort of the community of collaborators that we really care about a lot that it's worth doing. Not just for our own servers, but it actually makes some kind of dent out there. And whether that eventually leads to more people understanding the problem and caring about it, I don't know, I don't know how to solve that problem, but I don't get too hung up over the fact that not everybody's gonna believe it or want it or care about it. There's certainly reasons you'd like to be able to convince people. I'd love to be able to convince certain server hardware manufacturers, for example, to think that getting this right somewhere on one of their circuit boards was the right answer, but we'll see what can come. I was just thinking about Tolov's case and that he was distributing entropy to servers in a cloud and because of this SSH problem, it's sort of a chicken and egg problem, but if you decided to delay SSH start until the kernel was sure, and we trust the kernel's judgment, that it has enough entropy to seed those keys, so your startup is a little bit slower when you start something up in the cloud until you get enough entropy that then SSH can be trusted. Then you could tunnel a faster entropy stream in. There also was some work at some point to do a QMU device, so you could actually just do this through our diode. I'm not entirely sure where that ended up going, but I'm sure Wins can tell us. I believe it was Ian. Ian. It was Moulton that was working on that. No, Ian wrote a set of drivers for that. I don't think it ever made it all the way upstream. Sorry, yeah, it got presented and the QMU people specifically, Paul, I forget his surname, sorry, and a couple of the others basically turned around and decided on behalf of everybody that QMU didn't want to be an EGD client ever, so they refused all the patches, point blank, and it was at the time suddenly the work QMU was not being developed quite as much as we might like, so I don't know whether the format of accepting things in QMU has improved, but that's what happened to that patch series and I tried for some time to get up quite a lot of that push forward as well. It seems to be less of an future stop now, so. Okay. So, someone's taken that or that series? Yeah, so I seem to remember that, actually, they didn't like the patch and then ended up re-implementing it completely differently, but there is some support for giving you a PCI device which is an RNG. All right, so it's using the host's random ball. Jimmy, do you have a question? I was just going to respond to Bdale's point about gaining acceptance of the value of this. I was gonna say that even if there's still education needed, I think that it's probably a little bit easier to make the trade-offs in favor of security a little bit more than it was a few years ago now that everyone's more aware of the surveillance date and they're at least more open to hearing the usual ways that you do security have this big flaw that you're not noticing. And so it still is an education, but the pushback volume may be a little bit more amenable to positive feedback loop overcoming it. So I think that we're out of time. We don't have any more talk scheduled until four or anywhere as far as I know. Okay. So you guys had a lot of time, but yeah, if anyone has anything you want to do. Do you have another question? Other other questions? Go ahead. I just have a couple of general crypto questions. I think I heard at one point that the Trusted Platform Module has a hardware RNG built into it. Does anybody aware of that? And that's a maybe a good segue to my next question is what if you have a hardware random number generator, but you want to mitigate your risk because you don't completely trust it. Is there a consensus in the crypto community that mixing is enough to do that? Okay, I've got an idea. Dennis has an idea. There's no one here. So who wants to go next? Give it to her. If you have a good source of random numbers, you can mix it with something that you know is untrustworthy and it's probably fine. Yeah. That's basically what I was going to say. I don't have any opinions about TPM. I guess. Regardless of TPM or not, there's a mechanism within, at least the most kernel mixing process to allow you to state when you hand over X bits of data that it only has Y amount of entropy value in it. And in fact, an EQD by default for every eight bits of data it hands over only claims seven bits of value. Therefore, if you have a random stream that you believe to be okay, but it's really high speed, you could give it 4K at a time and tell it there's only 128 bits of entropy in there. And like Rob said, as long as there is some true entropy in there, a good mixing algorithm and the kernel one's really good. It's not the best, but it's pretty good and it's reasonably fast. We'll spread that entropy out such that every bit of its possible output has been affected by every possible input entropy Shannon. One of the things that I found in researching this was that there is an interesting, relatively newer PRNG algorithm called Fortuna that didn't make it into the kernel and I didn't really find out why. Does anyone know? Just curious, I'd love to learn more about that. Fortuna is a PRNG. Right. So the idea is that you can top it up with some real entropy you have and then it satisfies all your requests from that. So it's basically like DevU random. The free BST people and so on, they use Fortuna, I think OSX use. Yeah, Yaro is the predecessor to Fortuna. Fortuna's just sort of like a tweak on it, but it is basically a PRNG that you occasionally recede as you have data available. Whereas DevRandom is, I'm sure these are actually random bits. Right, right, right, right. Well, I mean, if you go shopping for PRNGs, we could talk about different qualities of PRNGs. My understanding is Fortuna is probably better than earlier implementations. It's just big blood fish. Blood fish? Oh, I didn't realize that. In that regard, what about... Oh, I don't know. Video stream. In that regard, what about HabGED? I have that installed, but I also have an EQD that I'm mixing things in and I don't know if anybody's looked at that one specifically, but you know, you have to get installed and you immediately have lots of entropy, but... Yeah. Yeah. Oh, God, don't use that. Don't use what? Random sound. Random sound. Random sound. Oh. I write a piece of... Oh, here we are. I've been reminded, so this is an apology. I did write a piece of software a while ago called Random Sound. It did make it into the archive. I think it was that was Steve Grand's fault. Everyone can blame him. Which was based around the idea that if you had an audio input, that was one that you could set to be a tri-state input. Then you could use the noise around that circuit as a source of entropy. Or just use the lower bits from the ADC and you'll be fine, right? No. And it would produce a very high-speed stream of data, but frankly, I would trust it to be about one shan in 128 megs. And... Oh, yeah. Yeah, the radio one. The comment where we were shaking our heads. The problem with anything like that is that an attacker can put a coil of wire around your input and attack it very effectively. Well, that sort of requires physical access, though, right? Right, but physical access is something you need to mitigate against when you have a physical device. Indeed. Yes, bud. And the bud part is just that at some point you have to decide how far you're gonna go with that. I mean, anything that depends on thermal noise has, you know, the potential of being driven very far in one direction or the other with, you know, the application of a suitable doer of liquid nitrogen and or a blowtorch. So... I'm sorry, I'm not kidding. I mean, it really is the case that if you care about this at that level, then you do have to physically protect the devices and you have to think about the right way to do that. And, you know, the thing about a completely open design that's reflashable is you also have to think about, you know, the consequences of how do you want to secure that, you know. Is this an example of a completely open device that we ought to flip the bid on that says you can't USB reflash it? You know, this is... Wait, Tom and I had a very serious conversation on IRC one night about, you know, should you ever let someone other than one of the three of us have one of these devices that they can reflash over USB without having to go get a programming dongle and put it on the, you know, the in-wire pins? These are interesting questions. It's not like there's a single simple answer either, but this is why I say when you start thinking about what the potential attack surface is around something that's going to be as fundamental to your sense of the security of your system as the hardware random number generator, you have to think about these things. You have to make conscious decisions, and you bloody well need to document what everybody else that's looking at it and thinking about using it or doing something with it understands what they're getting. And to me, that's part of why it's so absolutely vitally important that this time around what we do ends up being something that's a completely open design that everybody can look at, everybody can think about. If somebody wants to create a better derivative of, more power to them, et cetera, et cetera, et cetera. Peter, can't you just put, like, a TPM chip right here? We will accept it, so perhaps we should have made it more or two months later. We don't know when the selection process will end. Yeah, I... You guys don't need to apologize. In case you hadn't noticed, lots of inspiration taken from the work done on the Simtech Entrepiqui and EKD and all those sorts of things. Mad props for... We're going to build on it. I actually found one to buy at LCA last January so that the ones I lost in the fire didn't leave me without. Mad props. This is all about what do we do now and how do we go forward, how do we make sure this kind of stuff becomes and remains available for those of us who need it. Did you have another comment, Rob? I was just going to say that for the attack of dipping it in liquid nitrogen or blowtorch, the Entrepiqui had a temperature sensor, so it went, no, I'm too warm. My numbers aren't random anymore. Don't trust me. Feature creep. Feature creep. It literally glues fuses in terms of fuses in my car. Sorry, thanks for my buy. Thank you very much, sir. Actually, we're live. Eat was a software. Yeah. Question here. Beth, back. Apparently the temperature sensor is so good that my colleague uses it to monitor the temperature all the time. He's welcome. Well, we certainly didn't think of creative hacks for other sensors that we could put on the board. Hmm. Maybe we should put a webcam on it. Oh, sorry. Wolverine. I'll answer actually. Any other thoughts or questions? Oh, see. So I never did get round to picking up enough Entrepiquis for my own uses. And now it's hard. In the future, when you go into series production with these, any idea on price, what do you think you can do with them? What do you think you can do them for? Pass that to the business department. So the problem is that I've gotten very good at figuring out, based on the raw bill of materials, what I have to charge in order to be able to continue to operate a business in a high-power model-rocketry world where there's a certain flavor of customer support to engage in, and there's a certain, you know, sort of turn-on rate on the complex boards. And by many measures, this is a substantially simpler piece of hardware. It is going to have a similarly complex, you know, bench verification for each unit before I would be willing to take money from somebody. So I don't exactly the answer. This is certainly in the... It's in the sub-50-dollar range, but how much below that? I don't know. Certainly if we do a kick-startery kind of thing, it'll be, you know, cost-plus. And then if we actually sell them for realsies after that and have to inventory them, it'll be different. That's exactly the kind of thing I'm looking for. Yeah, I can't imagine it. I cannot imagine asking... Okay, I know what to look forward to. And it'll have a pretty plastic box, too. Will it be Altus Mentor and Blue? The Hammond doesn't make a box in that shape. White or black? Which is your choice? Well, that is unless we can get Jeff to find us that color in the right spool for the printer. But... Reach your own case. You can print nice, steady swirls. That would be wonderful. Okay. I think we're about done. We're done. We're talking about 3D printing swirls. We're done. Thank you, everyone.