drand 🛠 using drand and timelock encryption - Patrick McClurg

Hello everyone, welcome to the Hack Fest workshop on using Drand and time-locked encryption. Today we have Patrick McCleer with us, who will be leading this session, and I'll hand it over to Patrick to begin. Thank you very much, Rory. Yes, welcome to the Drand Hack Fest workshop. First, we'll take a brief look at the task, and then we'll delve into what Drand is and how it works.

After that, we will finish looking at what time-locked encryption is and how it can be used. At the end, I will answer any questions you may have during the session. So, session. So, firstly, there are two types of tasks. First—for the best application best application created using time-locked encryption.

This may be confusing to those who have not encountered this type of encryption, but we will get to that soon. Secondly, there is a prize for the best use of Drand to solve an everyday problem, increase the security of a blockchain project, game, or improve the Drand ecosystem. In total, $2,000 is up for grabs for those who create the best apps. So, what is Drand? Drand is a decentralized threshold network for generating publicly verifiable and immutable random numbers.

As I said, it is based on threshold cryptography and supports pairing operations, which we will get to a little later. In essence, during the creation of a network, a process of verified secret sharing occurs, which forms a shared private key between all participants, to which no party has access. After that, they generate randomness over epochs using signatures using a threshold cryptography scheme. It is built on the BLS 12-381 curve. The system has been tested and audited by Kudelski Security, and deployed at scale.

The largest user at the moment is the Filecoin network, which uses randomness from Drand for leader selection and other Proof-of-Spacetime related tasks. Drand randomness is currently available in FVM, the Cosmos ecosystem, and partially in Ethereum. By the way, at one of the past Ethereum hackathons, the team created a Drand integration for Ethereum called RNJesus, a link to which I added at the bottom of the slide if anyone wants to try it out for themselves to try it out for themselves . So, a brief introduction to how Drand works. The designations are not very important.

This is for math geeks who love all the details. But essentially, the epochs of chance, each of these epochs corresponds to a certain time on the clock. So, for our network, the default is every 30 seconds. Every 30 seconds, nodes in the network distribute a partially signed message about that epoch number. And when any node receives a threshold number of such signatures, it can combine them into one group signature, valid for everyone in the network.

Since, as I said, no node in the network has access to the private key, this signature is indistinguishable from randomness, because it is impossible to predict. We then run this signature through a hash signature through a hash function to remove certain mathematical properties, and that becomes our random number. And this happens in every era. Everyone in the network distributes their partial signatures among themselves, creating randomness. You may be familiar with some types of randomness, and I will briefly explain how D-Rand is different from them.

The most well-known type is dev/ well-known type is dev/ urandom, built into all Unix machines, Linux systems, and Macs, as well as an analogue in the Windows world. It's probably what you use to generate Bitcoin private keys and other everyday transactions that require randomness. The biggest difference, of course, is that dev/ of course, is that dev/ urandom is private randomness, while D-Rand is randomness, while D-Rand is public. Naturally, you wouldn't want to share your Bitcoin private key with anyone else unless you want to lose all your funds. In D-Rand, however, all random numbers are public.

Everyone can read them. Everyone gets the same random numbers. Additionally, you run urandom on your own device, while D-Rand is a decentralized network. So, many different participants work together to create this randomness. And finally, D-Rand is proven.

If you get a number from a random number generator, you need to trust that it is implemented correctly, that you are using the correct generator, and that the resulting number is truly random. But since D-Rand is based on a signature scheme, you can verify that the number was generated correctly. And thanks to the property we mentioned earlier— the impossibility of predicting signatures of predicting signatures —it is both random and verified, which at first glance seems contradictory. Now let 's delve into other aspects of the world of public chance. Those who have already worked with Ethereum may be familiar with Randao.

