 Thank you for this invitation, and it's my pleasure to present this awesome research work. That's the result of a lovely collaboration with Diego Aranya, Matthias Alhannerson, Anka Nikolescu, myself, Elena Panin, and Sofia Jakubov. And as you said, this is can't mean extendability for threshold ring signatures, which is accepted for publication in PKC Public Geographic Conference this year. So to get everybody on stage, let's, on the same let's see what digital signatures are just a quick recap. This is a cryptographic primitives that usually involves four algorithms. We have a setup algorithm that outputs, for instance, the group we are working with or some generic settings, public parameters. We have a key generation algorithm that will output appear a secret signing key and a public sign algorithm that's used together with the secret key and a message to produce a signature and a verification algorithm verify that takes instead the designer's public key that for throughout this presentation, I will represent like this colorful circle and checks that the signature is actually correct for the given message and the given public key. In 2001, Rivens Chamiir and Tauman have proposed the notion of ring signature. So the algorithm is exact in the same except that the verification and procedure instead of taking one single public key as input, it will take a ring, a group of public keys. It's called a ring just for historical reason that the first construction was constructed around the shape that looks like a ring. But essentially, I will have like a set of N potential signer. And what the signature is telling me is proving that one of the signer has signed this message, but and produced a signature, but it doesn't tell me which of those signers doing so. And this is relevant for instance in a Bitcoin application where let's say I want to sign my transactions, but I don't want you to know that every evening I'm signing my transaction from my work computer because then you know that I'm at work and not at home and maybe you can run some of that. And it's also interesting in whistleblowing scenarios where maybe some some employee of an institution wants to say voice out whatever wrongdoings, but they just want to show that they belong to a certain group, to a certain department, they don't want necessarily to expose their identity. Nice. A couple of years later in actually the next year in 2002 crypto, there has been the first scheme of threshold ring signature proposed in the literature. Again, the algorithms are exactly the same, except that now instead of having one potential signer out of N public keys, we have T people that sign out of N possible signers. And this is again very important in for instance with Sir Blowing or if I want to have some threshold cryptography even in Bitcoin, maybe I want to have two factor authentication, two signal two devices that sign the same transaction, but I don't want people to know exactly which combination of two devices I'm using. So this is all cool and amazing, but there are a couple of short timings. So first of all, existing scheme require interaction among signers when producing this threshold signatures, or they can signatures produced by independent signers can be combined together. However, when upon when the signing algorithm is run, all signers need to use the same ring. So essentially, there needs to be a sort of interaction on signer to agree on which ring we are using. In the case of Bitcoin, if it's me signing, it's not that hard. I know which is my ring of public keys, but in the case, for instance, about me to case, I might be just hiding myself within my group, but there will be people from other groups that want to join the same cause. And that's not possible with existing scheme. So we are not particularly happy with these two limitations. And that's essentially what we address in this work. So in this work, we propose extendable threshold ring signature schemes. They have the same algorithms as the threshold ring signature scheme. Plus a couple of twists. We have an extend procedure, which enables anybody to take a signature scheme, t out of n, sorry, a signature t out of n, and expand it to a t out of n prime when n prime is bigger than n. So I can add some potential signers. And then I can also join to get t plus one. So I can increase the threshold by joining a signature on a ring where my public appears. Good. And this is supposed to work in settings such as count me in, me too, I endorse this. What we achieve is that we have a dynamic ring growth and the interaction and no interaction among signers is needed. So we remove those two limitations that are there before. So let's go to a bit more formal with our contribution. First of all, we present this notion of extendability, which essentially is to enlarge the set of tensile signer of a given signature scheme. We do so not just for threshold ring signatures, but also for ring signatures and for same message linkable ring signatures. Then we provide a formal syntax and a security model for each of these primitives with this extendability feature on. And finally, we provide constructions and implementation. We have more or less as many constructions as authors and some implementations. We have construction of extendable ring signatures from signature of knowledge. We have the same message linkable extendable ring signatures constructed in a black box way, given an extendable ring signature, the one that we just constructed on the previous step, and the signature of knowledge again. And then we have extendable threshold ring signature, which is the coolest thing that can be constructed in a black box way from what we just created, the same message linkable extendable ring signature, or a construction that is based on the dialogue. So what I will show you in this presentation is basically the setting for the threshold ring signatures and the construction that we have from the dialogue assumption and signature of knowledge. Let's get started. So threshold ring signatures, they have been there for a while. You see some important references at the bottom of the slides. But in general, how do they work? We have this setup algorithm that takes as input the security parameter and outputs the public parameters. We have a key generator algorithm that takes the public parameters and output a public key and a secret key. Throughout this presentation, the public is going to be always this circle, and the secret key is going to be the circle with a ring around it. The signing algorithm takes an input, a message, a ring of public keys, and one secret key, and produces a signature. And the verification algorithm takes as input a threshold with essentially discounting how many signing key have been used to produce the signature, a message, a signature, and a ring and gives us your one. If there is at least a secret key that have been used to produce the signatures and the secret key belong to the ring, are given in the verification algorithm. Good. So this is what exists already. Yeah, this is the correctness. So at least the secret key needs to have been used to produce the signature S for the message M. Let's go one step further and talk about what is extendable threshold ring signature. So that's what we do in this paper. In this paper, we add the extend algorithm, which will take an input, a message, a signature, an initial ring R1, and a second ring R2, and will produce a new signature S prime. And the idea is that this new signature S prime should verify for the same threshold T as S. But for a larger ring, essentially, you can think of it as like augmenting the anonymity set with more public keys. And we also want to have a join algorithm that takes a message, a signature, and a ring of public keys and a secret key and produces a new signature. And of course, in this case, we want that the threshold of the signature S prime output by the join algorithm is growing by one. So there is one more person endorsing. And what we want to make sure is that the person endorsing is not already somebody that has been used to produce S. So for instance, the trivial idea of like, oh, let me glue together signatures, ring signatures and put them together wouldn't work unless we can prove that the same ring signature has not been produced by the signer, by the same signer. In the same time, they can produce three signatures. And we need to be able somehow to make sure that we are not reusing one person. How do this extend and join interactive? I will try to visualize this in a very intuitive way. And this is formalized in the concept of ladders that you can find in the paper for more details. So imagine that we start with this one out of four signers. So we have four public keys of different colors and one with a ring, which is the one that has been used for signing. If I want to join, now the threshold is going to be two out of four signers. Then maybe I can extend to add more public keys. Here we add like two purple shades, and I get two out of six signers. And then maybe somebody in the purple with the purple secret key joins, and then we end up with three out of six signers. Nice. But I can reach the same three out of six also with a different path. Let's say that I start again from a one out of four signature, but this time it's been the blue person signing. And then maybe I can extend this, getting a one out of five signers signature. Then I can extend it again, getting a one out of six. Then I can join with the purple, and then I can join again with the orange. So we will have two notions of anonymity. The basic one is saying that essentially I cannot distinguish the top or the bottom ones. So threshold signatures that have the same threshold and the same number of users. I cannot distinguish if it's been signed by the red, the orange, and the purple person, or by the blue, the orange, and the purple person. And the stronger version of anonymity instead tells me that I cannot even distinguish which path, which ladder. Have I extended using the left path or have I done all of this extension and joining as the red path. So the security model, let's jump before, before anonymity, we need to have forjability for a digital signature. This is not surprising as a notion that's going to be our adversary here as an owl with bad hacking tools in their hand. They can interact with key generation oracle, they can corrupt keys, and they can interact with a signing oracle. The goal of the adversary is to output a tuple of a threshold, a message, a signature, and a ring of public keys. And he wins the existential forjability game if this tuple output by the adversary verifies. So the verification algorithm returns one. And if the number of corrupted signers in the ring chosen by the adversary is less than t, because of course if the adversary has corrupted more than t signers, then it can of course forge because it has t secret keys. Essentially for the same reason, but a bit more technicality here, we cannot let the adversary interact with a signing oracle for this specific message chosen for the forjability more than t times, because otherwise it could recycle those things. And for anonymity, I already anticipated a little bit with the previous slide on the two ladders, but essentially we give the adversary access to the same oracles as before. But this time the adversary will interact with our amazing challenger to whom he will give a message and two ladders. And the challenger will reply with a signature. And for anonymity, we have that adversary should be able to correctly guess which of the two ladders has been executed by the challenger. And we have two notions of anonymity, and it depends if you allow for ladders to grow even with different lengths, or if you just allow one extension or just a simple you cannot distinguish who is the signer in a given set. That's to give the intuition. Now I think we are ready to see the construction, which is actually the cool thing. As I said before, we have several construction constructions, but I will focus here on the one that I find it more interesting, because it has some nuance in it. The others are I think more straightforward and more like composable with existing notions that I strongly encourage you to check the paper because they are really nice and elegant. But let's look at the more interesting one. So how can we construct this extendable threshold ring signature from the discrete log assumption, and we will also need some public encryption. Let's pick finite field ZP, group G, and an element H in G. These are going to be my public parameters. Then let's also pick three points on ZP. And for these three points, let's pick other three points in G that I have generated using the trapdoor. So I will first sample let's say TD1 and then generate G to the TD1 and call this Y1. Then what I will do, I will do something very similar to Shamir's secret sharing. So I will interpolate the exponent and create a polynomial that is matching these values on the specific axis point. Of course, the polynomial doesn't look like this in reality because we are on discrete fields, but give me an artistic break and let me draw it like it is right now. So now we have a polynomial of degree three of which I know the evaluation on four points. For three of these points, I know trapdoors. So I know the discrete logs and H is a public value. So I don't know the discrete log of that. Now, how can I sign? In order to sign, the idea is like I will sample another point X hat in ZP and I will evaluate the polynomial on this point Y hat. Note that the signer doesn't know the discrete log of Y hat because I've just evaluated a polynomial on a random point. I have not created it with the trapdoor as done before. So my signing procedure is going to be I will produce a signature of knowledge of the following statement that is either I know a witness for the public key, which is indeed the case because I am the signer, I know the secrecy, or I know a witness for this Y hat, which in this case I don't know. So the intuition is in order to produce this proof, the signer is forced to use your secrecy. And then I will create an element in a set P, the set of proofs, which collects this random point X hat that I've chosen from ZP, the evaluation of the polynomial Y hat, my public key, the proof that I just created, and a ciphertext. And the ciphertext is simply going to be an encryption of junk, because it doesn't matter for here, but it will matter when we do extensions. The signature is going to be the set P of proofs. And then another set in this case of three trapdoor points, which are the element in X that I created and the evaluation of the polynomials, on which I know the trapdoors. Now, when I want to extend, I will create again another proof using my signature of knowledge of the statement, which is very similar to the previous one. I'm basically saying I either know the public key pk prime on which I'm extending, or I know a trapdoor for a point in the polynomial. Now, you've seen that when I'm signing, I'm actually creating these trapdoors, this Y1, Y2, Y3, I'm generating them as G to the trapdoor 1, trapdoor 2, trapdoor 3. So I actually know the trapdoors. So when I'm signing, I will start and hide myself into the initial ring. And I will produce this pi, this signature of knowledge, using the trapdoors and not using the public key. And here is where the ciphertext C comes into play. Here I will use the, I will encrypt using the pretending signer encryption public key. I will encrypt the trapdoor for them, so that should they want to join, they can remove themselves, add someone else, and do a proper proof of knowledge. The signature now that we obtained from the extension is going to be a bunch of proof of PJs, obtained as I showed you, and then all the trapdoors that I have not used to do this extension. So this is an extent. How are we going to join? So when I join, I will pick sample another element in ZP, evaluate the polynomial again, and I get my Y hat crime, of which again, I'm behaving almost as a signer. I don't know this is a discrete log. Therefore, I will produce a signature of knowledge of the witness that I either know the secret key of my public key or I know the discrete log of Y prime, which is not the case. And then I will encrypt. So the joint procedure is very similar to the sign in procedure. And then again, what I will output is this signature where I am collecting a set of proofs and a set of trapdoors for the unused points in the polynomial. This is just an intuition. Of course, you can check all of the details. You find them in the paper. This is the very squeezed in algorithm representation of the construction. I don't expect you to read it up here, but I strongly encourage you to have a look, because it's a really cool ideas to obtain this extendability. I just want to spend a couple of words on our implementations. So we do have implementation of two of the schemes that we have. And one of this is actually the extendable thrashing ring signature from the discrete log construction that I've just shown you. So in this graph, you can see in orange, the high monster line is the signature size, which is not too bad, I would say. It's anywhere between 100 bytes and 1 megabyte, so totally doable for the size of rings that go from 1 to 2 people to 2 to 11, so more than 2000. Sorry, 200. No, 2000. 2 to 11. Good. And the running times are fairly short. In particular, we have like 100 milliseconds, so 0.1 second for rings of size of about 250 public keys. And for other construction, we also achieve a few milliseconds for rings of size less than 10. And for rings of size of 248 members, we can create a signature in 0.24 seconds, which is definitely in the realm of practicality. Good. So that was the presentation. I thank you for your attention and very much welcome questions.