 Thank you for coming today to my talk about D-RUN, so Public Variable Randomness Explained. So I'm Yalan. So this is a disclaimer for our American friends. I'm from Switzerland, not Sweden. So it's not the same thing. We got the chocolate and the cheese. They got IKEA and, I don't know, a lot of snow. I'm a CTF player. I'm an applied cryptographer at Protocol Labs. So not to be mixed with a Web3 developer, so please don't come after me. And yeah, I got a math background, but I will try to make these as simple as possible. It's about computer sciences and computer engineering, not about math today. So what are we going to see? Well, we're going to see what is randomness, and then we will see what kind of flavors we have for randomness. What are the different kinds of randomness that we have? Finally, well, next, we'll see why we need randomness, what kind of problems there are with randomness, and how to do it properly in practice. So what is randomness? It's a good question, right? So we can look it up. According to the Cambridge Dictionary, randomness is the quality of being random. Great. That's it, right? Well, granted, they refine it a bit. So it's a quality of being random, which means happening, done, or chosen by chance, rather than according to a plan. If you look at other dictionaries, you can see maybe better definitions, such as according to the Oxford Language definition, it's the quality or state of lacking a pattern. And that notion of lacking a pattern is super important for randomness, and we'll see why in a minute. So here are five random strings. Does the first one look random? Yeah, super random. Does the second one look random? Well, the second one is actually random. How about the third one? Not random, obviously not. Next, we've got the fourth one, which looks really random, right? Unless you look at it in hexadecimal, that doesn't look random then anymore. And finally, the last one has an obvious pattern, so it doesn't look random neither. So the important thing to remember with randomness is that all of these values add the same probability of occurring at random if you were to pick a random number of that size. So it's really difficult to say if something is random or not. We can try to do that. We can have some intuition of what is random by looking whether there are patterns or not. And there is a more formal academic treatment of randomness that is called the Kolmogorov complexity, which is basically the notion that if you can compress it, if you can output it in a smaller form factor, then maybe it's not so random. So typically, here I can represent the first line with just 19 characters instead of the 48 characters I needed to display it in full. So it doesn't really look random according to Kolmogorov complexity neither. But today is not a talk about Kolmogorov complexity. It's not a lecture, you know, so we will get into what is randomness and its different kind of flavors now. So first, I want to talk about the notion of public randomness. So public randomness is the notion that you want to pick a random number and reveal it to everybody. It's going to be public, you know, like you will publish it on your website or maybe you're running a lottery and you're drawing the numbers live on TV, but it's going to be public, okay? That's a different notion of randomness than the one we're most used to, which is that of secret randomness. We very often use randomness to generate secret keys. Whenever you connect to a website nowadays, you're using TLS, or at least you should, and TLS is using ephemeral keys. An ephemeral key is a random secret value that is drawn from your computer and it should be random to ensure your security, well, to ensure the privacy of your communication channels. We typically use secret randomness for generating secret keys, your PGP key must should be random, your Bitcoin private key should be random, and so on. It's very important to never use public randomness as a source of randomness to generate secret values, so please do not use a public random value to generate your next PGP key. It would be easily broken. Next, I want to talk about the notion of verifiable randomness. That's something we don't see too often, but it's really important with public randomness because they combine together really well. So verifiable randomness is basically a random value that you can verify it had been generated properly. So if you can verify the random value is actually random, then maybe you can trust it more, and that's really interesting for many use cases. We'll see use cases soon. So another big problem with randomness is the notion of distributed randomness. So nowadays, the internet is becoming more and more decentralized. There is this notion of web three where everything should be more and more decentralized and distributed. Agreeing on a random value as a group, so aving consensus on a random value is really difficult if you want to ensure it's unpredictable, for example, because if you cannot predict it, or can you be sure everybody's going to come up with the same random value, right? So achieving consensus on random values is difficult, and you can look at blockchain, for example, like Ethereum and that kind of blockchain that are running smart contracts. If you want to run a lottery on Ethereum, it's going to be difficult because it is fairly easy to predict future values. And there is a huge problem in the space currently with the MEV. So it's when miners can extract more value out of the block than just the reward from the transaction fees and the classic, the normal reward. That kind of things are difficult. So I gave you some hints of why we need randomness already, but I'm going to go over a few more use cases now. So public randomness make a lot of sense for lotteries, jury election, audits, random sampling, and that kind of things. The secret randomness is really used and very important for all cryptographic protocols out there, from TLS to SSH. You're probably using secret values, secret random values daily. Next, we have a few more use cases that might be less obvious, such as sampling. If you are running a medical study and you need to sample people at random, or do you do to make sure it's random and somebody didn't select their friends or something like that, it becomes even more interesting if you're looking into use cases where people are introducing, for example, basic income in the country and they need to select people at random because corruption and that kind of things are still a thing nowadays. And if you cannot do random selection properly, if you can bias it, then it's really bad. So a very good example of that is like a month ago, even less than a month ago, a few days back, we could see that both the former FBI director and his deputy were selected at random by the IRS for an intensive audit. That's an exact, that's a really good example of why we need public verifiable randomness because now nobody's going to trust the IRS is actually selecting people at random, right? Next, we'll see ways or problems with randomness. So it's something cryptographers will say very often, randomness is hard. And trust me, I've been doing a lot of code audits where I was looking at other people's codes and the most common flow was usually randomness. People will introduce bias or make the randomness predictable in ways that would break their whole systems. And these are the two very important properties we usually want to have with secret randomness or even proper randomness in general. We want it to be unpredictable and we want it to be bias resistant. So why do we want it to be unpredictable? Because if you can predict random value, you can most likely cheat or do something bad. If it's a lottery, you could predict the winning ticket and win it. If it's in a game or if it's in an audit, you could warn people or do nefarious things. So we really want it to be unpredictable. For cryptographic protocols, it's even more important because if you can predict the randomness in a ECDSA, for example, you can actually do a full secret key extraction. And that is the worst thing that can happen to a cryptographic protocol. Secret key extraction is something you don't want to have, right? And why unbiased? Well, this is tricker because having a bias is not always a bad thing. Maybe you want to select more people in your studio that are between 20 and 30 years old or whatsoever. It depends what you're doing with your randomness. But for cryptographic purposes, for secret randomness, you really, really want it to be unbiased because just a one-bit bias can also leak your secret key if you've been signing enough things, be it transactions, be it emails, whatever you're doing with your private key. If you sign enough messages and you have a bias in your random number generation, we can extract your private key. And that's the worst thing that can happen, right? And that's true for all cryptographic schemes that are most used nowadays. So it's not necessarily true for RSA, but RSA has been phased out nowadays and we're using Schnur-like signatures such as ECDSA, EDDSA, Elgamal, Schnur, BLS, and so on. And these are very sensitive to bias randomness. So maybe you've been coding already and maybe you needed to draw a random value. Or would you do that? Well, a very easy way to draw a random value is just to call your operating system random, get random syscall, right? So most programming languages offer such calls through OS or whatsoever module. So here is an example. To get a random number between zero and 255, we can just draw a random byte and convert it into a number. That's fine. It's unbiased, it's good randomness. If you've got a modern computer, nothing to worry about. But if you don't want to pick a random value between zero and 255, say you want to pick a random value between zero and 106, so you have 107 possibilities from zero to 106. Or would you do that? Well, most people will think, ah, I just reduced it to 107, right? That's a very easy way to just slash the extra values you could have gotten in your bytes. But that's actually not a good idea at all because these is called modular bias. And here is a graph of why modular bias is bad. So if you do that, your lower values will have a higher chance of being drawn. So here in this example, we're drawing one byte. So we have 256 possibilities and we are converting it into a number that's smaller to 107. And that means we have the 42 lower values from zero to 41 that are more likely to occur. And this means you've just leaked your private key if you were doing a cryptographic protocol or something like that. So it's really important not to reduce modulo, the target value if you're doing secret stuff with your randomness. The best way to avoid bias is just to rely on your cryptographic PRNG to give you proper values. So most libraries from Python to go to Rust, you can even find some in C but with coding in C, right? All of these languages have standard libraries that provide you with good randomness, good random numbers that are unbiased and easy to sample. You can also read my blog post about how to avoid modulo bias. It's the link here. I'll post the slides on my website. I guess MCH also posting the slides online so it should be fairly easy to find if you want to read more about modulo bias. Last time I talked about that, somebody asked, hey, what if I just divide by 255 and multiply by the value I want to get? That's unbiased, right? Well, no, because precision and floating points number are going to kill you again. So this is not going to be bias like the modulo bias. So you won't see a heavy first half of the graph, you know? But you will get spiked in the middle of your graph. And that's also terrible. There is a really good blog post by the PCG random team which are really going into the details of how PRNG and randomness works are highly recommended if you want to learn more about not choosing floating points. So in practice now. So in practice, randomness has been really difficult for a long time, but we've mostly solved it on personal computers. The somewhat unsolved thing was public verifiable randomness. So that was first proposed in 1993 by Rabin. The notion that even a trusted intermediary could release trusted public random numbers was introduced, but you need to trust somebody who wants to do that, right? So there are websites that offer public randomness. For example, random.org claims to be using a true random generator or collecting the atmospheric noise and giving you random values. But how do you trust them? It's just a website. You can't really look into their system. It's not open source. It's super annoying too. So, ah. Next, you have NIST. You know the NIST standardization body in the US? They're very active in the cybersecurity space and for cryptographic protocols and everything. And so they released the first public verifiable trusted randomness beacon in 2013. But NIST is also very famous for trying to bias randomness with their dual ECB random generator. So who would trust NIST to run a public randomness service, right? So there have been a lot of previous attempts at doing public randomness, right? And one of them was an academic world work roundhound and it seemed like a really good way to achieve this. Sadly, it was using short signatures. It was relatively slow. Had a lot of network overhead. So the question was, can we do it in a simpler and faster way? The answer, actually, is yes. So just like we have NTP servers, DNS servers, certificate transparency servers and that kind of things, we were thinking the internet really needed a public verifiable randomness protocol that anybody could use. And that's exactly what DRUN is about. DRUN is an open source software. It's coded in Go. It's coming originally from EPFL, so it's been studied by academics. And then it was launched later by many people. We'll see that later. But DRUN is relying on cool threshold cryptography and it's providing the nice thing we want with public verifiable randomness. So we'll get into the details now. DRUN is meant to be decentralized. So DRUN is just the software and you can run it on multiple nodes. And when you run it on multiple nodes, they connect to each other to form a network. And that network is using threshold cryptography, which means you just need a threshold number of nodes to be available for it to produce randomness. That randomness is going to be unpredictable, bias-resistant, unverifiable. So it's really good public randomness. The randomness is currently chained. So each new beacon is linked to the previous beacon. So if you don't know the previous beacon, you can generate the next beacon. So it's really helping with the unpredictability. And as long as you even compromise the threshold number of nodes, you're guaranteed, you cannot predict the next round. It's really easy to use. This is the JavaScript code to verify DRUN randomness. So you can see it's very few line of codes. You just need to import the BLS12 381 code from a novel library and then it's very easy to verify. The threat model behind DRUN is basically that of a threshold network. So you have a set of nodes and together they are going to generate randomness every 30 seconds. And they do that by relying on BLS signatures. BLS is a threshold signature scheme and you just require, for example, currently 13 members to generate a valid signatures to get a group signature. And that signature is valid under the whole group public key. And that group public key allows you to verify randomness was generated properly. The security of BLS and that kind of threshold cryptography is fairly good as long as you don't get a quantum computer. So we should be fine for the next five to 20 years, I guess. Also, it's very important your secret key stay secret and so on, but we'll see that in a minute. DRUN is also exposing public APIs. So you can just query it online. It's a REST API. You can curl it. You can use it in your browser. And you get the randomness on the signature which allows you to verify the randomness was generated properly. While DRUN is just a software and is exposing on points and everything, you can't really use it unless you have a network, right? So that's where the League of Entropy comes in. The League of Entropy is a set of companies, universities and research teams that came together and decided to run a DRUN network to provide public verifiable randomness to anybody who needs it. It was first created in 2019 with 10 members. It has since grown to 16 members with 23 nodes on the threshold of 12. I think we just ran in the last ceremony we were now maybe 24 nodes on the threshold of 13. Everything is open to rules. You can look it up and it's, yeah, fairly interesting. The nice thing with DRUN is that all nodes can provide their own entropy during the distributed key generation. So for example, here, Cloudflare is using their lava lamps as a source of entropy in DRUN. So it's true randomness, you know? And DRUN is collecting the randomness from all the members that run the distributed key generation. And that means it also should be fairly solid in terms of unpredictability. And that's a nice to a thing. DRUN has been running for, well, the League of Entropy has been running DRUN for now two years. We just crossed two million rounds last week and we had zero downtime. So it's a really good battle-tested system if you need public randomness. And what can we do with DRUN? Well, we can obviously do lotteries, we can do gumbling, we can do a lot of things. But something I'm super excited about is time lock encryption. And that's something we researched in the past six months, mostly. And to enable that, we needed to be able to run multiple networks on the same DRUN node. So we recently introduced the notion of multi-protocol support, which means a single node can run multiple networks. So we can have a post-quantum network, we can have a very fast network, we can have a very slow network. We can have also, instead of a chain randomness where each beacon is linked to the previous one by its signature, we could have a unchained network. And the really nice thing with unchained network is that you can predict the message that is going to be signed in two days or maybe in a week. And if you can predict that message, then you can use very fancy cryptography to do time lock encryption. And this is something that's amazing because time lock encryption is an unsolved problem since 1993 as well when it was proposed on the Cypherpunk mailing list by Tim May. And time lock encryption is using pairing-based and identity-based crypto just like we do with DRUN. And it means it's very easy to integrate with DRUN. So each DRUN round, I told you, is produced at a given time. So for example, we produce currently rounds every 30 seconds on the current network. We are probably going to launch a faster network, but the current network is staying, right? We can run multiple network at once. And every 30 seconds, we get a round. So in five minutes, it's just 10 rounds in the future, right? So we can link DRUN randomness on rounds and becomes to future time. And that means we can use time lock encryption to encrypt towards a future round. And that's a super cool thing. I'm not going to explain it because it's going to be released next month at DEF CON actually. So we'll be releasing time lock encryption based on DRUN. You can use it for a lot of things, including a dead man's fully yet responsible disclosure system. We're going to release a time lock encryption open source library. We're going to release a JavaScript web app as well running in your browser. So I'm super excited about that. Finally, we would love you to use DRUN, right? So we created this cool public randomness server and anybody can use it. You can verify its random. You can use it in your, I don't know, lotaries in your jury election to select people at random for your audits. You can use it in smart contracts and so on. So please don't hesitate to use DRUN. Currently, it's mostly used by Filecoin to do leader election. There is a company in the US that actually is using DRUN randomness in their gambling system to generate random values for their gambling machines. It got authorized by the Gambling Federation in the US, so it's pretty cool as well. We got a website explaining everything about DRUN in case you are interested. And another cool thing you could be doing is decide to join the League of Entropy. So come and join Cloudflare, Protocol Labs, and the many other members of the League and you could run a node. So if you're used to have high availability servers or something like that, please come and talk to me. We would be thrilled to expand the League of Entropy because the more members we have, the higher the security and the trust in the network will be because of the fact that you just need to trust a threshold number of nodes. So as long as you're sure there are enough diversified members in the League of Entropy and that they are not going to collude together, you can trust the League of Entropy to produce fair and buyout randomness. That's it more or less, so thank you for coming today. I'm... Thanks a lot, we have time left. And if there are any questions, please line up at the microphones in the middle of the room. Anyone? Yes. Front microphone, please. Step close so that we can hear you. Yes, there we are. Thanks for the talk. Important work, I think. I was wondering, do you have ready-made scripts or programs too? How do I put this? For people to afterwards verify that things were indeed random and correct, make it easy for people to check this, actually. Yes, so I didn't go into the math too much, but basically the random values is generated from a signature, so from a BLS signature. And the random rounds are made of all the information you need to verify that signature. And you just need to use the public key of the network. So if the signature verifies under the public key of the network, then you can be sure it was properly generated by the network. And if the network is not managed use, then it's good. So you can do that by either querying the DRUN on points and getting the beacons, or you could, in your application or whatsoever, include the signature as well as the randomness. So people can see they can derive the same randomness out of the signature. To be more precise, we can't use the signature itself as a random value, but a signature must satisfy the undistinguishability under between two signatures. So it must be indistinguishable from random. Otherwise it's not a secure signature scheme. The problem with signatures is that there are unfunny elliptic curves, right? So if you just take the signature, you will get the algebraic structure of the elliptic curve that's going to bias your randomness. So what we do is we take the signature, we hash it to map it to a uniform random string, and so that's how you can verify it was properly derived. You take the signature, you validate the signature, and then you hash it and you get the same randomness, and that's it. Thank you. You're welcome. And we have another question. So usually in things like this, there's an input component, there's the keys, and then there's also an input component, like the input to a BLS, this message being signed in BLS signature or something. Is there a way to contribute not to the randomness of the keys, I guess, but to the randomness of the input so that you get a kind of a faster turnaround time in terms of knowing your contribution was included without being a member, I mean. So currently I didn't go into the details too much, but the only time where new entropy is contributed to the network is during key generation. So the messages we are signing with the BLS signature scheme are the previous signature and the round number. That is fine as long as we still satisfy the security assumption that there is never a threshold number of malicious nodes. But so you can, yeah, we could add a way to make the signatures more unpredictable by adding some random values to the messages we are signing. Currently it's not the case because it's difficult to achieve consensus on a random value to include in the messages. So currently the only time you get new entropy is during key generation, yeah. Okay, are there any more questions? Or is everything clear and answered? Anyone? One more. Okay, front micro. So you require a simple majority of the parties to reduce the random number. Can you scale that up to like a higher threshold if you wanna be sure that he, well, I guess this has like liveness implications then. So the League of Entropy is doing resharing regularly to refresh the shares because of the threshold cryptography thingy. So if we want to increase the size of the network, we can add new nodes and change the threshold during the resharing, yeah. Okay. So it's possible. But you need a threshold number of nodes to agree to do a resharing. But if you wanna say, if you grow this set to like a really large number and then if you wanna reduce like the amount of trust that you have to like, if you start accepting like worse or like less trusted instances and then you wanna keep the thresholds still high, then you maybe wanna increase the threshold, I suppose. Yeah, I suppose it. So if we add more members and we wouldn't trust them to be able to be trustworthy, I mean, we don't trust any single member in the network currently. But if we add an easy way to get into the network, somebody could try and add a lot of malicious nodes so that they would get a threshold number of malicious nodes. So currently the network is really permissioned. So you need to get approval to get in, right? You can't just join the network like that. You need a threshold number of nodes to agree to onboard a new node. And so yeah, definitely if we were to increase the size to 100 or 200 nodes, we might want to increase the size of the threshold as well. But the thing is currently, I had a slide about it actually, the network is trying to be fairly diversified. So we're trying to not be on a single continent. We're trying to not run on a single cloud provider and so on. And in the future, we're also looking into having more implementations so that if there is a bug, for example, in the go implementation, we would still have maybe the rest and the Python implementation working. So yeah, there are a lot, yeah. So you can play with a threshold, but the larger the threshold is, the more dangerous it gets for liveness because if AWS goes down, suddenly the network would stop and that's something we really don't want to happen. We want it to be very like high availability and doing its work every 30 seconds, you know, so. Okay, and we have one more question. All right, thank you for creating this wonderful tool or toy. If I sort of like to look at this and I kind of like see really nice diversity across quite a few continents and sort of like types of organizations on-premise, off-premise and so on cloud. And I think of like how you would use this. You could almost, would it be fair to argue if you sort of like add a few, let's say, Asian, South Africa, Australia, you are essentially dumb because is there a fundamental reason to go to a much larger number of nodes? So, sorry, I'm not sure I'm getting the question. Well, so you're very far on your way already having a nice mix of clouds and on-premise. So, in a way, for a lot of like attack models, you're covered there. You also caught quite a few countries there, like Edson Asia, Edson Australia, and you basically got the whole world. Is there any fundamental technical or security reasons why you need more nodes than that? Like why it would be better to have 100 nodes than just let's say 30 and be finished with it? Really no technical reasons, mostly human reasons, I guess. Do people trust Cloudflare? Do people trust Protocol Lab? Do people trust Ethereum Foundation? Do you trust the EPFL University in Switzerland? Do you trust the UCL in London? So, it depends, right? It depends on your threat model and that kind of thing. So, having more nodes could increase the trust of some people in the network, but at the same time, it would be more difficult to keep up with the liveness. So, currently we're not planning to get to 100 or 200 nodes. The goal would be maybe to achieve more diverse set of nodes, like having Australia, having Japan, and so on to the list would be great. A really nice thing as well with Ethereum is since you just need a threshold number of nodes to communicate with each other to achieve, to get the final beacon, you could get nodes in America, talking to each other, generating the exact same randomness than the nodes that are in Europa. So, you don't get too impacted by the lag if you have enough nodes, but that's a very interesting research project we're actually looking into right now. All the network and the lag is actually impacting us because with such a network running on a global scale, it can become somewhat of an issue. So, currently we have 800 milliseconds of lag on producing the next round, so we couldn't go below one second with proper warranties of availability and liveness, right? But, yeah, so it's pretty cool to have such a global network on, yeah. Okay. If there are no more questions, thank you very much again for the talk.