Randao is a smart contract DAO on the Ethereum network, where users pledge to provide some entropy to the smart entropy to the smart contract and then reveal it. And these bits of randomness are put together into a final random number. What you want to distinguish from this is primarily its unpredictability. So you can imagine someone with a lot of power on the Ethereum network, say Coinbase, who could actually take up a lot of slots in this Randao contract. And they can decide whether or not to reveal their little bit of randomness, based on the previous outcome.

So, if you manage to get a certain number of slots at the end of any Randao era, you will be able to influence the final outcome. Also, a cool feature of D-Rand, based on the signature scheme, is that it is not just for Web3. The D-Rand blockchain as such does not exist. This is not just within one blockchain. In fact, you can get D-Rand signals from D-Rand signals from any CDN.

You can even get them from an attacker. And because they are verified, you can know that the D-Rand network generated this random number. The latest project that is currently very popular in blockchain ecosystems is Chainlink VRF. Chainlink VRF allows you to request random numbers, they create proof and record it somewhere before use to show that the randomness was generated honestly. generated honestly.

First, like Randao, the difference with Randao is that Chainlink is primarily for network applications, but the trust model is also very different. You are turning to one party, Chainlink, to perform this function to generate a random number, whereas in DRAND there is a network of participants and you have to trust that there will never be a threshold number of attackers on the network. So the model is just a little different. Now a little about the network part. We currently support two networks in production: the default network and the fastnet network.

The main difference between them is that the default network generates randomness every 30 seconds, while fastnet generates randomness seconds, while fastnet generates randomness every 3 seconds. They, of course, have different of course, have different URLs to interact with. In addition, they operate in slightly different modes. So, in a default network operating in chain mode, each signal contains a reference to the randomness from the previous signal previous signal . This means that they form a kind of directed acyclic graph (Merkle DAG).

And one downside to this is that we can't use time- locked encryption, which I'll talk about later, in this chained mode. In contrast, in a Fast network, each signal is independent. It is not connected to the previous signal through this chain of signatures. And this means that we can predict all future messages, although not signatures, for beacons that will appear on the Fast network. This is the secret ingredient for time-locked encryption, which we will return to later.

Also, for the math geeks: in the Fast network, we swap groups G1 and G2 in BLS to get smaller signatures and larger public keys, since at the network level we create one public key, and each epoch, a and each epoch, a signature that also contains randomness contains randomness . So, this means you can save on gas fees if you use this on the blockchain. So if you were to open a terminal right now and query the randomness via the VRN API, you would get something like this. The top entry here is the round number, i.e.

the epoch. This is a monotonically increasing number. Every time the network generates a portion of randomness, it's a new round. This also corresponds to a specific time on the clock, so you can predictably know when a specific round will become available . The next key in it is the randomness itself, which is the SHA-256 digest of the signature.

The third signature field is, in fact, the signature itself. This is a group signature for the entire network. Again, this is a key pair created during the distributed key generation process, and it is BLS 12-381. For chain networks, there is also a pre- signature, which, as I said, connects all these pre-beacons. The easiest way to access it is to use client libraries.

We provided one in Go and one in TypeScript. These are official libraries. Of course, you can get them through any CDN or any any CDN or any HTTP client. But they also include a signature verification feature. So you don't have to do it yourself.

Also, it seems like everyone in our community is a Rust guy, so there are a bunch of different Rust clients for those who like to write in Rust. By the way, the first one, D, is also a CLI that can perform time- locked encryption and many other cool operations. You should try it because it's great. I have a slide that says "time for demo," but that's a bit of a lie. This is more of a code review than a demo.

Ahem. Let me pause the presentation for a moment. Um, I'm just going to move on to the D-run client integration tests for JavaScript. I think this is the easiest way to understand exactly what's going on, and at least you can find it later if you don't quite remember what was in that presentation. Um, so we have an integration test here.

Essentially, you are creating some infrastructure some infrastructure . We get the public key of the network, which can also be done off-channel. There are also other objects that allow you to avoid making requests for this. We provide three main functions. First, you can get a beacon by time.

