 Hi everyone. My name is Sophia and I'm going to be talking about multi-designated verifier signatures or MDVS for short. We make two contributions in this paper. First, we give stronger definitions of MDVS and second, we describe two constructions that meet those stronger definitions. I'd like to start with some motivation for multi-designated verifier signatures. So imagine we have Snow White who works for a corrupt organization. She decides to blow the whistle on the corruption and tell Doc the Dwarf the whole story. And there are several properties of their conversation that are going to be important to Snow White. So first, it's important to her that Doc knows that she's really the one telling the story so that he believes what she's telling him. And of course, he knows that she's really the one telling the story because he's seeing her tell it. Second, it's important to Snow White that Doc not be able to prove to anyone that the story really came from her. Because otherwise, if Doc could prove to the Evil Queen that Snow White tattles, then she could get into a lot of trouble. Of course, if all Doc has a Snow White's spoken word, he can't prove anything to the Evil Queen because for all she knows, Doc made the whole thing up and Snow White wasn't involved at all. But now, imagine that Snow White and Doc weren't actually able to meet in person, maybe because Snow White couldn't get away from the castle. So instead, they communicate on some sort of chat platform. Snow White would really like all the same guarantees that they had before when they were talking in person. And of course, they could use digital signatures to get inforgeability. But digital signatures don't get off the record because Doc can't forge the signature and the Evil Queen knows it. So when Doc shows the Evil Queen Snow White signature, the Evil Queen will know that Snow White tattled. In fact, there's a natural tension between inforgeability and off the record because it's important that no one be able to forge Snow White's signature for Doc, but it's also important that Doc be able to simulate or forge the signature for an outsider. In order to get off the record, Doc and Snow White could instead use a symmetric Mac. So then, Doc will be convinced that Snow White sent the message since she's the only other person who knows the Mac key. But Doc won't be able to convince the Evil Queen because as far as she's concerned, either of them could have produced the Mac since they both know the same key. And a Mac is actually an instance of a designated verifier signature where only the designated verifier is convinced by a signer's signature. The primitive we study is multi-designated verifier signatures. So imagine that Snow White wants to blow the whistle to all the dwarves at the same time. What she'll want to use is a group off the record chat. Here, we want to generalize the inforgeability property to a stronger property. We want to guarantee that all of the chat participants agree on a chat transcript. And of course, a part of that is inforgeability. All of the dwarves should know that if they see a verifying signature from Snow White, then the message really came from Snow White. But there's also another property which we call consistency, which is the guarantee that even if Snow White tries to cause disagreement, she won't be able to. Without the consistency property, Snow White could send a message that only one of the dwarves could verify. And that dwarf would then be unable to convince the rest to accept the message and would disagree with them about what actually happens in the conversation. There are a bunch of prior work in the area of multi-designated verifier signatures, and they all achieve these properties to varying degrees. So let's take a look at inforgeability first. Most of the prior work uses a weak definition of inforgeability that doesn't actually preclude some of the designated verifiers from forging for the other designated verifiers. So the constructions that achieve this weaker notion of inforgeability are marked with a red X on the right. However, there is one paper that does define and use a stronger notion of inforgeability that doesn't allow verifiers to forge for other verifiers. So moving to consistency, on the flip side, consistency is achieved by most prior work, but was never formally defined in them. And finally, all of the prior notions of the off the record property are much weaker than what seems to be really needed here. Those definitions only allow all of the dwarves together to simulate a signature. And this is problematic because the evil queen might know that that couldn't have happened. So for instance, maybe the evil queen knows that happy the dwarf is actually loyal to her and wouldn't help the other dwarves trick her. Or maybe she knows that happy is working undercover and is out of contact with the other dwarves so couldn't have helped with a simulation. The definition we really want here is for any subset of the designated verifiers or dwarves in our case to be able to simulate a signature. And their simulated signature should verify under their own verification keys, but not under the keys of the other dwarves since then it would be a forgery for those other dwarves. There are a few other features of multi designated for our signature constructions that we care about. So for instance, an MDVS scheme has privacy of signer identity if the signature hides who the signer was. And of course, if you remember from the off the record property, any signature should hide whether it's a real signature or a simulation produced by the verifiers. However, if an MDVS scheme also has privacy of signer identity, then anyone other than the designated verifiers shouldn't be able to tell who signed or on whose behalf the simulation is produced if it's a simulation. And finally, of course, we also care about the signature size. In this table, N refers to the number of designated verifiers. So some prior work have constant size signatures while others have signatures whose size depends on the number of verifiers. In our paper, we make several contributions. First, as I mentioned, we strengthen the definitions of MDVS. So we give a definition of off the record, which requires that any subset of verifiers be able to simulate. And we also give the first formal definition of consistency. So next we show that any scheme that meets our stronger definitions must have signatures whose size is at least linear and the number of verifiers. All the schemes in prior work, which have constant size signatures, of course, don't meet our stronger definitions. I'm not going to go into the details of this proof, and instead I'd like to focus on our two constructions. The first of these is based on standard primitives, but doesn't have this privacy of signer identity property. And our second construction is from functional encryption, and so is a little heavier on assumptions and requires a trusted setup to distribute the verification keys. But it does have a privacy of signer identities. Next, I'm going to give an overview of our construction from standard primitives. Recall that the single verifier version of a multi-designated verifier signature is just a designated verifier signature, or a DVS. In a DVS, we have a signer with a secret signing key represented by the quill in the slide and a verifier with a secret verification key, which is the magnifying glass. If we're using a Mac as our DVS, the quill in the magnifying glass actually happened to be the same thing, but this isn't going to be true for most DVS schemes. And also most DVS schemes have public keys for both the signer and the verifier, which I'm not going to put on the slides for simplicity. In an MDVS, we have multiple verifiers, each with their own verification key or magnifying glass. And the idea behind our first MDVS construction is for the signer or Snow White to just use a separate DVS with each verifier. So of course, this gives us unfortunately, since each of the DVSs is unforgible, so their concatenation has to be as well. And we can also get off the record by using a DVS with a few simulation algorithms. So the first one, verifier simulation, is for the designated verifier to use, and it produces a simulation which is indistinguishable from a real signature, even given the verification key. The second simulation algorithm can be used by any third party, and it produces a simulation which is indistinguishable as long as the verification key isn't known. So if we have these two simulation algorithms, any subset of dwarves can simulate by using the verifier simulation algorithm for the designated verifier signatures meant for the dwarves who are participating in simulation, and the public simulation algorithm for the DVSs meant for the other dwarves. The issue here will be consistency. Snow White can easily provide some dwarves with verifying DVSs and other dwarves with DVSs that don't verify, for instance simulations, and then our dwarves won't agree on whether Snow White really sent the message. Our first attempt to fix this is including a zero-knowledge proof that all of the DVSs verify. However, then only all of the dwarves together will be able to simulate since if they're missing even one dwarf, they won't be able to produce a verifying signature for that dwarf, and so won't be able to make this zero-knowledge proof. Instead, what we do is we have Snow White include a zero-knowledge proof that either all of the DVSs verify or they're all simulated. And we do this by using a new primitive which we call a provably simulatable DVS designed to support proofs of realness and proofs of simulatedness. As a quick side note, our favorite example of a DVS, which is a Mac, clearly doesn't have this property since real and simulated signatures are both Macs produced in the exact same way, so you can't really prove where the Mac came from. In our paper, we show how to instantiate provably simulatable DVS or PSDVS efficiently from fairly standard assumptions like DDH. And though it looks from the picture on the slide, like Snow White actually needs a lot of key material, this isn't the case because we let her reuse a single signing key in multiple signatures by using primitives such as non-interactive key exchange. Next, I'd like to give an overview of our second construction, which requires stronger assumptions as well as trusted setup, but has the additional property of privacy of signer identity. We use two building blocks. On the left, we have regular digital signatures with a public verification key and a secret signing key. The signer uses the message together with the secret signing key to create a signature, which can then be verified by anyone using the public verification key. On the right, we have functional encryption. Here we have a public encryption key represented by the padlock and secret decryption keys represented by pickaxes. And each decryption key is associated with some function f. Any member of the general public can encrypt a message using the padlock, and someone who has a decryption key for the function f can then use the cipher text to learn the output of f on the encrypted message. Kind of like we built our first construction up from single verify or DBS, we build this one up from regular digital signatures. So we start by having Snow White send a simple digital signature for which everyone knows the verification key. Of course, the problem here is that anyone can verify, so we don't have any off the record. So what we do is we have Snow White encrypt her signed message together with her verification key using the functional encryption scheme. To enable the dwarfs to verify, we give them all decryption key pickaxes, but the remaining question is, what function should these pickaxes allow the dwarfs to evaluate on the cipher text? As a first attempt, we can give out decryption keys corresponding to the function that checks whether the encrypted signature verifies under Snow White's encrypted verification key. The function returns reject and reject only if the signature doesn't verify and accept together with Snow White's verification key if it does verify. The problem here is still that the dwarfs can't simulate a signature from Snow White, since their decryption keys will only output accept together with Snow White's verification key if a real verifying signature by Snow White was encrypted. So what we do is we additionally hand out signing keys to all the dwarfs and augment the function to check a disjunction of two statements. Either the signature verifies under Snow White's verification key, which is encrypted together with the signature, or the signature verifies under the dwarfs own verification key. And either way, the function should return accept together with Snow White's verification key. Each dwarf can now simulate a signature that verifies under its own key simply by signing the message himself with his own signing key and encrypting that signature. But now we have another problem. Though one dwarf is able to simulate a signature that verifies under its own verification key pickaxe, two dwarfs can't do that. And this is because an encrypted signature that's accepted by two dwarfs, let's say happy and grumpy, must have really been produced by Snow White since if it verifies under Snow White's public key or happy's public key, and also under Snow White's public key or grumpy's public key, the intersection of those two is Snow White's public key. So that must be the key it really verifies under. So we augment the scheme one more time by having Snow White encrypt a list of signatures instead of just one signature. One signature in the list will be her actual signature, and the rest will just be dummy values. Now each dwarfs function will check whether any of the signatures in the list verify under either Snow White's key or that dwarf's key. If the set of dwarfs wants to simulate a signature for the evil queen, they'll all sign the message individually and encrypt the list of all of their signatures. For any dwarf in the set, the ciphertext will verify using that dwarf's functional decryption scheme, since the list will contain a signature by that dwarf himself. And of course it won't verify using the keys of the other dwarfs. When presented with the simulation, the evil queen will have no idea whether it's actually a simulation or Snow White's genuine signature, since both are ciphertexts, which the crypto accepts under the decryption key is belonging to the set of dwarfs that are simulating. So this gets us exactly the notion of off the record we wanted, where any subset of dwarfs can simulate a signature, and that signature looks indistinguishable from a real one, even in the presence of their designated verification keys. We also get inforgeability, since the only way to get a dwarf to accept a message as coming from Snow White is either by signing it using Snow White's signing key or using that dwarf's signing key. And finally, we get consistency, because if Snow White includes her own signature in this list of encrypted signatures, then of course all the dwarfs will accept, and if she doesn't, then none of them will. As I mentioned earlier, this scheme also gets us an extra property called privacy of signer identity, meaning that the signature doesn't actually reveal to the general public who the signer was or on whose behalf the simulation was done. This is true because the signature is actually just a ciphertext, and since the general public doesn't know any of the functional decryption keys, it can't learn anything about the underlying plaintext at all. This is actually all that I wanted to tell you about our two constructions. So I want to thank you very much for listening, and I look forward to hear your questions in the live session. Thanks again.