 Hi everybody, my name is Abita Hawk and today I'd like to talk about our paper Logarithmic Size Linkable Threshold Ring Signatures in the Plane Model. I bolded threshold in the title because that's what I want your main takeaway to be, how we achieved the threshold. Part 1 Background and Contribution Let's start by explaining what a ring signature is. In the ring signature setting, a party wants to send out an authenticated message anonymously on behalf of a set. The set is known as a ring. Anybody can join the ring. So let's suppose we have these three characters, Alice, Bob and Charlie. Alice is going to join by publishing her verification key, VKA, and keep SKA to herself. And similarly, Bob and Charlie can publish VKB and VKC, and keep SKB and SKC to themselves respectively. Now this ring of verification keys is publicly known, so at the time of signing, a signer can pick their ring, and they can sign a message and send it over. Now any verifier can check that it came from somebody within that ring, but they can't tell exactly whom. That leads us to our security properties. A ring signature should be unforgible, meaning that you really do need to have a secret key within the ring to produce a signature. And a ring signature should also be anonymous, meaning that no external observer can tell from whom that signature came. And notice that with an external observer, that can be anybody that's not in the ring, and as well it could be non signers in the ring. So except for process of elimination where they know that it's not them, they can't tell which signer it was. Now in some cases, we don't just want a 1 out of n ring signature, but we want a threshold t out of n ring signature, or thring signature. One way to do this is by having parties interact. So let's say Alice and Bob want to sign a 2 out of 3 thring signature. Well they both know their secret keys, SKA and SKB, and they can use them and interact with each other to produce a signature, where a verifier believes that at least 2 people must have signed. Now any party external to the ring cannot tell which 2 people it was, it could be Bob and Charlie or Charlie and Alice, they don't know. And Charlie of course does know because he knows it wasn't him, but in a bigger ring wouldn't be able to tell which members it was. So that's the first way to get threshold ring signatures. Interaction between parties. Now even though external observers cannot tell which party is signed, at least the signers do have to know each other's identities. Somehow Alice had to find Bob and let him know that there was this message she wanted to sign and he had to agree to work on it with him. In some cases, like voting or a petition where the message is sensitive, signers might not want to have to seek out other people to join their message. Maybe they should be able to just sign a message by themselves and then other people can add themselves as they go, and we can remove the interaction. That's this concept of intersigner anonymous thring signatures. So this is the way that we got thresholdization in our paper with intersigner anonymity and we did it by forcing our ring signature to have a deterministic part to it. With that deterministic part, signers could just sign by themselves and a verifier could check to see if they came from different people without revealing their identities. So you start with this deterministic part and then a verifier given two signatures just checks if that part is equal. For example, let's say that a verifier sees a list of five signatures, then he can parse any two of them and he can check the deterministic part and see if that part is different or if it is the same. And he can conclude then that it came from different or the same signer. Now one thing to note is that we limited this so that the signatures have to be on the same message and ring. This makes it a little bit different from linkable ring signatures, which some people in the audience might be familiar with, where if you sign once, a linkable ring signature once, you're linked forever and a verifier can always check if a signature came from the same person. So in some sense what we've done is more fine-grained than linkability. In fact, we can add linkability to our base construction easily and figure out what scope we want signers to be linked on. So now that we understand ring signatures, let's talk about their security properties in a bit more depth. The adversary is going to ask the challenger, pretend that's me, a lot of different kinds of queries. After seeing all this kind of information, he's either going to produce a new signature, which that's trying to produce a forgery, or he will ask for two honest signers and the challenger, me, will flip a bit and send him back a signature on one of them. And he has to guess which one it is. If he can, he breaks anonymity. Now in either case, the adversary is going to have similar kinds of oracle queries that he can make to me. And those kinds of oracle queries should mimic the real-world behavior that ring signatures have. One thing I want to point out is that because ring signatures are an open setting, remember, everybody could just produce their verification key themselves and just publish it. The adversary could even be a participant in the ring. And that's why it's important to be careful about how we capture the kinds of real-world actions we think an adversary can take. So the four different kinds of queries are these oracles that we've defined to have a truly active adversary. The first one is OSIGN. So here, the adversary is going to ask for signatures on honestly generated keys. For OKGen, the adversary can ask for new keys to be added to the ring honestly. Ocorrupt means he asks on an honestly generated key for the secret key associated to it. And finally, the most important one for us is Oregister, or Oreg, where the adversary actually will produce his own key by himself and send it out. This is important to the open setting of ring signatures and it captures the fact that the adversary can actually maliciously produce a public key. Now that we have talked about ring signatures and their security properties in general, we can talk about our specific construction and proofs. We'll start with the building blocks. There are four building blocks for our construction. The first one is somewhere perfectly binding hashing, or SPB. Two, public key encryption, or PKE. Three, verifiable random function, or VRF. And four, non-interactive witness indistinguishable proof, or NEWI. I point out here that SPB, PKE, and NEWI come from a template of a ring signature scheme that we followed from Bacchus et al from Eurocrypt 19. Our novelty is the use of the VRF to get that threshold with intraciner anonymity and lead to us having to use different proof techniques. Let's explain each building block. I'll start with verifiable random function. A verifiable random function is like a pseudo random function, but you can generate a proof. What do I mean by that? Well, a pseudo random function produces an output that's pseudo random, per the name, which means that nobody can tell whether that output is truly random or it really came from this PRF. A VRF has the same thing, but there's an additional proof that the owner of the secret key can use to prove that that value really did come from the VRF. Like a PRF, there is a secret key, but there's also now a public verification key that anyone can use with the value and proof to believe that it really did come from that VRF. This is a little abstract. The point I want to get across here is that there is public verifiability of a function that produces random looking outputs. The next building block I want to talk about is public key encryption. I think most people in the audience are actually familiar with public key encryption, but there is one property that I want to point out. If there are multiple public keys and there's a ciphertext that has been encrypted on one of them, people cannot tell whose public key was used to create that ciphertext. I have here Alice and ciphertext comes from her public key pKa and Bob ciphertext coming from his public key pKb. Even with a known input, nobody can tell whether it came from Alice or from Bob, except for they themselves who know their secret key. This is a property known as key privacy. The next building block is somewhere perfectly binding hashing, which really just looks like a merkle tree. You take the ring, which is known, and you can write it as a vector and then hash it up as if you were in a tree until you get to the root. And there's the hash value and the hashing key that goes along with it. The difference between somewhere perfectly binding hashing and a merkle tree is we do have this property where at one index, it really has to be that case that we are bound to whatever that value is. That's where that name somewhere perfectly binding comes from. The last building block I want to explain is the non-interactive witness indistinguishable proof. So the non-interactive part means that our prover, Alice, can just pick her witness and statement and she can send out a proof in a single shot without having to interact with any verifier. The witness indistinguishable part means that even if there are multiple witnesses for which the relationship with the statement holds, that the verifier cannot figure out which witness it was that the prover used, even if they know what the witnesses are. One final thing. The newies that we're concerned with have perfect soundness, which means you can't prove a false statement. I think we are now ready we are now ready to start talking about the construction. Remember that a signature construction has three algorithms. Key generation, sign, and verify. We have not put them together yet. We only have building blocks, but now we're ready. And we'll start with key generation and I'll start explaining what sign looks like. The key generation uses the PKE and VRF. The secret key is the secret key of the VRF and the verification key is the verification key of the VRF and the public key of the PKE. So remember, anyone can join the ring so they can create these values on their own and just publish that VK. Then at the time of signing, the signer will start by doing this. They will use their secret key to evaluate the VRF on their message. This is a little bit simplified, but they get a value and a proof. Then they'll use the verification key and they will encrypt the proof of the VRF inside the cipher text. And because the value is pseudo-random and the cipher text hides which key it is, nobody can tell which keys were used to create these two values. We're getting started with the signature. Let's continue. Now, you can't just use any old verification key. You do have to prove membership in the ring. So the NEWI is a NEWI proof that the cipher text encrypts a valid VRF proof under some verification key in the ring and the proof verifies for that value under the VK. And then finally, we need to show that there exists an SPB opening showing that that VK is consistent with H and HK. So our signature so far looks like this. V, CT, H, and HK. None of this reveals the signer and the membership proof with the SPB opening shows that that verification key must be in the ring. So we're almost there, but this is not quite enough. Now, if I just gave you V, CT, H, and HK and gave you a proof that everything was consistent, this seems like it should work out. But we need something more for our proof of anonymity. We need to be able to swap between the witnesses. So there's one more thing that we need to add. I told you before that the SPB binds the signer to their index. They have to prove that H and HK are consistent as part of the NUI. Instead of just doing this once, the signer can do it twice and bind themselves to another index that is not his own. So that gives you H prime and HK prime. Then instead of having a NUI proof that just does everything I told you with all these values being consistent, the signer could create the same proof but for another index at J. Well, he can't actually do this if he doesn't know the secret key for J, so it won't be true. So what's actually going to happen is a NUI is going to be an OR proof where either everything is true for some index I or it's true for index J. So the entire signature ends up looking like V, CT, H, HK, and then V prime, CT prime, H prime, HK prime, where the proof pi says that either the first set of values is true and consistent or the second set of values is true and consistent. And only one of those branches has to be true in an OR proof. So the NUI proof is actually this relationship R with VKI and R with VKJ. The reason that we did this is we needed to be able to do the anonymity proof where we swapped between signers. So remember, the adversary is going to request a signature on one of two signers. He'll pick index I and index J. He'll get back a signature on one of those signers and he has to decide from whom it came. In the proof of anonymity, we show that we can swap between an honest signature for signer I and an honest signature for signer J indistinguishably, thus proving anonymity. And the way that these swaps are done are going to be via hybrid. So at the beginning with an honest signature from signer I, VI, HI, HKI and CTI, those are all true, whereas everything from J is false. An honest signer would just use random values there. Then slowly, with hybrid changes, we start making everything true. But we get to this point where VJ, the VRF associated with signer J, is still false. And something is going to happen that makes it so that we can't make it true. If both of those branches are true, then it's actually possible for an adversary to distinguish that type of signature from the previous hybrid. And the reason for that is if both of these branches for VKI and VKJ are true, then that means both of these VRF values really did come from the VRF, which means they're deterministic and they're constantly put together in this way. An adversary could, for example, just request signatures on all signers and see that these signers I and J were always somehow together, and that would not be indistinguishable from a real signature. So we have come to a problem. Those hybrid changes are not going to work for us. The other thing you could do, maybe, is could you make both branches false and make sure that VI and VJ are both just random values? Well, not really, because the knee-wee has soundness, and so if both branches are false, then the knee-wee overall will be false. So we need some way of making both branches for VKI and VKJ false while still making this overall knee-wee true. We are going to do that by adding one more or into our knee-wee. To make it so that the branch for signer I and for signer J can be false at the same time, we're going to add one more branch. F is a one-way function, and the relationship we're going to ensure is RF, which is F of SKI is equal to SKJ. So our knee-wee is going to be RVKI or RF or RVKJ. Let's look at the hybrids. In the original signature, we want to pick signer I, and so the branch for signer I is true while the remaining two branches for signer J and RF are false. Overall, the knee-wee will be true. Then, at the end, we want signer J's branch to be true while the other two branches are false. We want to hop from real signatures from signer I to real signatures from signer J using the relationship F of SKI is equal to SKJ. We'll make two changes. We can make the relationship RF true, and then we can make the relationship for RVKI be false. Overall, the knee-wee will still be true. Then, moving forward, we can make the relationship for VKJ be true as well. Then, in the final step, we'll make the relationship for RF false. This gives us a real signature from signer J. All of these steps are indistinguishable. All of the changes that we make for the signers themselves have to do with how the VRF works or the public key encryption, and the relationship for RF making that true or false is indistinguishable because one-way functions are hard to invert. But now we have a problem. Unforgibility can't be as strong as we would like it to be because a register is now trivially going to make it so that an adversary can forge. Even though honestly generated keys will never have this relationship, if we allow the adversary to register his own keys, he can easily make it so that he picks two keys such that F of SKI is equal to SKJ. And then he would be able to create as many signatures as he likes. So because of our insistence on being in the plain model and having logarithmic size ring signatures, we lost our ability to have a register. Let's conclude. Why does our work matter? Well, it gives feasibility of a logarithmic size threshold ring signature in the plain model even though it has weakened unforgibility. And it does give us one resultant research question, which is, can we do a compact ring signature with malicious registration and still be in the plain model? Thank you for your attention. If you would like to know more about our work, you can look us up on ePrint or you can email me if you have any questions. Thanks.