 All right, so I'll be talking today about time-lock recovery factors. It's gonna be kind of interactive. We'll do some thought experiments and we're gonna start with like a toy problem and then the toy solution and let's see whether we get to something that works. So what are we really talking about? What are we trying to solve? The main problem we're trying to solve is that C phrases are bad, right? And C phrases contribute to loss, death, and even terrorism. C phrases are like a very long password, right? They're easy to use, easy to lose, sorry, easy to compromise. And basically when you write it down, it's like, you know, writing a post-it note, that's you basically when you write down a C phrase. And what we should really be using is multi-fact authentication, right? NPC or multi-six. And why we should use it is the outcome of decades of evolution in user authentication, right? Since 1986, people have been trying to push multi-fact authentication and it works. It provides better security, prevents phishing attacks and it's relatively easy to set up. So hopefully you also use this after this talk. And let's just talk a bit about NPC and multi-six. So most of you guys are probably familiar with multi-six and maybe a bit about NPC and both of them have very similar properties, right? They're both better than C phrase. They are more hack resistant. You have to compromise multiple factors before you lose your account. There's better redundancy. So if you lose one factor, you're still okay. And that's also the possibility of additional checks, right? Like a daily spending limit, for example. But there are some differences. So NPC is off-chain, multi-six usually off-chain as a smart contract. So multi-six can support much more complex access structures. Think like organizations, right? Thousands of people trying to vote for something. Whereas NPC usually costs less to deploy and operate because it's off-chain, so there's no gas. Multi-six also has trustless access to on-chain state. For example, pricing from dexers as well as like limits based on block time. Whereas NPC is cross-chain. But actually you can use both, right? One is probably more useful in like a large setup and one is probably more useful for personal setup. So NPC is probably more useful for personal setup. So I'll talk a bit very briefly about NPC because we need to understand this before we talk about even multi-six and how to use recovery factors. So first we need to understand how to share a secret key, right? Imagine you drew a line and the Y in the set represents your private key, right? Now you draw three points in a line and then you erase the line, right? And with one point, if you only have one of the points, you can't redraw the line, right? It's not possible. Any number of lines could pass through it. On probably two, you can redraw the line and recover your key. This is basically Charmé's secret sharing which splits a private key into multiple shares and by tying each share to some user factor, we can get multi-factor authentication on private keys. And where does NPC come in? NPC does all this except there is no line drawing and basically it avoids a single point of failure because when you're generating the key, if your device is compromised at a point in time, the key could be stolen whereas NPC just does that in a distributed way. For today, we'll just limit the scope to personal key management, but of course you can use NPC for other things as well, managing it in like an organization if you wanted. So the crux of the problem and what my talk is mainly about is there's this binary dilemma, right? Between non-custodiality and custodiality. What do I mean, right? We say a key is non-custodial if a user has full control of the majority of the shares. So let's say you have three shares, right? And you require two of them to reconstruct a key. As long as two of them are fully owned by the user, it's considered non-custodial since the user can easily move his key as well as use it, but no other person can control the key. Whereas a key is custodial with third parties, which we call custodians, right? Have control over majority of the shares. And it's pretty obvious that the above are exclusive properties, right? You kind of like two majorities. So either get non-custodiality or you get full custodiality. And there's some special cases, like if the user owns a share and third party owns another share, but let's not think about that for now. But realistically, wouldn't it be nice if we have something better? Ideally, right? What I really want is that my private key should be non-custodial all the time until I accidentally lost all my factors or touch food, I die. Then it somehow transitions to become custodial, right? So at least my crypto assets can be retrieved. Sounds impossible, right? Okay, let's try and solve them possible. Time loss secret shares. So firstly, before we get into that, right? What is a time loss? It's basically something that takes a long time to decrypt. There are multiple variants, right? If you guys have been following the merge, they use verifiable delay functions and all that, but we are just going to use the most basic one, which is repeated squaring. And realistically, it really doesn't matter what you use. Just think it's locked for a long time. That's what matters, right? And you know what, let's just do this, right? Let's just have an extra share, right? We have three just now. You require two to redraw the line. Let's just have one more, right? One more that's time locked. And let's say your house caught fire, you know, and you've lost both your laptop and your phone, so you've lost two factors. They're now ash, but luckily, right? You've prepared ahead of time. You generated a four share at a time lock for like one month, and you put it somewhere other than your house, so it didn't catch on fire. You put it in public. And a month's time it unlocks, and with your other share, which is like an email share, you can get back your key. Perfect. Not really, that doesn't work. So let's see why, right? The problem is that now, you're just one compromise factor away from losing a key. So let's say there's a patient attacker, adversary, just waiting, right? He just waits a month. Well, your time lock share will eventually unlock, right, after a month. And remember, it's in the public domain because it's not your house. Someone could get access to it. And then they just need to steal any one of the factors, right, to get a key. So basically you've got for 2FA to really 1FA. So that's no good. Solution two, let's improve that, right? Let's do time lock shares with key refresh. So once again, new concept, right? What is key refresh? For those who don't know, basically key refresh is a way to refresh the shares of a secret share, secret sharing, while keeping the private key the same. The private key here is the star, right? It's the star. So that's a private key the same. And the way we do it is kind of, you just draw another line that goes through the same point, the same y-intercept, which is your key, and then you get rid of the old shares. Basically, all the shares are different, but your key is the same. And the point here is that as long as you don't lose two factors on the same line, right, you don't lose two factors before you did a QE refresh, your key is safe, right? Because even if they compromise these factors, they can't redraw the line, impossible. And the two lines are completely unrelated. So that's what QE refresh does. There are a lot of protocols that do that today. But please, don't do it like this. There's a lot of other stuff you can do. Please don't do like this production. So now we have some idea of what QE refresh does. What if we just QE refresh before the time locks up, right? So we do a QE refresh, whatever you use a wallet, maybe once a week. The time lock is like a month, right? So as long as you use it once a week, you're fine. So when you use it, you do a QE refresh, you get rid of the shares. Even when the time lock share unlocks, right? The attacker can't get anything, even if you steal another factor, right? Because you can't get back the line. So you can't get back the same line. So it seems like a safe, right? And this seems to work, right? The setup seems to have a lot of properties that we want. During normal operation, attacker can solve the time lock, but it cannot use the other shares since QE refresh has occurred. It's on a different line. There's an interesting property here. So if you guys have been following time lock research and like verifiable delay encryption, you'll know that there are some research being done, there's some research being done on homomorphic time lock puzzles and all that because it makes it cheaper. But in our case, actually it's good that it's expensive. It's a feature. We want it to be expensive because we don't want attackers to be getting through the time lock easily or even be able to do it parallely. And in the case when you lose your key, you won't mind doing the work. It doesn't matter. Bends is not a big deal. So during normal operation, you're fine, but if you're catastrophic loss, right? You lose all your user factors. You, I don't know, somehow lose all your user factors. Then if the time lock share is reviewed and share refresh won't happen, right? Because you didn't have your share, so you can't share refresh. Then you can use the custodial share with the email share and the time lock share to reconstruct the key. So it's kind of like a dead man switch of a smart contract wallet, except it's done in FPC. So we created a non-custodial setup that degrades into a custodial setup on loss. But that's it. Thank you. No, I'm kidding. This kid, this is for a host. There's no way this is gonna work, right? So firstly, what happens if a phone share is stolen? Then the time lock share unlocks. Let's consider that, right? So your phone share is there. It's been stolen, right? Someone just stole your phone. Well, what are you gonna do? Well, you're gonna key refresh, right? That's the only thing you have protecting a share. So you're gonna key refresh. You bought a new phone, so your new share and that phone, perfect. But the attacker and the hacker who put in teeth, who stole your phone, is not going to actually delete the share. Just gonna hold on to it. And when a month passes and the time lock expires, he's gonna be able to steal a key. Key gone. Terrible. Okay, maybe what we can do is stop making more shares, right? The reason why this person was able to get a key was because he had more cryptographic material. So what we're gonna do is, instead of having more shares, the time lock share itself is just gonna be my phone share, right? So this person stole my phone and then he gets the time lock share which is also my phone share. So he doesn't really get anything new. So I'm safe. Not really. If you store your laptop, right, and the time lock share unlocks, you run into the same problem. So it looks like we're in a dilemma here, right? What really can we do? A new solution, right? Let's split the device share in two. A time lock share and then a custodial sub share. So how does that look like? How does that look like? So what we're gonna do is, we have this initial setup, right? Two out of three factors. You have an email login, a phone and a laptop share. So they're actually stored based on these factors. And what we're gonna do is to split the phone factor into two sub shares. We're gonna split it in two. And one will be time lock. And the other will be encrypted in your email, right? So this way, let's say if someone's used any of the factors and they get a time lock share, they still have to compromise another factor, which is your email, right? So key recovery still works. If you lose everything, you still have, let's say you lose both your phone and your laptop, record fire in the house, right? You still have the time lock share and the email share, which you can use to reconstruct your phone share and you already have email share, so you can redraw the line, right? So you're still safe from catastrophic loss, but adversary can't actually get your key unless he also compromises another factor. So you still get the two FA properties, perfect. But there's also another problem. The email provider might not release shares during Key Refresh. Let's see why that's a problem. What happens if, let's say, the email provider doesn't delete shares, right? So let's go back to the scenario, right? You do Key Refresh, right? And the email provider, instead of doing Key Refresh properly and during Key Refresh, you're supposed to discard the old shares. He doesn't, he just keeps the email share. I don't know why not, why shouldn't he keep it? Well, after a month passes, right? So let's go back a bit. After a month passes, right? This is going to unlock, right? The time lock share is going to unlock. And it's going to reconstruct the phone share on the previous secret sharing polynomial and reconstruct your key. So even though you refresh your shares, this is still a problem. As long as the custodian doesn't delete the share, right, you still have this problem where when the time lock expires, the custodian can get your key solution, right? The custodian's bad. No custodial factors. Let's just get rid of all the custodians at third parties. There's a problem there, though. We're trying to solve for the disaster case when you lose all of your user-owned factors. Do you really want all your factors to be lost because if they're all user-owned and something happens to you such that all the factors go away, there's going to be no way to recover a key. And this problem is really less of a problem than a statement. It's not possible to get recovery from catastrophic loss without third parties having at least threshold minus one shares. Let's see why, right? Fundamentally, if custodians only control, let's say threshold minus two, which is less than threshold minus one, with a time lock shared and locks after one month, they will only have threshold minus one, right? So threshold minus two plus one. So they only have threshold minus one shares which is not sufficient. It's not going to meet the threshold. So because it doesn't meet the threshold, you need some other factor. You need some user-owned factor and that's impossible in this scenario since you're assuming that users lost all the shares. So they can't access anything. So we haven't really solved the non-deletion problem. Remember, this solution of removing custodians was to get rid of the non-deletion problem, but it's a non-solution. So we haven't really solved the non-deletion problem, right? We still need third parties to hold threshold minus one of the shares, but we can't guarantee deletion. So in one month, the custodian might be malicious and they'll steal the key. We have a final solution for now. One out of N deletion. So there are many forms of trust, right? And the best kind of trust is like trust, right? Zero of N. But there are also other trust factors, like U of N and one out of N. And maybe it's so like half majority of N. And one way to do that is maybe there's a way to make it such that we can delete the factor if at least one of N of the parties follow the rules. So what we could do is, right, we could have the custodial sub-share be further split across 100 independent custodians, like guardians, and trust that one of them will delete it during the refresh. As long as they do, the key material is gone. This isn't ideal, right? One out of N is not as good as zero of N, trustless, but it's close enough. And the set gets bigger, one out of 1,000, is actually pretty close to trustless. And also doing N and N secret sharing is very fast, so it's quite practical. So this is what a set-up looks like, right? We have the two-off resetting. We split it into two, one is time-locked, like you saw earlier, and then this one is split into amongst a bunch of guardians, right? However many you want. And during normal operation, right, if you do key refresh, and at least one of these guardians deletes the share, you're not gonna have enough pieces to reconstruct the phone share, so it's good enough, so adversary can get it. And neither can the custodial provider. But during catastrophic loss, when all user factors are gone, so your phone factor and laptop factor is gone, at least there's some way to recover it because your email factor is still there. The time-lock factor will unlock and the guardians should, in this scenario, return the shares to you, so you can reconstruct your key. There, a bit more complex, but much better than what we started with. So I have a demo, but it doesn't work very well on slow internet, so you guys can check it out on the slides below, on the link there. And if you don't like this solution, you can also just use a smart contract wallet or a date message, it's much simpler. Not everything is MPC, really. So some open problems. The guardians can really grief you, so let's say a catastrophic loss, the guardians can just refuse to return the shares to you, unless you pay them exorbitant fee. There's also a problem of how should the guardians know when to lock the key and return the shares to you. So these are some open problems we're exploring. So that's all. Thank you very much for coming to my talk. Hello? I think I'm a bit early, so does anyone have any questions? Yes, go ahead. Hello. Oh, hi. So the time-locked piece is a bit of a magic box that just works. Are there any practical algorithms to run this? Yes. The gist that I... I need the... Oh, he's taken it away. But anyway, you go check out slides online. There's a gist there. It's implemented in JavaScript, so you're wanting to rush a bit even faster, but the most common and simple algorithm is a repeated squaring algorithm. Look at this, look it up. It's quite popular and it works in this case. It works for just this use case. You don't need anything very complex. Yes, it's ASIC resistant, in a sense that it requires sequential steps. You can't parallelize it. So you could maybe build an ASIC for squaring, but it's not possible to parallelize the computation, so it's sequential. Yeah. Any other questions? Yes. Ah, okay. So we're considering the scenario, the whole point of this setup is complex, but the whole point of this is to protect against catastrophic loss. So during catastrophic loss, you're going to have this issue where you've lost basically all your user-owned factors, like phone and laptop. The email, we're just assuming it's custodial. There's always some way to subpoena the guy. There's always some way to get it. But what might happen is the time not sure unlocked, but the guardians, knowing that you didn't refresh your shares, have now detected that you lost your factors. And now they're going to grief you, right? They're going to be like, if you don't pay me half of what's owned by this account, I'm not going to give you back the shares. And this is extra challenging here because you only need one guardian to grief since there is no redundancy here. Yeah, so there's one problem, there's an open problem to solve. Any other questions? Go ahead. Someone not deleting a share and someone keeping the share. The problem here is that the actors here are dynamic. They're not static. So I will delete my share if I'm pretty sure you refreshed, right? Then you're not going to, you haven't lost your account. So my share is actually worthless. But when I do detect, right? Maybe you have no on-chain activity for like three weeks, right? A little suspicious, three weeks. Then I'm going to modify my behavior in accordance to that. So it's kind of hard to model it that way. I think a much more comprehensive way to think about a threat model is to think about the different types of attacks because the number of ways you can attack is limited since there isn't much interaction between the parties is really just about factors. Any other questions? All right, thank you very much.