Hi everyone, I'm Emily, a software engineer and student researcher from the University of British
Columbia.
You can reach me at Hello at Emily.ma.
You can also follow along with the slides for this talk at Emily.ma.sashfastom 2025.
I was recently a visiting researcher at the University of Cambridge, where I worked with Professor
Martin Klutman on the Kansigi Protocol.
Kansigi is a decentralized and an encryption key recovery protocol, making sure that users
can retain access to their encrypted backups without putting all their trust in a central
provider.
The name is a play on the Japanese art of mending together broken earth and wear a pottery
with gold, and here we're mending together decentralized shares into recovery keys.
Maybe the analogy needs a little work.
Anyway, this talk will cover some background on Pyra and Kansigi recovery work, as well as
how we developed Kansigi, its inner workings, and its unique security properties.
I'll be keeping the cryptography fairly light to make sure things are accessible to everyone,
but feel free to interrupt me if you have any questions.
So to contextualize the problems, but it's a little bit, consider what happens when you
lose your phone, but you want to regain access to some data that you had on an app.
With a non-entering cryptid app, this is fairly simple.
You can just download the app again and log in with the same username and password, and
that app server probably stores some hash of your password or some other information where
it can validate and authenticate you.
But if the app is entered encrypted, that doesn't work quite so well.
The very nature of enter encryption means that the server doesn't store a copy of your
private key or recovery key or anything.
So you have to use something different.
For example, you might use a recovery pin, set of a recovery contact, have recovery codes
or files, and just a name if you.
But each of these schemes has their own trade-offs.
So for example, signal and WhatsApp use recovery pins, which are short, four to six digit
codes that you can set, memorize, and then provide back to the app in order to gain access
to your account again.
However, four to six digits is very short, so it's very easy to brute force.
So you need some sort of rate limiting in effect.
Unfortunately, this usually requires some sort of secure hardware, like a hardware security
module, that makes sure that only recovery attempts can happen only once every so often.
And these hard-rescurity modules tend to be expensive to run, or difficult to deploy.
Another option is using a recovery contact.
So Apple iCloud will let you set someone as a recovery contact, and this email provider
called Prevail, which is also entering encrypted, will let you set a group of people as
a recovery contact.
So you don't have to put all your trust into one person.
Regardless, you still have to trust these contacts a lot, because, for example, with Apple,
you can ask you for some information that'll ostensibly only you know, but if you're
close enough to a person to be set as a recovery contact, it's fairly easy to also guess.
And even if we use a group-based approach where you need some threshold of these recovery
contacts to come back together, the implementations of these schemes usually means that
these contacts can come together behind your back, and reconstruct your key in its entirety.
Finally, some apps like last pass require that you download some recovery codes, or have
some set of recovery files.
And similarly, a cryptocurrency wallet is like Bitcoin or whatnot, require that you store
some seed phrase, which is 24 words, so that can help you re-derive your private key and
get back access to your wallet.
This is good because they're less prone to brute force due to their being longer and
higher entropy, but this also requires keeping a copy of this somewhere.
So users tend to misplace these files and backups either digitally or physically, which
isn't good because this leads to an increased risk of total account lockout.
And even if they wanted to commit them to memory because they're so long and therefore
makes them hard to move force, but also much more difficult to commit to memory.
As well, all of the schemes implicitly rely on some sort of centralized source of trust,
which isn't always work for some apps.
For example, some applications like TOR that require a metadata privacy wouldn't work well
with a model of this central, all-knowing app authority that controls all the servers and
hardware that belongs to the app.
As well, some apps might have concerns about having their infrastructure shut down if
it's all hosted on a single provider.
Otherwise, services might lack this concept of essential authority group if it's
some sort of decentralized instance-based service.
Also, this infrastructure can be cost prohibitive.
As I mentioned with the recovery pins, you'll usually need some sort of hardware security
module, which is expensive and not typical hardware.
And this in turn limits the amount of decentralization that's possible.
You can't use TOR's node operator model if the hobbyist node operators can't afford
the specialized hardware that's required.
And there are also your typical gripes about centralization, like concerns about having
a single point of failure and trust and infer availability.
So overall, while these existing encryption key recovery schemes work well for existing
apps, we want to just for a new space in our research, including key recovery protocols
that were completely decentralized and didn't require any of this specialized hardware.
So this is where Kansuki comes in.
It's a decentralized key recovery protocol based on a peer-to-peer network of recovery nodes.
So these recovery nodes can be either recovery servers run by different app providers
or end-user contact devices or a mix of the two.
With Kansuki, users can perform recovery by providing the password and then contacting
some threshold of recovery nodes.
And the users can configure the threshold and exact recovery nodes they use during registration.
Each of these recovery nodes holds a share of a secret that's needed to recover the key.
Users can also update the recovery nodes at any time, which is something that's ideal
in most contexts where you might want to, for example, change the collaborators who you're
giving access to some shared file, for example.
Kansuki also defends against brute force attacks on the password and against including honest
bit curious recovery nodes, which are where we're having nodes that are colliding behind
your back to try to put together your key without your knowledge.
So that's something that's a concern, for example, with the recovery context I mentioned
earlier.
So I've got a limo demo to walk through in here, and you can also check out the implementation
on the GitHub link I have up on this slide.
Kansuki is implemented as a peer-to-peer app interest with libp2p for the communication
layer and tori and a react for the UI.
And I'll just be showing the UI of the quote unquote user's node, but each Kansuki node
can enter and serve as a recovery node for other Kansuki nodes.
So in this video here, I'll be walking through the process of a user registering with
some potential service that uses Kansuki.
So for simplicity, let's say that this is just an encrypted no-pad, do is read and write
from an encrypted file, and that's all stored locally.
In this case, Kansuki is used to protect and help recover the key that's used to encrypt
this local file, because otherwise if the user loses the device and loses the key, then
they're not able to decrypt it again.
So in the video here, we first walk through registration, so the user provides the username
and the password, and then configures the recovery node as an official.
So I'm just using some boot shop nodes that I'm running in the background.
We can then write to this encrypted no-pad, and then what we'll do is delete the local
login envelope just similar to the device law.
So now we don't have the key used to encrypt that envelope anymore.
Next we can initiate recovery, so the user provides the username and password, and select
some threshold of the recovery nodes to use.
And you can see that we can read back the value of the encrypted no-pad and that the recovery
was successful.
And also you can see now that we can log in locally again, so we actually have the copy of
the key.
Now, the part of this is changing this recovery context, so we can, for example, delete
a recovery context or change the threshold of context something to reach, and you can
see that we follow a similar recovery process.
We delete the local login envelope to similar device laws, provide username and password,
and now we can use only two recovery nodes instead of the three before.
And we can still read back the value of that encrypted no-pad.
So let's now get into how this all works.
I promised I would keep the crypto light here, but I wanted to cover the basic concepts
used behind the main building blocks that can suit you.
So for one, the way we preserve Enten encryption, ensure that the recovery nodes don't
learn anything about the user's password or the final recovery key is via an oblivious
pseudo-random function, or OPRF.
And OPRF is a type of function where you need two parties to provide each of their own
secret inputs.
So for example, the user keeps their secret value, which we can call you, and the server
keeps their secret value, which we call S. Within OPRF evaluation, the user will learn
the result of the OPRF, but not the value that the server put in during evaluation.
On the other hand, the server will learn nothing about the user secret or the final result.
So how does this all work?
The key is in what we call blinded.
So you might be able to think of this, like, wrapping a secret present.
So let's say for Christmas, I gave someone a very nice talk at.
And we can wrap it in some wrapping papers, so people from the outside can't tell what
was inside.
So likewise with this OPRF, the user will blind and kind of wrap their secret value
you before sending it to the server.
Then the server will operate on this blinded value.
So the server doesn't know what's actually inside the present, but it can also operate
on the value so it's inside.
So we can think of the server like this magic machine that turns anything that passes through
it into pure gold.
So because the present is wrapped, we can't see what the servers are turning into gold,
but the server is still able to operate on that value.
And the server will return this then back to the user.
Now the user can take off that wrapping paper, which we call unblinding the value, and
get back the final evaluation result of their OPRF.
So now we can see that that top out has become a gold crown.
So with this analogy, the user learns the final execution result, they get their gold
crown, but they don't know what secrets the server is using to make a magic machine.
And likewise because of this wrapping, this blinding that the user is using, the server doesn't
know what value it was actually operating on.
So the server has no way of knowing anything related to you.
The other main concept of this is of secret sharing.
So this is how we're able to decentralize this key recovery.
If you've heard of it before, we're using concepts from Shemir secret sharing.
And forgive me if your eyes are glazing over at the set of a polynomial, but I promise
I'll make this intuitive.
So Shemir secret is hearing works by having the secret S that you want to split up into
multiple shares.
So you want to make sure that you need some threshold of shares to reconstruct, because
otherwise you would put all your trust into one person and say, OK, this one person
please don't do anything that.
But if we have this decentralized shares, then we have to enforce that some threshold of
people have to come together to help you do recovery.
So we have this secret S. And then we define some polynomial function where their constant
term is S. So constant term means that when we evaluate this function F at zero, we just
get S back.
Then we can add some coefficients to the other terms in that polynomial.
And we can just assign these to random values.
The interesting bit though is that now we can evaluate this whole function at a bunch of
other X values.
And each of those points will turn into one of our shares.
Once we have enough shares to do recovery, what we can do is essentially connect the
dots.
So we have a bunch of these points on the curve.
And we can connect the dots to derive back the unique function that passes through all of
these points.
But we need enough shares to do that though.
So how many shares do we end up needing?
If you have a polynomial of degree T, which means that it has T plus 1 terms, including
that constant factor, this means that you essentially have T plus 1 free variables, those
coefficients, and that secret value that you need to figure out again.
And if you remember from high school algebra, you need T plus 1 equations to solve for
T plus 1 unknowns.
And each of these equations is what the information captured in the share, because it maps
a X value to one of the points on our curve.
So essentially we need T plus 1 values to reconstruct S. And if we have less than T plus 1,
then we can't exactly figure out the unique function that passes through all these points.
So recovery won't be successful.
And if we have more than T plus 1, it's kind of like if we just had more points on the
same curve, we can still connect the dots to get back the same shared value S.
If this is all going up over your head, the summary is that we have a secret value S.
We draw a squiggly line through it and map some points on that curve.
And then we just connect the dots later, and I promise that you get the same value back.
So we use extensions of both opiorefs and shimmery secret sharing to build Kinsugi.
In Kinsugi, we use threshold opiorefs instead of opiorefs, which are just like opiorefs,
but imagine that you have multiple servers instead.
You still have to take your value and blind it and send it out to all these servers.
So imagine you take that secret and wrap it in some wrapping paper and send it out to all these servers.
But you now need to wait to get a blinded execution back from P plus 1 of them to combine together.
Before you can, and blind things and reconstruct the recovery key.
If you're interested, this concept is explained in more detail in the TOPPSS paper by Jerarchy at L.
As well instead of shimmery secret sharing, we actually using a variation called dynamic proactive secret sharing.
Where each recovery node secret share can be refreshed and updated
in order to change who can hold these secret shares.
So imagine we have that curve and we're just moving around the points on the curve,
but we're keeping the same share value at X equals 0.
This is used so the user can change their recovery nodes.
For example, if one of them becomes untrustworthy and we need a remove it like we saw in that video,
or if one just goes permanently offline.
Again, this is just making sure that these old recovery nodes can't participate
in the new recovery attempts.
And this is described in more detail in the long live the Honey Badger paper by Dawson at L.
Now let's finally get into the three main flows that you saw in the demo video.
Registration, recovery, and updating the recovery nodes.
So the first slow we saw is registration.
So users start with their password, wish they then blind, again, like wrapping it in some wrapping paper.
And then send this to the recovery nodes.
Again, the recovery nodes can't see the value of the user's password because of this blending.
And each of these recovery nodes holds a share of a recovery secret
that's done by a dynamic proactive secret sharing.
So each of these recovery nodes has the share of the secret and applies that by a threshold operev.
And sends all of their evaluation results back to the user.
Now the user, again, doesn't know anything about the recovery secret that's held and shared by these recovery nodes.
But the user still able to combine all of these special operev evaluations to get back a result.
And this result is used as a key to then encrypt the user's recovery key or
private key or whatever recovery data that they want to keep track of.
And this has been sent to the recovery nodes to be persisted.
During recovery, the recovery flow operates very similarly.
So the user starts with their password, blinds it, and sends it to the recovery nodes.
The recovery nodes will then send back their threshold operev evaluations along with that encrypted envelope.
So by a very similar process, the user can then combine these special operev evaluations
to get back the key and then decrypt that envelope to get back their recovery key or private key.
These nodes also perform rate limiting with an additional layer of Boothers protection
without requiring these expensive hardware security modules.
Because we're using a threshold operev, so we now need to wait for a T-plus one results to come back to us
before we're able to combine things. So this intern limits naturally the rate at which you can submit
new recovery attempts. Because if we have at least one of these recovery nodes slowing things down
and implementing rate limiting properly, then the overall process of recovery will be slowed down.
Which gives us this really nice, decentralized rate limiting as a result.
Also because no one recovery node has the whole recovery secret, this means that you'll
one need a threshold of these recovery nodes to collude to even get back the recovery secret.
And even if they find out that the recovery secret, like their malicious, they go behind your
back, they put together recovery secret. That's not entirely a problem because when you go back to
the encrypted envelope, you'll still need the users input for the operev in order to get back the
key used to decrypt that envelope. So this provides our protection against colluding recovery nodes.
Finally, if the user wishes to update their recovery nodes, they consent in notification to the
old recovery nodes. These old recovery nodes will then take their shares and split it up into
sub shares, which they then broadcast to the new recovery nodes. These new recovery nodes can even
be the same nodes as the old recovery nodes. If you just want to do a periodic refresh of the shares
that you hold. So now these new recovery nodes will take these sub sub-subshars of the old recovery
nodes, combine them together using a similar like connect the dots, algorithm, and then they've
got their new shares that are used from this point onward in the consumer process. You can think of
this kind of like if we had all those points on the curve and we just moved around and changed
who held which point. We're still keeping the same shared value, so the operev can still
evaluate with the same encryption key used for that envelope. If you're interested, I wrote a blog
post about this dynamic practice secret sharing that goes into a more at a high level, but I think
we've had enough math for today, so let's wrap up and conclude. So that's been a world
little mock-through of conceugie. Today we've gone through some of the reasons why existing
nton key recovery protocols are lacking and how conceugie addresses their shortcomings.
We've gone through some fun introduction to crypto and finally learned on a deeper level how conceugie
works. With conceugie, our main improvements over existing recovery methods are definitely this aspect
of decentralization. As well, we also don't require any expensive hardware as with those recovery
pins, and we also work in the case of device loss because all you need to remember is your password.
Also conceugie will protect against brute force as we've shown with that rate limiting,
and then also with the colluding recovery notes as we've shown with the opereph evaluation.
As the current state of the project, we've finished the protocol demo as you can see the
GitHub link on the slide, but we've also going to be figuring out how to integrate this with a larger
decentralized access control project run by the Inconcewich Lab. That's called behive and you can
click the link on the slides if you'd like to learn more about it. There's also plenty of non-critical
loose ends that I stopped to get around to implementing like Byzantine fault equivalents and
Byzantine value agreement that I haven't fully gone through yet, but I love to get around to you.
That's about me for me and the conceugie protocol. Again, you can find the slides for the stock
at mly.mas.faston2025 and yeah, I'm happy to take any questions out.
One of the last slides where you were reading the screen, reading the screen, reading the keys,
one of the nodes is untrusted and nothing complied, so we didn't give you back the share of it
yet. I guess you have to have a low enough needed number to reconstruct the T and then
partition it again. So to repeat the question, the question was on this slide,
we need all of these recovery nodes to what happens if one of these recovery nodes doesn't
cooperate with the recovery update process. So you don't need all of them to comply,
you just need a threshold of them to comply, because you just need a threshold of them to reconstruct
to split up the information that was originally held in that shared secret. And then,
as long as you have some threshold of the old nodes that comply, you can then work with their
new threshold and the new community. Let's say one of our team for more of that, and
points don't comply, but in the defense that the provide the incorrect values, is there error checking?
Yeah, so the question was, what happens if the recovery nodes don't provide correct values? Is there
error checking? So right now with the implementation, there's not error checking, but there's
Byzantine value agreement that I saw to implement. I left it at a demo just for time sick and
like for my implementation process, but that's something that you can do in like the theoretical protocol.
Yeah.
Is it necessary that the user is involved in selecting the recovery node or is it possible to
automate which recovery nodes are used? So the question was, does a user have to participate
in selecting which of the recovery nodes are used? I'm not thought about this. I think it's
possible to just do this opaquely and just say we're going to take, here's the ones that you can use
and just like use these. But I guess idea was that users are able to choose for their own benefit,
but I don't think it's, it's not necessary in the protocol. Yeah.
So the question was, what's stopping? If you have recovery nodes that are colluding, what's stopping
them from decryping the envelope? Yeah. So the password is the, well, the blinded password is
what's preventing them from completing the OPRF and going behind your back to get the recovery key.
But because the password is blinded and then there's a whole bunch of like elliptic curve
cryptography in the middle, then like this significantly decreases the risk as opposed to you just
having like a plain password. It can't be done offline. You have to be providing your value.
Yeah.
For another question.
So in some situations, people did all of the servers to update some data like if I changed
the number of nodes that are required for recovery, that means that I have to create a new
polynomial and then I have to upload it all to all the servers or I have to communicate
it all the internal files. So if some of those recovery nodes are down, yeah.
I'm not colluding, they're just trying to evolve and when I want to make a day and then
they switch on again. Yeah. So the question was, it seems like we need to contact all of the
recovery nodes in some situations. What happens if some of them are down? I guess like during
this update process. So you don't have to contact all of them. You only need to contact
a threshold of the old recovery nodes. You will have to contact all of the new recovery nodes or
at least you need to contact a threshold based on the new threshold of the recovery nodes for
the new committee. So you at no point have to contact all of the nodes. So even if there's some
often I notice that works fine.