 Hey everyone and welcome to today's Protocol Labs Research Seminar. Today we are joined by Yolan Romier, I hope I haven't butchered that. Yolan is an applied cryptographer delving into and mostly dwelling on cryptography, secure coding and other fun things. He has pre-release spoken at Black Hat USA, B Slides, LB, Crypto Village, NorthSec, GopherCon EU and Defcon on topics including automation in cryptography, public keys, vulnerabilities, elliptic curves, post-quantum cryptography, functional encryption, open source security, distributor randomness and many more. He introduced the first practical fault attack against the EDDSA signature scheme and orchestrated the full disclosure with the code of the curveball vulnerability. These days he's working on the distributor randomness projects, namely DRAND, studying paired-based cryptography, distributed key generation and threshold systems. So at this point I'm going to hand it over to Yolan and off you go. So yeah, hello, I'm Yolan. Today we'll be talking about time lock encryption based on DRAND. So I will start with some intro just to make sure everybody understands what DRAND is and who that kind of works and then we'll dig into the time lock port actually works. I love digression so I'm going to start with one. I don't know if you know what randomness is but according to the Cambridge dictionary, randomness is simply the quality of being random. Yeah, that's right. So that's very useful. Actually, I kind of prefer to see randomness as being the quality of being unpredictable and of lacking any patterns, which also happens to be the way some other dictionaries are defining it, which is a bad way to define it, I think. With the notion of randomness and lacking patterns and being unpredictable, we can already guess it must be hard for a deterministic computer to do that, right? So getting randomness is usually hard because we are not using true random generators in our computers. So you have truly random processes in the physical world that we could be using to produce true random numbers or strings. It's often not the case. So a computer will usually use jitter or what you've typed on your keyboard or mouse movement and it will gather some entropy and then it will start using CPRNG, so cryptographic pseudo-random generator to produce random numbers. And actually, we had a very interesting talk about it in a previous session, I think. So I guess there is a recording somewhere in case you want to check it. And I like to say randomness has different kind of flavors, like secret, probably very stable and distributed. And so we'll quickly see what these are because it's kind of important for the next part of the talk. So public randomness is basically just a value that is meant to be public. It's really exactly what it is. So if you're playing a lottery and you can see on TV those people like growing random values in a big bowl, throwing the bowls with the numbers on it, that's a way to throw a public random value. And public randomness is really just that. It's just meant to be public. It's a random value you throw to and then you can publish it. What we're more used to, even maybe unknowingly, is the secret randomness because that's what we use to produce secret keys, nonceas, initialization vectors. And our computers are actually doing that multiple times a day, like many times a day, because every time we establish a TLS connection with a website, what's happening behind the hood is basically that the browser will establish like fmrl keys. It will create fmrl keys using secret randomness and so on. And the thing with secret randomness is that it is meant to stay secret. If you link the secret value that was used to produce a secret key, then you don't get any security. Same goes with nonceas or IVs and so on. So secret randomness is really meant to stay like secret. Public randomness, which is public, is kind of cool. But actually, if I were, you know, today to just say, okay, let's run a lottery. Here you buy tickets. And then suddenly, I don't know, like, it's Patrick, my colleague in the Duran team was winning the lottery. Everybody in the room would be like, hey, Yolan, you cheated. Patrick is a good pal of you. You made him win. If I don't get any way to prove my randomness was actually random, I would lack any way. I couldn't tell you no, no, I didn't do anything. I got nothing up my sleeves, right? So that's where the notion of verifiable randomness comes in. And it's quite interesting. So the idea behind verifiable randomness mostly makes sense when you want to draw public randomness, but you also want to achieve some kind of, you know, auditability. So people can see you didn't cheat when you draw the public randomness. These notions were, you know, useful, but even more interesting when we're talking about distributed randomness. Because when we are looking at blockchain systems or at distributed systems, achieving consensus on a random value is difficult. Already achieving consensus on, you know, in general can be difficult. But if you want to achieve consensus on a random value in a way that prevents any actor to bias or influence the final randomness, you cannot just say, oh, we'll be using, I don't know, the XOR of some random values because then you have a last player attack or that kind of things. So in general, producing random values on a distributed system, especially on blockchains or for smart contracts and so on is difficult. When we're talking about distributed randomness, we're also usually talking about decentralizing trust. So we don't want to be, we don't want to have to trust any single party. So for example, we don't want to trust NIST to be providing us with proper random becomes because NIST is running a public randomness service, providing public randomness to anybody asking for it. But do you really trust NIST? Good question. Usually in the blockchain space, we don't. In the cryptography space, we don't necessarily trust them, either, right? So I mean, they've been doing weird things in the past with randomness, right? So distributed randomness is quite important. That's, oh, DRUN came to live, actually, to life. So DRUN was initially a project from a university, EPFL, and then it was picked over by Protocol Lab and it was launched in 2019. So DRUN is meant to be basically just like DNS or NTP sellers. It's a way to get public very favorable randomness easily without trusting anybody. DRUN is just an open source software, okay? So it's a software that you need to run on multiple nodes that connect together to form a network. And then you can pull randomness from a DRUN network and you can verify that randomness and verify it was properly generated. And as long as you trust there is never a threshold amount of malicious porties on a DRUN network, you can trust the randomness produced by DRUN is actually random. So DRUN has actually been tested, audited, and deployed in practice. And it's been running since 2020. Actually, we've just passed the two years milestone in August. So DRUN is currently being run by the legal philanthropy, which is made of 16 organizations, organizations with 23 nodes. We had zero disruption and zero downtime for the past two years. So it's pretty good. It has shown it's working as intended. And we've produced over 2 million random beacon so far. DRUN is a legal philanthropy. Mainnet is currently producing random beacons every 30 seconds. And these are served over for HTTP relays provided by Cloudflap and Protocol Labs and also through PubSub if you want to use Gossip instead to get your randomness. So now that we know there is a service providing distributed randomness consistently for the past two years, we can move on to our time lock encryption scheme. So what is exactly time lock encryption? So time lock encryption is exactly what it sounds like, right? It's being able to encrypt something that cannot be decrypted until a certain time has come. So for example, if I'm encrypting a message now and I don't want it to be decrypted until Christmas, I could do it using a time lock encryption scheme if I have one. And it's also sometimes called time lock encryption or time release encryption. Some people sometimes do a new saying, okay, there are like time lock puzzles or there are like time release encryption because sometimes you can encrypt something that cannot be decrypted until at least a given amount of time has passed. But it doesn't mean it can be decrypted immediately once this minimum amount has passed. It can be like a minimal bound. It's not like the upper bound or stuff like that. So sometimes there are some nuance in the literature. Time lock encryption is quite interesting to do a lot of things. You can do sealed bid auctions where every participant is encrypting their bids and the bids cannot be decrypted until the final call for the auction comes. You could also do math prevention like you're encrypting the transactions and so you could have like services that are ordering transactions on some kind of services that are validating the transactions. And two services doesn't necessarily need to be the same. And also the transaction could maybe be encrypted in some part of the system. So time lock encryption has a lot of interesting applications in the blockchain space. Also like conditional transfer of wealth is really easy in the blockchain space. Like you can imagine you just encrypt your private key, like your private Bitcoin key. You encrypt it with a time lock encryption scheme. You say we cannot decrypt it until I don't know when you're in the future. And if you're still alive in one year, what you do is you transfer your funds to a new address. And so the secret key you time lock is useless and so nobody can get it. But if you happen to die or whatsoever, if something happened to you, the people who get the ciphertext could then decrypt it and recover your funds. This has been already discussed quite a lot on the internet. It could also help with electronic voting. And also quite interestingly, it's very useful to do, I don't know, like disclosures or when you have a known embargo period on a document, like if it's legal documents or if it's, yeah, depending on the context, you might want to encrypt documents so that they cannot be decrypted until a certain time has come. But as soon as the time has come, you want them to be publicly available. This is pretty cool because it means you can release documents that are encrypted upfront and you don't need to do anything in the future to enable people to access them. They could just take the ciphertext and decrypt it as soon as the time has come. So this means you can have non-interactive embargo and documents. Another few fun possibilities with time lock encryption could be responsible ransomware. I really like the idea where instead of encrypting your files forever, the ransomware would be like, hey, either you wait six months or you pay this amount upfront and you get your files today. I think it would be like, you know, more unassured ransomware could be nice. So if you're developing ransomware on your, you know, as a hobby, please consider using time lock encryption. Also, there is a paper actually considering using it to escape emulation. Like, you know, you have a malware that is being analyzed by an antivirus. The antivirus is sometimes trying to sandbox it or to do emulation of the binary. So if the binary is containing a payload that cannot be decrypted until a certain time has come and the binary could look like, you know, armless when it gets emulated or analyzed. But suddenly at some point in the future, it could be able to decrypt its malicious payload and do necessary things. So that was an interesting paper that came out a few years ago. To give you some insight into how time lock encryption came to be, I think we need to look into how it came to life, right? So time lock encryption, the ID is actually fairly old. It's coming from team May 1993. So you may know team May because it was actually the father of the crypto anarchist movement. And he published the time lock encryption ID on the Cypherpunks mailing list. So pretty cool stuff from, you know, almost 30 years ago. At the time, the main idea to solve time lock encryption was basically, hey, you just pick a notary and you convince them to not release the encryption keys until a certain time in the future. And then you trust them to not do it. And if they're behaving nicely as notaries should, you've got time lock encryption system. That's not so cool because it means you have a trusted third party, right? So in 1996, Reader, Shamir and Wagner actually proposed another solution to achieve time lock. And their solution was actually a proof of work system. They introduced the notion of time lock puzzles, where you need to basically grind, do something like computation that takes a lot of time to do sequentially. In that case, they were using a squaring. So you had to square a number, like modular squaring. So you had to square a number multiple times in a row until you achieve some value, which would be your secret. And you can, you know, parallelize the computation. So it should be ensuring anybody that you spent a minimum amount of time on that puzzle before you were able to solve it. In that paper in 1996, it was quite interesting, actually, because as I said something, which was basically, there are only two natural approaches to implementing time release and cryptography. These were using time lock, so proof of work, or to use trusted agent, like the notaries from 1993, from Tim May's initial email. That's actually not how we do it. So we're pretty happy about it, right? In 1999, run rivers actually created a time capsule that was meant to, you know, to keep 35 years to break. And that time capsule actually was broken only 20 years later. So in 2019, two different teams broke it. So on one front in April, there was a guy running it on his computer for like three and a half year, and he was able to break it. So it just means the hardware got much faster than rivers expected it to become, like 10 times faster. So that's, you know, it's difficult to predict the future, right? In May, a collaboration between Ethereum Foundation, Supernational and Protocol Labs actually used FPGA implementation, so hardware implementation to solve it in only two months. So this is really, really fast. So it was something that was meant to, you know, take 35 years to compute, and we were able to do it in two months in 2019. So proof of work based system are very sensitive to hardware advances and to hardware, you know, evolution in general. There are a lot of other proposals to achieve, you know, like some of them are based on Bitcoin proof of work using the basically the Bitcoin network as a cryptographic clock. Some of them are using other IDs. And most interestingly here is the last one about how to build a time lock encryption, because that one is introducing the notion of computational reference clock or cryptographic clock. And it's also using identity based encryption to achieve time lock encryption. So this is actually very close to what we're doing here today in our time lock encryption scheme based on DRUN. The problem with most of these pre-orbs and most of the stuff I've just presented you is that either it's proof of work based. So it means you need to do a lot of computation and you're burning the planet, which is not so great. And also it's very sensitive to specialized hardware. So it's also not so great because it means if you want to produce a time lock puzzle that is both able to resist an attacker for 20 years, but also that anybody can compute in 20 years, you won't get there without providing these people with specialized ASICs, which is kind of painful. And then it would mean these people would need to run the ASICs for 20 years to be able to solve your puzzle. That's amazing. Some of the other proposals are using cutting edge cryptography like they are, I don't know, assuming authentication or assuming some other stuff that is not so practical. And so we come to that impractical point. So obfuscation and amorphous cryptosystems in general are way too slow nowadays. So maybe we'll get there at some point in the future, but currently it's not very practical. And also all of them are not actually deployed in practice. I mean, there are some proof of concepts using Bitcoin and there is another paper from 2009 that was saying they would be providing an open source implementation also like a public service to be able to do time lock encryption using that service, but they never provided it. So none of them are actual deployed. So that's how we came to look into implementing and providing a service that would be live. And that's what we did actually. So currently, that's our goal, right? We are right now and we need to be able to encrypt towards a future time. Here, I represented some cryptographic reference clock ticks. It's funny because that looks exactly like what DRAN is currently doing. Because DRAN is currently producing randomness at a given frequency. So currently it's every 30 seconds. You can trust the DRAN network to not produce randomness too early because that is definitely not the goal of the network. So it would break the trust people in the network. So the League of Entropy has no advantage breaking that trust. And also it's pretty cool because you can predict which run will be at what time in the future. So you can say, okay, in five minutes, we will advance exactly 10 rounds, stuff like that. Now, can we achieve time lock encryption based on DRAN? The funny thing is DRAN is based on the BLS signature scheme. So actually, a DRAN beacon is made of a signature, a BLS signature. That BLS signature is then asked to obtain the randomness. That's how we achieve very high probability of the randomness produced by the DRAN network. And the really nice thing about BLS is that actually, BLS signatures are related to identity-based encryption because in 2001, when Bonnet et al. produced their identity-based encryption based on the whale pairing papers, they noted in that paper that actually, you can also use pairings something similar to identity-based encryption to do signatures. And two years later, they released the BLS scheme, which is doing exactly that. What they noted in 2001 was that basically, if you reveal the decryption key of your identity-based encryption scheme, it's equivalent to being a signature because you can verify it under the master public key. That means that currently DRAN is releasing every 30 seconds an identity-based encryption key. We can use that identity-based key to decrypt messages. The question is what kind of messages and the answer is basically whatever is getting signed by DRAN. This is how it works. Don't worry. I'll actually try to break that down into simpler steps. So first, we need to recall BLS signatures work. We have a public key, P, which is basically just a secret S time a generator G1, which is on the group G1 because BLS signatures are based on pairing. So we have two groups, G1 and G2. Here, S is basically just an integer. P is a public key. It's basically like ECDSA or ADDSA. It looks like elliptic curve standard signature schemes, except we'll be using the pairings to do the verification later on. DRAN is actually hashing the epoch it wants to sign and is just signing it. DRAN signature is basically the secret time the hash of the prorion. There is one trick. So it's that DRAN is actually using a threshold BLS like setup. So it means every node is producing a partial signature, which is here represented as PI, which is equal to SI, the secreture of a node. And it's just every node is going to be signing the same message. So we have the hash of the epoch, which is a message. The signature with BLS, the BLS scheme we're using here is actually on G2. You can do signatures with BLS either by the public key on G1 and signature on G2, or you can do it the other way around with the signature on G1 and the public key on G2. But here we do public key on G1, signatures on G2. DRAN is then aggregating all of the signatures together to get the final signature. But actually, the final signature is still a BLS signature. So it will be basically S, the secret of the whole network, times the message. So the message here, it was the hash of the epoch. To do time lock, what we'll do is basically we want to be able to map from the different signatures to the IB encryption scheme. And so to do that, we need to take QID being the hash of the epoch. So the identity we're encrypting towards is basically the hash of the epoch. The nice thing about pairing is our billionaire. So what it means is here that if we have the pairing of G1 with a signature of a message M, the pairing of G1 with P is actually equal to the secret S times the pairing of G1 on the message. These maps naturally to the public key, because if we take the pairing of the public key on the message M, we will get that the familiarity means both are equal. So that's all BLS signature work. They verify basically that the pairing of your signature together with the generator will be equal to the pairing of the public key together with the message or claiming to have signed on it. That's the gist of the idea, right? But that is really nice because it also looks a lot like a key agreement. So it means we can agree on some common key easily. The problem being anybody can easily compute the pairing of the public key together with a message and get your assured secret. So you can use that directly to obtain a shared secret. You need some extra steps and to ensure secrecy, we will need to add the notion of ephemeral key to mix. So we will have a random value R. We will compute its ephemeral public key. And now we can compute R times the pairing of the public key together with the message. And that is going to be equal to R times the secret of the group, which we don't know, right? Times the pairing of G1 and M. And when we get the signatures, if we know the ephemeral public key PB and the signature, we can compute the pairing of PB together with the signature, which is the pairing of R times G1 and S times M. And so that is by billionaireity, it's equal to R times S times the pairing of G1 and M. So that's exactly key agreement basically. We have two different ways on agreeing on a common reference string on a common key. And that is, oh, we do time lock here. So we compute GID as being the pairing of the public key of the group together with the hash of the code, which can be pre-computed because it will be the same for everyone. Then we choose a random mask, sigma, we set the nonce or whatever you want to call it, the ephemeral secret key maybe. We set the ephemeral secret key to R being the hash of the mask together with the message. So it's unique. And then we output the ciphertext U being the ephemeral public key R times G1, V, which is basically just a commitment to the mask, sigma, that you've got parallel. And then W, which is the message, XORed with the hash of sigma. So this is basically a one big part of the message you want to encrypt. And this is actually coming from the IB paper from Bonnet or from 2001. So that's a nice thing here. It's that we've been able to map directly to the paper, not using anything new, not changing the scheme whatsoever. So we can directly benefit from the secret analysis from that paper. So we get CCH secret. And then to do the encryption, as soon as you get a signature for that echo, so if you get P of rho, you can compute the hash of the pairing of U. So U was the ephemeral public key. And the pairing of U with the signature will give you R times S times E. You hash it, you XOR it with V, you get your mask sigma. You can hash the mask sigma to get your one time key. You hash it with W, you get the message. And you can verify the commitment. You can verify everything was computed correctly by computing the value R out of sigma and the message. And you can verify the ephemeral public key was actually produced by R. And then you get the encrypted cycle. So it's really easy to do. And it is also directly based on the ID paper. So the initial ID didn't change here. So we are working on a preference about the details behind using the RAND as a time-locked encryption scheme or service, rather time-locked encryption service. There is a link here to access public Notionsite about how we do it with all the math and a few details about how to work. So I'll be releasing the slides on my website and I guess we can link them on Twitter or yeah, and we can also link them somewhere. So it should be fairly easy to get the slides on the link if you want to. Because that's quite difficult to copy, I guess. We had a few problems though to do time-locked encryption using DRUN because DRUN was using chain randomness. So each message was linked to the previous one because it was the hash of the RUND. RUN contained it with the previous signature, which means that nobody is able to predict the next message before the RUND, just before it. But actually from a security point of view, if you've been able to compromise a threshold number of nodes and you've got the secret key of the group, then you can regenerate all past messages and it doesn't change anything. So you could get all the past signatures you would need. So it's not actually bringing match in terms of security. And also it's making the verification of randomness more complicated because you need to know the signature of the previous message in order to verify the current RUND. So it was a bit painful and we could solve it easily by introducing Unchained Randomness, which we brought to the network in February 2022. So Unchained Randomness is currently running on test net on DRUN. Unchained Randomness is basically just we are signing the hash of the RUND number. So anybody can predict a future RUND number and that means we can use these ashes as the identity we're encrypting towards using the IB scheme I just presented. So it means also its verification is much simpler because under our security, you know, our trust assumption, if you trust, there is never a threshold amount of malicious 40s. You can trust that anything signed by the public key of the group is valid and so you can just verify the signature using the public key of the group. There is one thing though you may have noticed I was using a one-time pad between M and the hash of Sigma. So depending on our hash function or if we're using maybe an extended output function, we could encrypt more or less data. But most extended output functions are limited in terms of, you know, the size of their maximum size of the DGS and stuff like that. So how do we encrypt a 10 gigabyte file? We decided we would just be using hybrid encryption like everybody does, like PGP does, like a lot of people do. So what we do is we encrypt with AES the data and then we just encrypt using time lock the AES key we use to encrypt the actual data and don't need to worry about extended output functions whatsoever. We can just use SHA-256 or whatever Blake and that is enough to encrypt 10 gigabyte files because the actual encryption is done with AES or SHA-256. Actually in our case we're using SHA-20, Polly 1305. So it's authenticated encryption scheme and it's fairly fast. So we didn't really need to care about, you know, mode of operation whatsoever. Also it's got the RFC, it's well defined. So that's it basically. We had this proof of concept with the math and everything working since November or even December last year. And then we decided we really needed to move on and so we worked together with Arden Lab to produce a Go library which is called T-Lock. And then we worked together with Patrick to produce a JavaScript, well actually TypeScript library which is called T-Lock-js. Both are currently defaulting to using the test net because the League of Entropy test net is the only network running Unchained Randomness right now. We are planning to release Unchained Randomness on main net very soon. It should have been done in two weeks roughly. It will probably be postponed maybe a week or two but it's getting very soon. So if you want to try it out, you can already try it out using test net because test net has 13 nodes running. So you don't need to trust any single party. You just trust that threshold network running test net is not compromised. The threshold is on the sixth on test net currently. And when it will land on main net, we will have a threshold of at least 13 maybe more. We have 24 nodes currently running on main net, maybe more in a few months but currently that's the threshold we have on main net. So we also have a CLI tool which allows you to test it in the terminal super easily encrypting and decrypting with test net or you can specify your own network using flags if you want or if you're running your own Unchained Network at home because anybody can run a DRUN network. So anybody could launch their own time lock encryption service using DRUN as well. Just the nice thing about the League of Entropy is it's a kind of, you know, it's an old network running, produce distributed randomness meant to do a lot of other things which is kind of unrelated to time lock encryption. And it's really nice to be able to use the League of Entropy also as a time lock service. So I would say it's an argument to not launch another network but yeah, if you want to, you could do it locally as well. So that's the CLI tool. The inspiration behind the CLI tool is actually based on Aggie which is an opinionated encryption CLI tool made by Filippo, which you might know in the cryptographic community. And then we also decided it was not enough to just have a CLI tool but it would be much, you know, nicer to have a web demo. And so we created a time vault web demo where you can just go on your browser and it will be using the T-lock GS to do the encryption and decryption locally on your device. And so let me try it live, you know, to do a demo. So here we have the time vault website. We can show the time in the future. Let's say 45. We can say hello. We get an Aggie encrypted file because we're using Aggie behind the hood to do the in-grid encryption. So we didn't have to re-implement the world in-grid encryption anyway. So if I paste it here now, it will say, hey, you cannot decrypt it yet because it's not yet 45, right? And I could also try to do it in the terminal, I guess, by typing it into CLI and say decrypt. And I guess, oh, did I forget something. And now it worked because the time has lapsed. So if I try again the browser, it should also work. Hello, Pierre. So as you can see, this is currently running on TestNet, but still it's still a threshold network. It's still difficult to compromise, hopefully. And so it's working. If you want to trade or if you want to, you know, do something with it, you can start working on the development today. And you could be using the main net when we launch it in a few weeks. Yeah, pretty cool stuff. There are a couple issues, I guess, when dealing with the future. So obviously, new attacks. So we're relying on the IB scheme from 2001 and we're relying on BLS, both in the same security assumptions. So if somebody is breaking BLS or pairing base cryptography, then our time lock encryption scheme couldn't protect your data for the next, you know, five years or whatsoever. Also, quantum computers are obviously a threat because none of the schemes we're using here except for the hybrid encryption scheme. So the time lock part is not resistant to quantum computers. Currently, it's quite difficult to imagine doing a quantum resistant time lock scheme using the same ID because we don't really have the, you know, the nice properties we get with pairings with quantum scheme right now. And also not too many threshold crypto system that are quantum resistant. So if we want to not have a single trusted party and we want to decentralize the trust like we do here using a threshold network using quantum, assuming quantum computers, it could be, you know, difficult. Also, more computing power. I mean, that's naturally a threat for our scheme because Shasha is supposedly like achieving at least 128 bits of security. I think it's even way more. It could be like 256 bits, Shasha. And the BLS scheme we're using, it's, so the BLS implementation we're using is based on BLS 12, 381. So because, you know, pairings need very friendly curves. So that elliptic curve is currently believed to have the security of roughly 117 bits according to the latest tax and estimates. So I mean, as soon as we got more than 100 bits of security, we're practically safe for now. It could change in the future because attacks always get better, right? Don't forget it's a threshold network. So it's fairly decentralized. It's fairly resistant because we could do a resharing using the DKG. So it's a distributed generation as long as we have a threshold number of nodes available. But we can tell if the network is still going to be running in 10 years, in 20 years. We certainly hope so, but that's a very long time, right? We can't really predict what's going to happen in the next 10 years. So we, I wouldn't say that this time-lock encryption scheme is very useful to encrypt something for a long time in the future, but it's very useful to do sealed mid auction. It's very useful to do math prevention, anything that is like a few seconds, minutes, hours, days in the future is fairly safe. Also, there is a problem of governance with a threshold network. So what if the League of Entropy members decide to stop the network suddenly? So currently, it has not really been decided by the League of Entropy. And that's something we've been working on producing a governance model and publishing it. The question would be, is the League going to release all the keys, all the secretures, if it stops? Or is it going to burn them and destroy the group secret key definitely? Because that changes, right? The outcome. If you encrypt something for, I don't know, in five years, I mean, three years, the network says, okay, we stopped the League. Here are all the secretures that anybody could decrypt your ciphertext in three years as soon as the secretures got released instead of waiting five years. That could be an issue depending on what you encrypted. So we need, yeah, proper governance model to ensure so that user can choose. And I guess maybe we would need two networks, right? So one network that if it gets stopped, shares would get released. So people could choose to use that one. So there are shares or secret is never lost. It could be decrypted too early, but it won't be lost. And another network once the governance is basically, we delete the share if ever we decide to stop the network. And so whatever you encrypt is the network cannot be decrypted until the time has come for sure. Or it could maybe never get decrypted if a network stopped before. But these are difficult questions you need to ask yourselves when you're playing with thresholds services, threshold networks. And yeah, most credits go to the rest of the team actually. So the initial ID and the first proof of concept around the time lock encryption scheme was actually produced by Nicola Gaye. Then Patrick, my colleague, is behind all the JavaScript and JavaScript magic. Most of it, I only played with a crypto, the few crypto lines. And then we got the design of the Web demo by Julia Armboost, which is also a protocol lab colleague. And then also we want to thank a few people, such as Justin Drake, Jason Dunn and Phil, and also Alvin Lab because they were very useful during the whole thing. So we had comments about the scheme, some future work ideas. Also, with Jason, we had the practical idea that we could be using time lock encryption to do responsible disclosure. You know, when people go on Twitter and post the hash of their findings, what they could do instead is post the link to a paste being containing the time locked ciphertext. And even if they get hit by a bus in the meantime, anybody could decrypt their findings in 90 days or 120 days, whatever the responsible disclosure deadline they chose to use as lapsed. So that's a pretty cool, that's a pretty cool application, I think. And that's the one we presented actually at DEFCON last month in August. That's it basically. So if you're watching these and you're like, oh, this is a pretty cool project, I would love to help run a threshold service, providing time lock encryption, and also distributed public randomness. Well, the legal philanthropy is actually hiring new members, especially if you're in Asia or in geographies where we don't have too many people, because the goal of a threshold network is to be decentralized and also to never have a threshold amount of people, I don't know, running on AWS or running on on gcloud or whatsoever. So yeah, the league is trying to get more people to join and be more secure and more distributed. So yeah, don't hesitate to go on the website to run that lab if you're interested. Awesome. Well, thank you, Yola. That was very interesting.