You can simply pass a classic JavaScript date and the correspondence between real time and the DRAND epoch will be determined automatically. If you know the era you want to use, you can also pass it in and get the beacon simply by the round number. Finally, we provide a watch function. So if you're, for example, building a game that needs to use DRAND randomness in a timely manner every epoch, you can get an asynchronous generator that will trigger a callback every time you get a randomness. They are also more or less available in the same format in the Go library.

So I won't go into depth about the Go library. But if you have any questions about this, of course, contact me. Okay, that was about how we use DRAND and a little introduction to how it works. Now let's look at time- locked encryption. It does exactly what it says on the label.

It's the encryption of something now that can't be decrypted until some time in the future. The bottom line is that the DRAND network DRAND network is like a reference clock. It ticks for each epoch and emits a fragment of randomness. So, we can rely on it for real-time reference. Also, by the way, my colleague presented a time- locked encryption scheme at the Real World Crypto conference.

So if you want a more in-depth explanation of how it works and all the details, you should definitely watch the encryption talk on Real World Crypto. Delving a little further, how does time- locked encryption work? Well, it's simple. Complex mathematics, perhaps, in short. For those of you whose eyes are already glassy from school and discussing such things, don't worry, we won't go into that.

I've , uh, simplified it a little bit more. So, I said on one of the first slides that, first slides that, uh, BLS 12-381 supports a pairing operation. This is essentially using some mathematical properties of an equation, which allows you to move different things around without changing it. So, time- locked encryption works a bit like traditional asymmetric encryption. In traditional asymmetric encryption, you have a public key that you use to encrypt plaintext, and the result is ciphertext.

Uh, and if you take the ciphertext and some secret key that's associated with the public key, you can combine them and decrypt the ciphertext to get the plaintext. What time- locked encryption does is essentially turn a random number into a public key, and the signature generated from that random number into a private key. So, as I said before, in the non-chained mode non-chained mode , since each beacon is not connected to the previous one, we can predict the exact message and the exact bytes that will be transmitted by the network in the future. This means we know this message already . We can use it as a public key to encrypt something.

And we won't be able to decrypt it until the DRand network releases this piece of randomness as a signature later. Uh, we've built some libraries around this, and also a cool web demo that, uh, you can try out. Uh can try out. Uh , it's called the Time Vault. It's a web application for encrypting vulnerability reports, so when you find all those Adobe bugs, even if you get taken down by a hitman, the world will still be able to find out what you found.

Uh, it's built using t log js. Of course, it is supported by the D run network. Uh, I'm not going to demonstrate it right now, but, uh, you can always open it in your browser and experiment with it yourself. All the code is open source, it's all on GitHub. Uh, and there's also a preprint article if you want to know how it works.

Uh, before we get to the Q&A, I'll do a similar, not- quite-t demo of log js. Again, we have some integration tests there integration tests there . I think they give the clearest idea of ​​how to use it in practice. Uh, but essentially, we're bringing together multiple clients here for the main and test networks. There is a function called time lock encrypt.

You pass there the round number you want to encrypt to. There is also a tool to match the round number with the real time and vice versa. And there's also a time-locked encryption feature that also accepts the client and your encrypted text. It supports asymmetric encryption with a tool called “age”—a called “age”—a really good encryption that works and looks a bit like PGP. If you've already filled the time storage, you can see that the result of the ciphertext here is a cool file encrypted via age encrypted via age , which again looks a bit like PGP looks a bit like PGP ciphertext.

So I encourage you to get involved, check it out, and try all the libraries. Fortunately, I left plenty of time for questions and answers. So if anyone has any questions about time-locked encryption, I'm ready to listen. I see...oh, there are a few questions in the chat here.

Is the length of the generated random numbers fixed? Yes random numbers fixed? Yes , indeed. This is a SHA-256 digest, so it has a fixed length. Hypothetically, you could also create your own function to derive a hash key based on the signature.

By the way, someone in the community has already submitted a request (PR) for this in the D Rand repository, so there are some workarounds if you want to see how they did it or come up with your own output function. Tony asks: will this be available online? It depends on what network you are using. This is already available in the Cosmos ecosystem through the NOIS network. This is N O I S.

