 Okay, perfect. Thank you. So hey everyone, I cannot see you. I'm like good afternoon and like good morning If you're like following remotely as I am and today as like Patrick mentioned, I will be presenting a Rust implementation of like time-lock encryption and especially like a like simple time-lock client Usually I like like on my daytime work for Cloudflare like this was like a personal time work and Yeah, I will carry on on that Many the next 15 minutes, maybe less We'll see how that goes given like this or some time constraint So I will start with like a small demo. So like you have like a high overview of what has been built But then we'll go over like some decision and design in terms of like the CLI Will continue to dive deeper in term of like how the time-lock API has been like designed and like changes it involved Compared to the current implementation and then finally there will be some final words. I Mentioned the CLI is like built-in Rust But really this presentation is not that much better like which language this like this API has been built in more Into like the design consideration to move like how I wanted to make it easy and how I wanted to use like like time-lock So, yeah first like a short demo which is not going to be a live demo because I don't need to change screen But it's going to be available some like backups So in to move installation you can install it with cargo, which is like a Rust package manager There's also some pre-built which are like Provided and so you just install D which is D like a short short comment for that Then what you can do is like you would need to add the remote chain So the remote chain is for instance like fastnet, which is the latest DRAN mainnet Which allows for time-lock encryption. So like here would use like the clariflux like endpoints with a long hash that I don't want to print because it's too long and in any case You would just copy paste it and not read it from here So you do D remotes, which is the way to management and you get fastness. That's it Then you want to retrieve some randomness. So you would retrieve some randomness for fastnet So like fastnet is your upstream. Therefore, I have a dash U. DRAN dash U fastnet gives me the randomness That's that's it. If you want to encrypt towards the future You would like have a message and I'm like hello D that you would encrypt Let's say 30 second in the future. So and put it directly into a file Like nothing more. That's very similar to like existing command and we will go into like these choices later down in the presentation Of course if 30 seconds have passed you're now in the future compared to like 30 seconds before and you can decrypt What happened? So you'd say decrypt you decrypt And you decrypt the file that you've saved and that's it like hello D That the same. Of course, there's not like the like, I don't know, shininess of if it was like live in a terminal But like definitely you can do it like run the exact same command and have it performed. Hopefully exactly like as I present here today Great. So you have like a No overview of like the CLI and now we will like start to dive a bit deeper into more like why these command have been chosen and like how it has been designed So first one saying I didn't want any default on the CLI And this is for like many reasons But like one of the reason is like if you put like to like default Then it's like very hard to like remove it or like if there's my API changes You have some stickiness and etc and so D is like meant to like have configurable remote and Provide the list of remotes you can use depending on your use case But doesn't set any default therefore when you do like D remote ad main net and your your main net endpoints So in this case protocol lab endpoints, then you can choose which Like which remote you want to use it's also very useful because you can like easily switch between like various networks and That works. It's very similar to get and will go a bit more of that down the line Another thing is I wanted to have like my one thing I didn't have in the main d-rand client It's like it was like very hard to like understand What was the time of the beacon? What time was left or etc? And so I wanted like slightly more like output on that and so you have various output level on the d-rand Command for instance, so here I will have like a dash L which stands for dash long And you have all that in the documentation But that gives you for like the latest round all the information that you want So like the round number the relative time compared to now like to the time of the current machine when this Around was produced the exact time the randomness the signatures and this is really meant for like human consumption You have also way to consume it like for GCN APIs or etc, which I would present here, but really Everyone should have like a different output depending on the use case and so that's what this is providing In addition, there's like some like informative errors So like when I started developing D It was at the time where like they started to be like a switch between G1 and G2 So I think Yolan explained a bit earlier and so sometimes for instance like here if you use a main net It cannot like encrypt because you need to use unchanged signatures Similarly, if you want to like decrypt a bit too early You need to know when you can come back to actually like be able to decrypt So there's like a lot of like work that has been done on like the error message so that the users always know what is happening and Finally as I explained before there's like some mimic for existing CLIs CLI similar to like websites or etc like this kind of like a lot of taste that is like being put into them and Really in terms of like this being a personal product I didn't want to just overextend in like creating a whole new CLI design in the CLI so I just Got a lot of inspiration from CLI that I know and I like and so like the first one was kit for the remote management Therefore, like it's a remote so you can like show the detail for specific remote add it change the URL whatsoever Similarly for like the encryption And because like we were using age for the the hybrid encryption Yolan presented before The CLI has like exactly like the same parameter So like if you want decrypt you can like decrypt like with like armoring and like take Content from sdn takes content from the file really depends but like it's the very similar If it's similar pattern, the only thing that has changed is the recipient instead of like being a file key or like a Naged specific thing. It's a time because that's where you want to be able to decrypt and Finally, well, I obviously took some inspiration from the around because the clients like of it existing This kind of like is inscribed in this ecosystem And therefore like you can like specify a specific round and get the randomness for that round the main net Some output for Jason if you don't put the round you get the latest one Just normal thing some very specific rest Resdev tooling that like we're helpful through these development Clap is definitely very good for having like inline like code documentation as well as like documentation for For the end users and it's also very helpful to like generate minepages For for your CLI and so that's what I've been using in in D Another thing which was like super useful is like the cross-compile Like ability lack of rust and like the fact that like without using upon SSL was like a lot easier to target for instance wasn't And that's one of the same wanted to mention and finally in term of like the performance and the crypto API There are two libraries that like I considered. I started using like ZK crypto and then I switched over to like artwork and one of the concern for that why I did that was like for performance Once again, it's a personal product. I wanted to like to try them out And so like cargo provide like some benchmark Features which were like very helpful in some of like Getting informed in for like getting informed guests in some of like which one is performing better Is there some degradation? Should I tweak some of my algorithm now? I will go over a bit more detail when we discuss time lock in term of like what's the difference between the two and Yeah, now it's time for time log and one of the things with time log is like it's great to like have the capability Like in the paper for how to do time log, but at some point you need to like implement it and there's a lot of trade-offs They were already trade-offs in the CLI and now there are like some trade-offs in the API So one of the main thing I wanted is I wanted this API to be able to work offline And what I mean to be able to work offline Doesn't mean that like I will need at some point to pull the signatures from the Iran but maybe like as your line mentioned like BLS and I be Encryption is like an old idea and maybe like I will get my signatures from the file Maybe I will get it from like a peer-to-peer communications and I don't necessarily have a deer and client So if we do compare the API like in go and in rust that I've implemented In go you have like T lock client Which like takes a destination. It's move like why you want to do the encryption to you have like a source Reader from like where you get your information that you want to encrypt and then the RAM number In a rest it's slightly different We have exactly the same three like first three parameters But there are two additional ones and the two additional ones are the hash Which is the hash of the chain we encrypting to and the public key that we're going to use and these are important Because if we actually take a look at like how these functions can be used in both go and rest It seems rust is a like a lot more furbows And it's not because rust is furbows because it's been like the API has been designed this way in go We first take like the network, which is API to the random SH Well, there's a bit of a hash, but that's the idea then we need instantiate the T lock client and then we encrypt and that's it the source Buffer would be encrypted to the RAM number and like put into the destination buffer The thing is while doing that. There's some side effect that happens I feel like the T lock client will make a fetch to retrieve some information about the chain and the encryption to API to the random SH and this is Like not really transparent I'd say in some of like the user won't see it but like there's some side effect and things that will happen in the background and I really wanted to make that explicit and so What happens in rest and like you would like declare a chain which is like the equivalent of the network You would declare a new client, which is a T lock client And you like as a user need to retrieve the info before calling the encryption Method so then you pass like exactly same time. It's not the destination the source around number but you now have the info and the hash public key that you can pass to the encrypt method and Apart from like being super easy in some of like development because it's much easier like to Debug what happens here because you don't have to mock the API client You could also retrieve these information from a file for instance If you like it's being shared or you could like retrieve some like of these information from something Which is not the rent while exposing the same BLS primitives And that's one of the things I like the main difference in some of the API design Then there was a whole question of like interoperability And so one of the amazing thing about d-rent and like the time lock is the team is committed to have multiple implementations And so they have two implementations For T lock one in go and one in JavaScript Both of them are interoperable. They have different goals. Like the T lock is really for like a CLI Use case and like local use case for like back-end while like the T-locked is has been made like kind of like wonderful With the example of like time vault dot d-randop love And I wanted my implementation to be compatible with those two So we just don't create a fork and there's no reason why for now we cannot be compatible One of the things that like I encountered is like the rage Implementation so it's like the rust implementation for age adds like an additional parameter to like the file which like just makes it incompatible with the format that like The go or the jazz implementations are using and this was due to like a small Like over constraint that was put in those two clients and so this has been fixed like very fast by the d-rent team and so definitely thanks for that Another more I don't know low level implementation The detail that was interesting is like how like the crypto is implemented and definitely I want to thank People that like worked a lot on like the hash to curve RFC because both in terms of like the explanation to How like the crypto like is being performed in various libraries and the specific method that like we wanted to see which is hash to field and expand message. It was just Super smooth to reach through that. I think like the Normal like libraries implementation do a great job of like making the documentation Explicit but the fact that like there's an FC that like also gives a lot more context to two more newcomers It was like just awesome to see that and very helpful to understand what was happening in both like the T-lock The go implementation in the jazz implementation and how I could make it compatible However, this RFC standardizes a lot of things but one thing that is explicitly not standardized in this RFC is how like elliptic curve field Serialization works and this is not standardized and the fact that it's not standardized is also interesting because like most of the libraries Just have a different serialization strategy. So for instance, some of them will serialize like in FB 12 So it would serialize the fields in one order while some will just like do it in like the reverse order Which is something which is sometimes mentioned sometimes not mentioned Like you just look at the code and see how that goes and when the abstraction is like hold on from bytes or like two bytes You don't really know what's happening that another like consideration was like if it was like big engine or little engine Which changes like the order of the serialization Most of the like crypto library like make a good job at like distinguishing the two and actually being compatible was like big engine and little engine But that's one thing which was also like needed to be like like careful about when working with interoperability considerations And that's it some final words in some of like where could we go next what could happen different In some of like what could have been different because it's been like a lot of trade off I think down the line The fact that like DRN exposes like a big chain of API is not super friendly when you need to actually add the information into a CLI or pass it to like also developers And given like the main T look interface is HTTPS something You may need like possibly like you could have like a dedicated like hostname so that you directly connect to the chain That still we need like some confirmation on the user side that they expect a chain ID and etc that they want but it's much easier to add later down the line Similarly for like the stanza format and so stanza is like the way for age to encrypt like to encrypt information and put information in the file kind of like metadata For the file that you encrypting for now like you have like a mandatory round and a mandatory chain hash but to be honest you could also consider not having them I think there's an issue in DRN to like possibly Like consider like either remove them or like have them more privacy preserving because like the round you could have it like stateful in the client and like the client could pass it at the time of description Similar to the chain hash you could pass it at the time of description. So this might be like interested to like redact them Finally in term of like the CLI there's some states for the CLI like I wanted to like save the remote beacons Maybe we want like a stateless CLI so you could like either pass directly the full URL every time you're performing operations or you can pass it as environment variables I still do prefer like the state for one but that's a consideration down the line that I could make Finally in term of takes a ways. Well, there's now a new DRN implementation and new T-lock implementation. Boston Rust that is available There was some of the learnings is like definitely one academic papers but like the lots of engineering tradeoffs and that's one thing like I learned through this process of like one API might not shoot Everyone needs despite being working on the same technology A third point I wanted to make was T-lock is not really constrained to the DRN API for now it's been really sought was like kind of a demonstration that you can use like time lock was the DRN API But as mentioned before you may have a server that like does exactly the same thing and therefore I didn't want to like look in the DRN client With like the time lock decryption and finally I want to thank everyone that like answered the multiple questions I had During the implementation process should be on Slack via emails or discussions and that really improves the way like software is made and like really enough for like fast development process And that's it if you want some more information there's a lot more information and documentation on the repository and if you have questions I'm happy to take them Thank you