WEBVTT 00:00.000 --> 00:09.880 Hi everyone, I'm Emily, a software engineer and student researcher from the University of British 00:09.880 --> 00:10.880 Columbia. 00:10.880 --> 00:12.880 You can reach me at Hello at Emily.ma. 00:12.880 --> 00:18.560 You can also follow along with the slides for this talk at Emily.ma.sashfastom 2025. 00:18.560 --> 00:22.720 I was recently a visiting researcher at the University of Cambridge, where I worked with Professor 00:22.720 --> 00:25.840 Martin Klutman on the Kansigi Protocol. 00:25.840 --> 00:31.520 Kansigi is a decentralized and an encryption key recovery protocol, making sure that users 00:31.520 --> 00:35.800 can retain access to their encrypted backups without putting all their trust in a central 00:35.800 --> 00:36.800 provider. 00:36.800 --> 00:41.800 The name is a play on the Japanese art of mending together broken earth and wear a pottery 00:41.800 --> 00:46.840 with gold, and here we're mending together decentralized shares into recovery keys. 00:46.840 --> 00:48.960 Maybe the analogy needs a little work. 00:48.960 --> 00:53.920 Anyway, this talk will cover some background on Pyra and Kansigi recovery work, as well as 00:53.920 --> 00:59.360 how we developed Kansigi, its inner workings, and its unique security properties. 00:59.360 --> 01:03.400 I'll be keeping the cryptography fairly light to make sure things are accessible to everyone, 01:03.400 --> 01:08.000 but feel free to interrupt me if you have any questions. 01:08.000 --> 01:11.520 So to contextualize the problems, but it's a little bit, consider what happens when you 01:11.520 --> 01:16.320 lose your phone, but you want to regain access to some data that you had on an app. 01:16.320 --> 01:19.320 With a non-entering cryptid app, this is fairly simple. 01:19.320 --> 01:23.320 You can just download the app again and log in with the same username and password, and 01:23.320 --> 01:27.320 that app server probably stores some hash of your password or some other information where 01:27.320 --> 01:30.280 it can validate and authenticate you. 01:30.280 --> 01:33.840 But if the app is entered encrypted, that doesn't work quite so well. 01:33.840 --> 01:37.680 The very nature of enter encryption means that the server doesn't store a copy of your 01:37.680 --> 01:40.080 private key or recovery key or anything. 01:40.080 --> 01:41.680 So you have to use something different. 01:41.680 --> 01:46.440 For example, you might use a recovery pin, set of a recovery contact, have recovery codes 01:46.440 --> 01:50.560 or files, and just a name if you. 01:50.560 --> 01:53.640 But each of these schemes has their own trade-offs. 01:53.640 --> 01:58.440 So for example, signal and WhatsApp use recovery pins, which are short, four to six digit 01:58.440 --> 02:02.840 codes that you can set, memorize, and then provide back to the app in order to gain access 02:02.840 --> 02:04.320 to your account again. 02:04.320 --> 02:08.040 However, four to six digits is very short, so it's very easy to brute force. 02:08.040 --> 02:10.960 So you need some sort of rate limiting in effect. 02:10.960 --> 02:15.200 Unfortunately, this usually requires some sort of secure hardware, like a hardware security 02:15.200 --> 02:20.520 module, that makes sure that only recovery attempts can happen only once every so often. 02:20.520 --> 02:26.920 And these hard-rescurity modules tend to be expensive to run, or difficult to deploy. 02:26.920 --> 02:29.800 Another option is using a recovery contact. 02:29.800 --> 02:33.960 So Apple iCloud will let you set someone as a recovery contact, and this email provider 02:33.960 --> 02:37.920 called Prevail, which is also entering encrypted, will let you set a group of people as 02:37.920 --> 02:38.920 a recovery contact. 02:38.920 --> 02:41.920 So you don't have to put all your trust into one person. 02:41.920 --> 02:46.720 Regardless, you still have to trust these contacts a lot, because, for example, with Apple, 02:46.720 --> 02:52.400 you can ask you for some information that'll ostensibly only you know, but if you're 02:52.400 --> 02:57.520 close enough to a person to be set as a recovery contact, it's fairly easy to also guess. 02:57.520 --> 03:01.640 And even if we use a group-based approach where you need some threshold of these recovery 03:01.640 --> 03:06.160 contacts to come back together, the implementations of these schemes usually means that 03:06.160 --> 03:13.080 these contacts can come together behind your back, and reconstruct your key in its entirety. 03:13.080 --> 03:17.800 Finally, some apps like last pass require that you download some recovery codes, or have 03:17.800 --> 03:19.920 some set of recovery files. 03:19.920 --> 03:24.120 And similarly, a cryptocurrency wallet is like Bitcoin or whatnot, require that you store 03:24.120 --> 03:29.400 some seed phrase, which is 24 words, so that can help you re-derive your private key and 03:29.400 --> 03:31.720 get back access to your wallet. 03:31.720 --> 03:36.640 This is good because they're less prone to brute force due to their being longer and 03:36.640 --> 03:41.360 higher entropy, but this also requires keeping a copy of this somewhere. 03:41.360 --> 03:47.120 So users tend to misplace these files and backups either digitally or physically, which 03:47.120 --> 03:51.960 isn't good because this leads to an increased risk of total account lockout. 03:51.960 --> 03:57.120 And even if they wanted to commit them to memory because they're so long and therefore 03:57.120 --> 04:03.160 makes them hard to move force, but also much more difficult to commit to memory. 04:03.160 --> 04:07.960 As well, all of the schemes implicitly rely on some sort of centralized source of trust, 04:07.960 --> 04:10.360 which isn't always work for some apps. 04:10.360 --> 04:14.440 For example, some applications like TOR that require a metadata privacy wouldn't work well 04:14.440 --> 04:19.160 with a model of this central, all-knowing app authority that controls all the servers and 04:19.160 --> 04:21.960 hardware that belongs to the app. 04:21.960 --> 04:26.560 As well, some apps might have concerns about having their infrastructure shut down if 04:26.560 --> 04:30.040 it's all hosted on a single provider. 04:30.040 --> 04:34.160 Otherwise, services might lack this concept of essential authority group if it's 04:34.160 --> 04:38.200 some sort of decentralized instance-based service. 04:38.200 --> 04:40.880 Also, this infrastructure can be cost prohibitive. 04:40.880 --> 04:44.120 As I mentioned with the recovery pins, you'll usually need some sort of hardware security 04:44.120 --> 04:47.440 module, which is expensive and not typical hardware. 04:47.440 --> 04:51.240 And this in turn limits the amount of decentralization that's possible. 04:51.240 --> 04:55.720 You can't use TOR's node operator model if the hobbyist node operators can't afford 04:55.720 --> 04:58.080 the specialized hardware that's required. 04:58.080 --> 05:01.280 And there are also your typical gripes about centralization, like concerns about having 05:01.280 --> 05:05.320 a single point of failure and trust and infer availability. 05:05.320 --> 05:11.040 So overall, while these existing encryption key recovery schemes work well for existing 05:11.040 --> 05:16.840 apps, we want to just for a new space in our research, including key recovery protocols 05:16.840 --> 05:23.560 that were completely decentralized and didn't require any of this specialized hardware. 05:23.560 --> 05:25.760 So this is where Kansuki comes in. 05:25.760 --> 05:31.480 It's a decentralized key recovery protocol based on a peer-to-peer network of recovery nodes. 05:31.480 --> 05:36.400 So these recovery nodes can be either recovery servers run by different app providers 05:36.400 --> 05:40.760 or end-user contact devices or a mix of the two. 05:40.760 --> 05:45.880 With Kansuki, users can perform recovery by providing the password and then contacting 05:45.880 --> 05:48.080 some threshold of recovery nodes. 05:48.080 --> 05:53.200 And the users can configure the threshold and exact recovery nodes they use during registration. 05:53.200 --> 05:58.880 Each of these recovery nodes holds a share of a secret that's needed to recover the key. 05:58.880 --> 06:02.960 Users can also update the recovery nodes at any time, which is something that's ideal 06:02.960 --> 06:07.160 in most contexts where you might want to, for example, change the collaborators who you're 06:07.160 --> 06:10.600 giving access to some shared file, for example. 06:10.600 --> 06:15.640 Kansuki also defends against brute force attacks on the password and against including honest 06:15.640 --> 06:19.480 bit curious recovery nodes, which are where we're having nodes that are colliding behind 06:19.480 --> 06:22.680 your back to try to put together your key without your knowledge. 06:22.680 --> 06:26.080 So that's something that's a concern, for example, with the recovery context I mentioned 06:26.080 --> 06:29.280 earlier. 06:29.280 --> 06:33.160 So I've got a limo demo to walk through in here, and you can also check out the implementation 06:33.160 --> 06:36.320 on the GitHub link I have up on this slide. 06:36.320 --> 06:41.600 Kansuki is implemented as a peer-to-peer app interest with libp2p for the communication 06:41.600 --> 06:45.680 layer and tori and a react for the UI. 06:45.680 --> 06:49.920 And I'll just be showing the UI of the quote unquote user's node, but each Kansuki node 06:49.920 --> 06:54.680 can enter and serve as a recovery node for other Kansuki nodes. 06:54.680 --> 07:01.280 So in this video here, I'll be walking through the process of a user registering with 07:01.280 --> 07:03.920 some potential service that uses Kansuki. 07:03.920 --> 07:08.240 So for simplicity, let's say that this is just an encrypted no-pad, do is read and write 07:08.240 --> 07:12.680 from an encrypted file, and that's all stored locally. 07:12.680 --> 07:18.120 In this case, Kansuki is used to protect and help recover the key that's used to encrypt 07:18.120 --> 07:22.840 this local file, because otherwise if the user loses the device and loses the key, then 07:22.840 --> 07:25.960 they're not able to decrypt it again. 07:25.960 --> 07:30.480 So in the video here, we first walk through registration, so the user provides the username 07:30.480 --> 07:35.400 and the password, and then configures the recovery node as an official. 07:35.400 --> 07:38.520 So I'm just using some boot shop nodes that I'm running in the background. 07:38.520 --> 07:45.880 We can then write to this encrypted no-pad, and then what we'll do is delete the local 07:45.880 --> 07:47.720 login envelope just similar to the device law. 07:47.720 --> 07:51.280 So now we don't have the key used to encrypt that envelope anymore. 07:51.280 --> 07:55.320 Next we can initiate recovery, so the user provides the username and password, and select 07:55.320 --> 08:00.960 some threshold of the recovery nodes to use. 08:00.960 --> 08:04.280 And you can see that we can read back the value of the encrypted no-pad and that the recovery 08:04.280 --> 08:05.280 was successful. 08:05.280 --> 08:09.180 And also you can see now that we can log in locally again, so we actually have the copy of 08:09.180 --> 08:10.180 the key. 08:10.180 --> 08:15.160 Now, the part of this is changing this recovery context, so we can, for example, delete 08:15.160 --> 08:20.640 a recovery context or change the threshold of context something to reach, and you can 08:20.640 --> 08:25.920 see that we follow a similar recovery process. 08:25.920 --> 08:31.960 We delete the local login envelope to similar device laws, provide username and password, 08:31.960 --> 08:36.160 and now we can use only two recovery nodes instead of the three before. 08:36.160 --> 08:46.760 And we can still read back the value of that encrypted no-pad. 08:46.760 --> 08:48.960 So let's now get into how this all works. 08:48.960 --> 08:53.080 I promised I would keep the crypto light here, but I wanted to cover the basic concepts 08:53.080 --> 08:56.320 used behind the main building blocks that can suit you. 08:56.320 --> 09:01.760 So for one, the way we preserve Enten encryption, ensure that the recovery nodes don't 09:01.760 --> 09:06.360 learn anything about the user's password or the final recovery key is via an oblivious 09:06.360 --> 09:09.520 pseudo-random function, or OPRF. 09:09.520 --> 09:14.400 And OPRF is a type of function where you need two parties to provide each of their own 09:14.400 --> 09:15.800 secret inputs. 09:15.800 --> 09:20.040 So for example, the user keeps their secret value, which we can call you, and the server 09:20.040 --> 09:25.640 keeps their secret value, which we call S. Within OPRF evaluation, the user will learn 09:25.640 --> 09:31.920 the result of the OPRF, but not the value that the server put in during evaluation. 09:31.920 --> 09:38.680 On the other hand, the server will learn nothing about the user secret or the final result. 09:38.680 --> 09:40.760 So how does this all work? 09:40.760 --> 09:43.840 The key is in what we call blinded. 09:43.840 --> 09:47.120 So you might be able to think of this, like, wrapping a secret present. 09:47.120 --> 09:51.360 So let's say for Christmas, I gave someone a very nice talk at. 09:51.360 --> 09:54.640 And we can wrap it in some wrapping papers, so people from the outside can't tell what 09:54.640 --> 09:56.800 was inside. 09:56.800 --> 10:01.880 So likewise with this OPRF, the user will blind and kind of wrap their secret value 10:01.880 --> 10:06.040 you before sending it to the server. 10:06.040 --> 10:08.400 Then the server will operate on this blinded value. 10:08.400 --> 10:12.520 So the server doesn't know what's actually inside the present, but it can also operate 10:12.520 --> 10:14.680 on the value so it's inside. 10:14.680 --> 10:18.840 So we can think of the server like this magic machine that turns anything that passes through 10:18.840 --> 10:20.240 it into pure gold. 10:20.240 --> 10:25.800 So because the present is wrapped, we can't see what the servers are turning into gold, 10:25.800 --> 10:29.120 but the server is still able to operate on that value. 10:29.120 --> 10:33.840 And the server will return this then back to the user. 10:33.840 --> 10:38.560 Now the user can take off that wrapping paper, which we call unblinding the value, and 10:38.560 --> 10:42.280 get back the final evaluation result of their OPRF. 10:42.280 --> 10:46.080 So now we can see that that top out has become a gold crown. 10:46.080 --> 10:50.680 So with this analogy, the user learns the final execution result, they get their gold 10:50.680 --> 10:55.840 crown, but they don't know what secrets the server is using to make a magic machine. 10:55.840 --> 11:00.480 And likewise because of this wrapping, this blinding that the user is using, the server doesn't 11:00.480 --> 11:02.920 know what value it was actually operating on. 11:02.920 --> 11:10.120 So the server has no way of knowing anything related to you. 11:10.120 --> 11:13.800 The other main concept of this is of secret sharing. 11:13.800 --> 11:17.240 So this is how we're able to decentralize this key recovery. 11:17.240 --> 11:21.360 If you've heard of it before, we're using concepts from Shemir secret sharing. 11:21.360 --> 11:24.960 And forgive me if your eyes are glazing over at the set of a polynomial, but I promise 11:24.960 --> 11:27.000 I'll make this intuitive. 11:27.000 --> 11:31.080 So Shemir secret is hearing works by having the secret S that you want to split up into 11:31.080 --> 11:32.880 multiple shares. 11:32.880 --> 11:36.760 So you want to make sure that you need some threshold of shares to reconstruct, because 11:36.760 --> 11:41.360 otherwise you would put all your trust into one person and say, OK, this one person 11:41.360 --> 11:42.680 please don't do anything that. 11:42.680 --> 11:48.520 But if we have this decentralized shares, then we have to enforce that some threshold of 11:48.520 --> 11:52.440 people have to come together to help you do recovery. 11:52.440 --> 11:57.040 So we have this secret S. And then we define some polynomial function where their constant 11:57.040 --> 12:02.160 term is S. So constant term means that when we evaluate this function F at zero, we just 12:02.160 --> 12:04.080 get S back. 12:04.080 --> 12:08.400 Then we can add some coefficients to the other terms in that polynomial. 12:08.400 --> 12:11.280 And we can just assign these to random values. 12:11.280 --> 12:15.720 The interesting bit though is that now we can evaluate this whole function at a bunch of 12:15.720 --> 12:16.920 other X values. 12:16.920 --> 12:20.520 And each of those points will turn into one of our shares. 12:20.520 --> 12:24.680 Once we have enough shares to do recovery, what we can do is essentially connect the 12:24.680 --> 12:25.680 dots. 12:25.680 --> 12:27.360 So we have a bunch of these points on the curve. 12:27.360 --> 12:31.560 And we can connect the dots to derive back the unique function that passes through all of 12:31.560 --> 12:33.000 these points. 12:33.000 --> 12:36.200 But we need enough shares to do that though. 12:36.200 --> 12:39.240 So how many shares do we end up needing? 12:39.240 --> 12:44.360 If you have a polynomial of degree T, which means that it has T plus 1 terms, including 12:44.360 --> 12:49.640 that constant factor, this means that you essentially have T plus 1 free variables, those 12:49.640 --> 12:53.040 coefficients, and that secret value that you need to figure out again. 12:53.040 --> 12:57.120 And if you remember from high school algebra, you need T plus 1 equations to solve for 12:57.120 --> 12:58.840 T plus 1 unknowns. 12:58.840 --> 13:03.880 And each of these equations is what the information captured in the share, because it maps 13:03.880 --> 13:08.680 a X value to one of the points on our curve. 13:08.680 --> 13:14.800 So essentially we need T plus 1 values to reconstruct S. And if we have less than T plus 1, 13:14.800 --> 13:18.800 then we can't exactly figure out the unique function that passes through all these points. 13:18.800 --> 13:20.840 So recovery won't be successful. 13:20.840 --> 13:24.160 And if we have more than T plus 1, it's kind of like if we just had more points on the 13:24.160 --> 13:28.800 same curve, we can still connect the dots to get back the same shared value S. 13:28.800 --> 13:32.960 If this is all going up over your head, the summary is that we have a secret value S. 13:32.960 --> 13:36.160 We draw a squiggly line through it and map some points on that curve. 13:36.160 --> 13:42.720 And then we just connect the dots later, and I promise that you get the same value back. 13:42.720 --> 13:48.480 So we use extensions of both opiorefs and shimmery secret sharing to build Kinsugi. 13:48.480 --> 13:53.440 In Kinsugi, we use threshold opiorefs instead of opiorefs, which are just like opiorefs, 13:53.440 --> 13:56.480 but imagine that you have multiple servers instead. 13:56.560 --> 14:00.640 You still have to take your value and blind it and send it out to all these servers. 14:00.640 --> 14:06.000 So imagine you take that secret and wrap it in some wrapping paper and send it out to all these servers. 14:06.000 --> 14:11.920 But you now need to wait to get a blinded execution back from P plus 1 of them to combine together. 14:11.920 --> 14:16.320 Before you can, and blind things and reconstruct the recovery key. 14:16.320 --> 14:22.960 If you're interested, this concept is explained in more detail in the TOPPSS paper by Jerarchy at L. 14:22.960 --> 14:29.360 As well instead of shimmery secret sharing, we actually using a variation called dynamic proactive secret sharing. 14:29.360 --> 14:33.120 Where each recovery node secret share can be refreshed and updated 14:33.120 --> 14:37.200 in order to change who can hold these secret shares. 14:37.200 --> 14:40.960 So imagine we have that curve and we're just moving around the points on the curve, 14:40.960 --> 14:44.960 but we're keeping the same share value at X equals 0. 14:44.960 --> 14:48.000 This is used so the user can change their recovery nodes. 14:48.000 --> 14:52.800 For example, if one of them becomes untrustworthy and we need a remove it like we saw in that video, 14:52.800 --> 14:54.560 or if one just goes permanently offline. 14:55.600 --> 15:00.720 Again, this is just making sure that these old recovery nodes can't participate 15:00.720 --> 15:02.640 in the new recovery attempts. 15:02.640 --> 15:06.960 And this is described in more detail in the long live the Honey Badger paper by Dawson at L. 15:09.520 --> 15:13.120 Now let's finally get into the three main flows that you saw in the demo video. 15:13.120 --> 15:15.840 Registration, recovery, and updating the recovery nodes. 15:16.480 --> 15:18.800 So the first slow we saw is registration. 15:19.040 --> 15:24.960 So users start with their password, wish they then blind, again, like wrapping it in some wrapping paper. 15:25.680 --> 15:28.080 And then send this to the recovery nodes. 15:28.880 --> 15:32.800 Again, the recovery nodes can't see the value of the user's password because of this blending. 15:33.360 --> 15:37.360 And each of these recovery nodes holds a share of a recovery secret 15:37.360 --> 15:39.600 that's done by a dynamic proactive secret sharing. 15:40.240 --> 15:44.880 So each of these recovery nodes has the share of the secret and applies that by a threshold operev. 15:45.840 --> 15:48.640 And sends all of their evaluation results back to the user. 15:49.440 --> 15:55.440 Now the user, again, doesn't know anything about the recovery secret that's held and shared by these recovery nodes. 15:56.000 --> 16:01.680 But the user still able to combine all of these special operev evaluations to get back a result. 16:02.560 --> 16:07.680 And this result is used as a key to then encrypt the user's recovery key or 16:07.680 --> 16:10.560 private key or whatever recovery data that they want to keep track of. 16:11.440 --> 16:15.360 And this has been sent to the recovery nodes to be persisted. 16:18.480 --> 16:21.200 During recovery, the recovery flow operates very similarly. 16:21.200 --> 16:25.760 So the user starts with their password, blinds it, and sends it to the recovery nodes. 16:26.640 --> 16:32.480 The recovery nodes will then send back their threshold operev evaluations along with that encrypted envelope. 16:33.520 --> 16:38.160 So by a very similar process, the user can then combine these special operev evaluations 16:38.160 --> 16:44.000 to get back the key and then decrypt that envelope to get back their recovery key or private key. 16:47.360 --> 16:51.840 These nodes also perform rate limiting with an additional layer of Boothers protection 16:51.840 --> 16:54.320 without requiring these expensive hardware security modules. 16:54.880 --> 17:00.000 Because we're using a threshold operev, so we now need to wait for a T-plus one results to come back to us 17:00.000 --> 17:07.120 before we're able to combine things. So this intern limits naturally the rate at which you can submit 17:07.280 --> 17:12.320 new recovery attempts. Because if we have at least one of these recovery nodes slowing things down 17:12.320 --> 17:17.120 and implementing rate limiting properly, then the overall process of recovery will be slowed down. 17:17.120 --> 17:20.160 Which gives us this really nice, decentralized rate limiting as a result. 17:21.680 --> 17:26.480 Also because no one recovery node has the whole recovery secret, this means that you'll 17:26.480 --> 17:31.920 one need a threshold of these recovery nodes to collude to even get back the recovery secret. 17:31.920 --> 17:35.440 And even if they find out that the recovery secret, like their malicious, they go behind your 17:35.840 --> 17:40.080 back, they put together recovery secret. That's not entirely a problem because when you go back to 17:40.080 --> 17:45.680 the encrypted envelope, you'll still need the users input for the operev in order to get back the 17:45.680 --> 17:51.600 key used to decrypt that envelope. So this provides our protection against colluding recovery nodes. 17:54.240 --> 18:00.080 Finally, if the user wishes to update their recovery nodes, they consent in notification to the 18:00.080 --> 18:06.080 old recovery nodes. These old recovery nodes will then take their shares and split it up into 18:06.080 --> 18:11.280 sub shares, which they then broadcast to the new recovery nodes. These new recovery nodes can even 18:11.280 --> 18:15.760 be the same nodes as the old recovery nodes. If you just want to do a periodic refresh of the shares 18:15.760 --> 18:22.800 that you hold. So now these new recovery nodes will take these sub sub-subshars of the old recovery 18:22.800 --> 18:28.480 nodes, combine them together using a similar like connect the dots, algorithm, and then they've 18:28.480 --> 18:34.000 got their new shares that are used from this point onward in the consumer process. You can think of 18:34.000 --> 18:38.240 this kind of like if we had all those points on the curve and we just moved around and changed 18:38.240 --> 18:43.120 who held which point. We're still keeping the same shared value, so the operev can still 18:43.120 --> 18:50.480 evaluate with the same encryption key used for that envelope. If you're interested, I wrote a blog 18:50.480 --> 18:55.600 post about this dynamic practice secret sharing that goes into a more at a high level, but I think 18:55.600 --> 19:01.600 we've had enough math for today, so let's wrap up and conclude. So that's been a world 19:01.600 --> 19:06.560 little mock-through of conceugie. Today we've gone through some of the reasons why existing 19:06.560 --> 19:11.760 nton key recovery protocols are lacking and how conceugie addresses their shortcomings. 19:11.760 --> 19:16.400 We've gone through some fun introduction to crypto and finally learned on a deeper level how conceugie 19:16.400 --> 19:22.480 works. With conceugie, our main improvements over existing recovery methods are definitely this aspect 19:22.560 --> 19:28.320 of decentralization. As well, we also don't require any expensive hardware as with those recovery 19:28.320 --> 19:33.040 pins, and we also work in the case of device loss because all you need to remember is your password. 19:34.800 --> 19:39.280 Also conceugie will protect against brute force as we've shown with that rate limiting, 19:39.280 --> 19:44.080 and then also with the colluding recovery notes as we've shown with the opereph evaluation. 19:45.360 --> 19:49.440 As the current state of the project, we've finished the protocol demo as you can see the 19:49.440 --> 19:54.800 GitHub link on the slide, but we've also going to be figuring out how to integrate this with a larger 19:54.800 --> 19:59.600 decentralized access control project run by the Inconcewich Lab. That's called behive and you can 19:59.600 --> 20:04.160 click the link on the slides if you'd like to learn more about it. There's also plenty of non-critical 20:04.160 --> 20:09.040 loose ends that I stopped to get around to implementing like Byzantine fault equivalents and 20:09.040 --> 20:12.960 Byzantine value agreement that I haven't fully gone through yet, but I love to get around to you. 20:14.240 --> 20:18.640 That's about me for me and the conceugie protocol. Again, you can find the slides for the stock 20:18.640 --> 20:23.360 at mly.mas.faston2025 and yeah, I'm happy to take any questions out. 20:31.920 --> 20:36.800 One of the last slides where you were reading the screen, reading the screen, reading the keys, 20:36.800 --> 20:44.000 one of the nodes is untrusted and nothing complied, so we didn't give you back the share of it 20:44.880 --> 20:55.200 yet. I guess you have to have a low enough needed number to reconstruct the T and then 20:56.480 --> 21:01.200 partition it again. So to repeat the question, the question was on this slide, 21:04.400 --> 21:09.040 we need all of these recovery nodes to what happens if one of these recovery nodes doesn't 21:09.040 --> 21:14.320 cooperate with the recovery update process. So you don't need all of them to comply, 21:14.320 --> 21:19.120 you just need a threshold of them to comply, because you just need a threshold of them to reconstruct 21:20.000 --> 21:25.120 to split up the information that was originally held in that shared secret. And then, 21:25.120 --> 21:30.080 as long as you have some threshold of the old nodes that comply, you can then work with their 21:30.080 --> 21:38.800 new threshold and the new community. Let's say one of our team for more of that, and 21:38.800 --> 21:44.800 points don't comply, but in the defense that the provide the incorrect values, is there error checking? 21:45.360 --> 21:50.960 Yeah, so the question was, what happens if the recovery nodes don't provide correct values? Is there 21:50.960 --> 21:55.200 error checking? So right now with the implementation, there's not error checking, but there's 21:55.200 --> 22:00.560 Byzantine value agreement that I saw to implement. I left it at a demo just for time sick and 22:00.560 --> 22:05.600 like for my implementation process, but that's something that you can do in like the theoretical protocol. 22:08.000 --> 22:08.800 Yeah. 22:08.800 --> 22:16.640 Is it necessary that the user is involved in selecting the recovery node or is it possible to 22:16.640 --> 22:22.480 automate which recovery nodes are used? So the question was, does a user have to participate 22:22.560 --> 22:26.720 in selecting which of the recovery nodes are used? I'm not thought about this. I think it's 22:26.720 --> 22:33.040 possible to just do this opaquely and just say we're going to take, here's the ones that you can use 22:33.040 --> 22:38.480 and just like use these. But I guess idea was that users are able to choose for their own benefit, 22:38.480 --> 22:42.320 but I don't think it's, it's not necessary in the protocol. Yeah. 22:52.480 --> 23:20.640 So the question was, what's stopping? If you have recovery nodes that are colluding, what's stopping 23:20.640 --> 23:27.600 them from decryping the envelope? Yeah. So the password is the, well, the blinded password is 23:27.600 --> 23:34.080 what's preventing them from completing the OPRF and going behind your back to get the recovery key. 23:34.080 --> 23:37.840 But because the password is blinded and then there's a whole bunch of like elliptic curve 23:37.840 --> 23:43.280 cryptography in the middle, then like this significantly decreases the risk as opposed to you just 23:43.280 --> 23:55.920 having like a plain password. It can't be done offline. You have to be providing your value. 23:55.920 --> 24:03.920 Yeah. 24:03.920 --> 24:07.920 For another question. 24:07.920 --> 24:15.600 So in some situations, people did all of the servers to update some data like if I changed 24:15.600 --> 24:22.400 the number of nodes that are required for recovery, that means that I have to create a new 24:22.400 --> 24:27.840 polynomial and then I have to upload it all to all the servers or I have to communicate 24:27.840 --> 24:34.240 it all the internal files. So if some of those recovery nodes are down, yeah. 24:34.240 --> 24:39.440 I'm not colluding, they're just trying to evolve and when I want to make a day and then 24:39.440 --> 24:45.440 they switch on again. Yeah. So the question was, it seems like we need to contact all of the 24:45.440 --> 24:50.000 recovery nodes in some situations. What happens if some of them are down? I guess like during 24:50.000 --> 24:54.400 this update process. So you don't have to contact all of them. You only need to contact 24:54.400 --> 25:00.160 a threshold of the old recovery nodes. You will have to contact all of the new recovery nodes or 25:00.160 --> 25:05.840 at least you need to contact a threshold based on the new threshold of the recovery nodes for 25:05.840 --> 25:10.560 the new committee. So you at no point have to contact all of the nodes. So even if there's some 25:10.560 --> 25:15.440 often I notice that works fine.