Also, random numbers D Rand are included in each block header of the Filecoin network. So you can access them via the pre-round opcode if, for example pre-round opcode if, for example , you are creating an FVM actor. This is not currently available out of the box in Ethereum, although as I mentioned, there is a project called RNGesus (because of the G, not the J) that has created all the appropriate bindings to implement this in Ethereum if you wish to do it yourself. Unfortunately, BLS operations are a bit expensive as they are not currently pre- compiled into the EVM, but there is an EIP for them, so if you need it, go and push the Ethereum team to adopt it. Max Ken asks: Do you have a link to the PR for the transform function to reduce the length?

I can find it for you very quickly. So...here's a useful link. You can find it somewhere here in the code inclusion requests, I'll pull it out for you. Yes.

Yes, this is from Mr. Gorman. Um, although there is also some preliminary work in progress... let's say, if you want to choose one of 10 elements, there is a cool project called derandomizer with an " called derandomizer with an " s"—the majestic British spelling British spelling , not the American one— , not the American one— that provides a toolkit to do this task properly, to avoid modulus drift and other problems. So it's worth getting to know it.

I didn't add a link here, but again, you can find all sorts of projects in the derand organization on GitHub. Suraj asks, “ GitHub. Suraj asks, “ Where can we find use cases?” I've joined the list, not sure if this has been discussed yet." Um, well, that's up to you at the hackathon, of course.

Um, some existing use cases we've seen: there are people making games based on drand. For example, for random item drops or defining variables for certain NFTs for game objects—this is one example. We also work with Social Income, a non-profit organization that provides an unconditional basic income in Sierra Leone, and they are trying to use drand to randomly select people who should receive this income. We also developed a sample application on drand called D raffle—it is essentially a lottery application for determining winners via a smart contract. Some other possible uses are time- locked encryption.

A very interesting option that can be challenging for a hackathon is preventing MEV ( preventing MEV ( maximum extractable value extractable value ). If you could, for example, encrypt the blockchain mempool with a time lock, you could stop miners from changing the order or ignoring transactions for their own benefit. Other uses: anything that requires a fair lottery, or in the world of time locks— time locks— wallet recovery wallet recovery , automated " , automated " dead man's switches" or auctions. I'm sure there are many more ideas you can come up with that I have n't thought of yet, and I hope so . I look forward to what you create.

How can we get your slides? That's a great question. I will provide them through the organizers of Hack of Fest the organizers of Hack of Fest . Not sure if there is a centralized channel for this. I can also upload them to IPFS afterwards and publish the CID so people can get them.

Ahem. Yes, of course, if you have any more questions, you can write to us on Twitter. We are also in Blue Sky Twitter. We are also in Blue Sky , so we are trendy and modern. And here's a link to our Slack workspace.

Many discuss the different, well, use cases and cool things they're building there. So, feel free to join. Hey Patrick, yes, regarding the slides, if you want to post them in the Discord channel, that could be an option too. That's actually the best idea, yes. I will do it right after the performance.

Wonderful after the performance. Wonderful . Do we have any more questions from the chat? Well questions from the chat? Well , if so, then thank you all very much.

Thank you for your attention. I hope to see many cool apps built on this, and if you have any questions—find me, write or tag me. And hopefully I can answer them. Oh, there was, oh, there was the last question. Can you talk about the future of file encryption?

Well, one cool idea about time-locked encryption that we would like to implement is a proof system on top of it. There is no way to link if I encrypt something now to prove that what is inside is exactly what was encrypted. This is a big research project research project , and it would be a lot of work for a hackathon, but if someone did it, it could win a prize. But anyway, thank you very much and happy hacking. See you later.

Thank you, Patrick, and thank you to everyone who joined. Good luck hacking this week, and see you at the next workshop soon. See you later. Goodbye. See you later.

Goodbye, goodbye.