Stronger Security and Constructions of Multi-designated Verifier Signatures

Abstract

Off-the-Record (OTR) messaging is a two-party message authentication protocol that also provides plausible deniability: there is no record that can later convince a third party what messages were actually sent. The challenge in group OTR, is to enable the sender to sign his messages so that group members can verify who sent a message (signatures should be unforgeable, even by group members). Also, we want the off-the-record property: even if some verifiers are corrupt and collude, they should not be able to prove the authenticity of a message to any outsider. Finally, we need consistency, meaning that if any group member accepts a signature, then all of them do.

To achieve these properties it is natural to consider Multi-Designated Verifier Signatures (MDVS). However, existing literature defines and builds only limited notions of MDVS, where (a) the off-the-record property (source hiding) only holds when all verifiers could conceivably collude, and (b) the consistency property is not considered.

The contributions of this paper are two-fold: stronger definitions for MDVS, and new constructions meeting those definitions. We strengthen source-hiding to support any subset of corrupt verifiers, and give the first formal definition of consistency. We build three new MDVS: one from generic standard primitives (PRF, key agreement, NIZK), one with concrete efficiency and one from functional encryption.

This research was supported by: the Concordium Blockhain Research Center, Aarhus University, Denmark; the Carlsberg Foundation under the Semper Ardens Research Project CF18-112 (BCM); the European Research Council (ERC) under the European Unions’s Horizon 2020 research and innovation programme under grant agreement No 669255 (MPCPRO) and No 803096 (SPEC); the Danish Independent Research Council under Grant-ID DFF-6108-00169 (FoCC); the NSF MACS project.

1 Introduction

Encrypted and authenticated messaging has experienced widespread adoption in recent years, due to the attractive combination of properties offered by, for example, the Signal protocol [Mar13]. With so many conversations happening over the internet, there is a growing need for protocols offering security to conversation participants. Encryption can be used to guarantee privacy of message contents, but authenticating messages while maintaining the properties of an in person conversation is more involved. There are two properties of in person conversations related to authenticity that we wish to emulate in the context of digital conversations:

• Unforgeability, meaning that the receiver should be convinced that the message actually came from the sender in question, and

• Off-the-record or deniability, meaning that the receiver cannot later prove to a third party that the message came from the sender.

Off-the-record (OTR) messaging offers a solution to this in the two-party case, enabling authentication of messages such that participants can convincingly deny having made certain statements, or even having taken part in the conversation at all [BGB04]. The protocol deals with encrypted messages accompanied by a message authentication code (MAC) constructed with a shared key. MACs work well in two-party conversations, because for parties $\mathsf {S}$(ender) and $\mathsf {R}$(eciever) with a shared secret key, a MAC attests ‘this message comes from $\mathsf {S}$ or $\mathsf {R}$’. MACs provide unforgeability, since a party $\mathsf {R}$ receiving a message authenticated with such a MAC knows that if this MAC verifies, the message came from $\mathsf {S}$. MACs provide off-the-record (deniable) communication as $\mathsf {R}$ cannot convince a third party that a message and MAC originally came from $\mathsf {S}$ (since $\mathsf {R}$ could have produced it just as easily). More generally, tools that provide unforgeable, off-the-record two-party communication are known as Designated Verifier Signatures (DVSs, proposed by [JSI96] and [Cha96]).

When there are multiple recipients, for example in group messaging, the situation becomes more complicated. The need for unforgeability can be generalized as the need for all parties in the group to agree on a conversation transcript. There are two components to this: unforgeability, as before, and consistency, which requires that if one recipient can verify a signature, they all can. Without the consistency property, a signer could send a message that only one recipient could verify; that recipient would then be unable to convince the rest to accept that message, and would disagree with them about the transcript of the conversation.

DVSs have been extended to the multiparty setting under the name of Multi-Designated Verifier Signatures (MDVSs) (we give a number of references in Fig. 1). One might hope that these schemes would work for off-the record group messaging; however, it turns out that existing MDVS definitions and schemes do not have the properties one would naturally ask for. In the following section, we give a motivating example illustrating which properties we should actually ask from an MDVS scheme, and we explain how existing schemes fall short of providing them.

1.1 A Motivating Example for MDVS

Imagine a government official $\mathsf {S}$ophia who wants to blow the whistle on some corrupt government activity; e.g., perhaps her colleague, $\mathcal {A}$aron, accepted a bribe.¹ She wants to send a message describing this corruption to $\mathsf {R}$obert, $\mathsf {R}$achel and $\mathsf {R}$ebekah, who are all $\mathsf {R}$eporters at national newspapers.

Naturally, $\mathsf {S}$ophia wants the $\mathsf {R}$eporters to be convinced that she is the true sender of the message. Otherwise, they would have no reason to believe—or print—the story.

Goal 1

(Unforgeability). It is vital that each of the $\mathsf {R}$eporters be able to authenticate that the message came from $\mathsf {S}$ophia.

In order to achieve unforgeability, $\mathsf {S}$ophia produces a signature $\sigma$ using an MDVS scheme, and attaches it to her message. (In such a scheme, each sender has a private signing key and each recipient has a private verification key.) However, blowing the whistle and reporting on $\mathcal {A}$aron’s corrupt activity could put $\mathsf {S}$ophia in danger. If any of $\mathsf {R}$obert, $\mathsf {R}$achel or $\mathsf {R}$ebekah could use $\sigma$ to demonstrate to $\mathcal {A}$aron that $\mathsf {S}$ophia blew the whistle on him, she could lose her position, or face other grave consequences.

Goal 2

(Source-Hiding/Off-the-Record). It is vital that the $\mathsf {R}$eporters be unable to prove to an outsider ($\mathcal {A}$aron) that the message came from $\mathsf {S}$ophia.

One way to guarantee that the $\mathsf {R}$eporters cannot link $\mathsf {S}$ophia to the message is to require that the $\mathsf {R}$eporters can simulate a signature $\sigma$ themselves. Then, if they try to implicate $\mathsf {S}$ophia by showing $\sigma$ to $\mathcal {A}$aron, he would have no reason to believe them; as far as he is concerned, the $\mathsf {R}$eporters could have produced $\sigma$ to try to frame $\mathsf {S}$ophia.

All previous constructions only support off-the-record in the limited sense that all of the $\mathsf {R}$eporters must collaborate in order to produce a simulated signature.² However, this is insufficient. Suppose, for instance, that $\mathcal {A}$aron knows $\mathsf {R}$achel was undercover—and thus unreachable—for the entire time between the bribery taking place, and $\mathsf {R}$obert and $\mathsf {R}$ebekah bringing $\sigma$ to $\mathcal {A}$aron. Then he would conclude that $\mathsf {R}$achel could not have collaborated in simulating $\sigma$, and so it must be genuine. Even with the off-the-record definition used in prior works, it is still possible that some subset of the $\mathsf {R}$eporters would be able to implicate $\mathsf {S}$ophia in the eyes of $\mathcal {A}$aron. We therefore need a stronger off-the-record defintion.

Contribution 1

(Off-The-Record For Any Subset). We give a stronger definition of the off-the-record property, where any subset of $\mathsf {R}$eporters must be able to simulate a signature. A simulation looks like a genuine signature to an outsider, even given the verification keys of the subset that produced it (as well as a number of other signatures that are guaranteed to be genuine).

Under our stronger definition, no set of $\mathsf {R}$eporters is able to use $\sigma$ to provably tie $\mathsf {S}$ophia to the message even if $\mathcal {A}$aron has side information about communication amongst the $\mathsf {R}$eporters as well as guaranteed-to-be-genuine signatures.

Remark 1

(The Tension Between Off-The-Record and Unforgeability). Note that, if $\mathsf {R}$achel did not participate in $\mathsf {R}$obert and $\mathsf {R}$ebekah’s signature simulation (e.g. if she was undercover at the time), she will later be able to distinguish the simulation from a real signature produced by $\mathsf {S}$ophia. Otherwise, $\mathsf {R}$obert and $\mathsf {R}$ebekah would have succeeded in producing a forgery that fools $\mathsf {R}$achel.

This means that under a sufficiently strong model of attack, we cannot have unforgeability and off-the-record at the same time. Namely, suppose $\mathcal {A}$aron first gets a signature $\sigma$ from $\mathsf {R}$obert and $\mathsf {R}$ebekah, while preventing them from communicating with $\mathsf {R}$achel. Then he coerces $\mathsf {R}$achel into giving him her secret verification key. By the unforgeability property, he can use this key to tell if $\sigma$ is a simulation. (Note that $\mathcal {A}$aron will be able to tell whether $\mathsf {R}$achel gives him her true verification key, since he may have other signatures from $\mathsf {S}$ophia that he knows are genuine that he can use to test it. So, she has no choice but to hand over her real verification key.)

Given this observation, we choose to explore the model where the secret keys of all coerced/corrupted verifiers (but not honest ones) can be used to simulate a signature, as this is the strongest model of attack in which both unforgeability and off-the-record can be achieved. As we shall see, even in this model, achieving both properties requires highly non-trivial constructions and implies a lower bound on the size of signatures.

Finally, let us fast forward to the moment when $\mathsf {R}$obert, $\mathsf {R}$achel and $\mathsf {R}$ebekah receive $\mathsf {S}$ophia’s message. They want to print this high-profile story as soon as possible, but of course they want to be sure they won’t make themselves look foolish by printing the story if their colleagues—the other well-respected $\mathsf {R}$eporters listed as recipients—don’t believe it actually came from $\mathsf {S}$ophia. The concern here is that $\mathsf {S}$ophia could be dishonest and her actual goal could be to discredit the $\mathsf {R}$eporters. Hence we need another property—consistency, or designated verifier transferability.

Goal 3

(Consistency/Designated Verifier Transferability). It is desirable that, even if $\mathsf {S}$ophia is malicious, if one of the $\mathsf {R}$eporters can authenticate that the message came from $\mathsf {S}$ophia, all of them can.

Contribution 2

We provide the first formal definition of consistency.

Now that we have covered the basic storyline, let us consider a few possible plot-twists. First, what if $\mathcal {A}$aron is tapping the wires connecting the government building to the outside world? Then he will see $\mathsf {S}$ophia’s message—together with her signature $\sigma$—as she sends it to the $\mathsf {R}$eporters. In such a situation, we would want the signature $\sigma$ not to give $\mathsf {S}$ophia—or the $\mathsf {R}$eporters—away.

Goal 4

(Privacy of Identities). It is desirable that $\sigma$ shouldn’t reveal $\mathsf {S}$ophia’s or the $\mathsf {R}$eporters’ identities³. When only the signer’s—$\mathsf {S}$ophia’s—identity is hidden, this property is called privacy of signer identity (PSI).

Next, what if, at the time at which $\mathsf {S}$ophia has the opportunity to send out her message, she cannot look up $\mathsf {R}$ebekah’s public key securely—perhaps because $\mathsf {R}$ebekah has not yet set up an account on the secure messaging system $\mathsf {S}$ophia uses? Then, it would be ideal for $\mathsf {S}$ophia to need nothing other than $\mathsf {R}$ebekah’s identity (and some global public parameters) in order to include her as a designated verifier. $\mathsf {R}$ebekah would then be able to get the appropriate key from a trusted authority such as the International Press Institute⁴ (having proved that she is, in fact, $\mathsf {R}$ebekah), and would be able to use that key to verify $\mathsf {S}$ophia’s signature.

Goal 5

(Verifier-Identity-Based (VIB) Signing). It is desirable that $\mathsf {S}$ophia should only need the $\mathsf {R}$eporters’ identities, not their public keys, in order to produce her designated verifier signature.

Contribution 3

We give the first three constructions that achieve unforgeability, off-the-record with any-subset simulation, and consistency. One of them additionally achieves privacy of identities and verifier-identity-based signing.

The third construction achieves privacy of verifiers identities (PVI) even if the secret signing key is leaked (but not the random coins used to produce the signature). This is a stronger flavor of the PVI notion with more possible applications, such as Post-Compromise Anonymity guarantees.

This last construction, may, at first glance, seem strictly better; however, the price it pays is two-fold: It uses functional encryption (which requires strong computational assumptions), and it requires an involved trusted setup in which a master secret is used to derive verifier keys. Note that such a trusted setup is clearly necessary in order to achieve verifier-identity-based signing.

In contrast, our first two constructions can be instantiated either in the random oracle model, or with a common reference string—in both cases avoiding the need for a master secret key. They use only standard primitives such as pseudorandom functions, pseudorandom generators, key agreement and NIZKs. The first construction uses these primitives in a black-box way; the second construction uses specific instances of these primitives, for concrete efficiency.

In the following subsections, we give an overview of previous work and then discuss our results in more detail. The main challenge of building stronger MDVS schemes is combining the three core properties we strive for: unforgeability, off-the-record for any subset, and consistency. This is highly non-trivial.

1.2 Flavors of Multi-designated Verifier Signatures

There are many ways to define MDVS and its properties. Figure 1 summarizes the approaches taken by prior work, compared to our own.

Verification. There are several different flavors of verification. In some MDVS schemes, even a single designated verifier cannot link a signature to the signer; the designated verifiers need to work together in order to verify a signature. Thus, we have two notions of verification: local verification and cooperative verification (where all designated verifiers need to cooperate in order to verify the signature).

Remark 2

In the schemes with cooperative verification, we need not additionally require consistency, since we have it implicitly: verifiers will agree on the verification decision they reach together. The notion of consistency is non-interactive, and more challenging to achieve in schemes with local verification.

Simulation. Recall that the off-the-record property states that an outsider cannot determine whether a given signature was created by the signer or simulated by the designated verifiers. We have three flavors of such simulateability: one designated verifier (out of n) can by himself simulate a signature (as done by [Tia12])⁵, all designated verifiers need to collude in order to simulate a signature (all other works on MDVS), or any subset of the designated verifiers can simulate a signature (this paper). Of course, the simulated signature should remain indistinguishable from a real one even in the presence of the secrets held by the simulating parties.

Unforgeability. There is also the standard security property of signature schemes, which is unforgeability; no one (except the signer) should be able to construct a signature that any verifier will accept as a valid signature from that signer. There are two flavors of unforgeability. The first is weak unforgeability, where designated verifiers can forge, but others cannot. The second is strong unforgeability, where a designated verifier can distinguish between real signatures and signatures simulated by other verifiers; that is, even other designated verifiers cannot fool a verifier into accepting a simulated signature.⁶ (In the weak unforgeability game, the adversary does not have access to any designated verifier keys; in the strong unforgeability game, the adversary is allowed access to some such keys.) Since strong unforgeability is the notion of unforgeability we require, in the rest of this paper, unforgeability refers to strong unforgeability (unless otherwise specified).

Fig. 1.

MDVS constructions and their properties. Let $\mathcal {D}$ be the set of designated verifiers, and $t\le |\mathcal {D}|$ be an upper bound on the set of colluding designated verifiers $\mathcal {C}\subseteq \mathcal {D}$.

1.3 Our Contributions

We propose formal definitions of all the relevant security properties of MDVS in the strongest flavor, including the definition of off-the-record with any-subset simulation. We also give the first formal (game based) definition of consistency, where a corrupt signer can collude with some of the designated verifiers to create an inconsistent signature.

Fig. 2.

Our MDVS Constructions and Building Blocks

We then give several different constructions of MDVS that achieve these properties, including local verification, off-the-record with any-subset simulation, and strong unforgeability. Our constructions, and the tools they require, are mapped out in Fig. 2. In particular, these are the first constructions that combine any-subset simulation and with strong unforgeability, as described in Fig. 1. We get these results at the expense of signature sizes that are larger than in some of the earlier constructions. However, this is unavoidable, as shown in Theorem 1 below.

Theorem 1

Any MDVS with any-subset simulation and strong unforgeability must have signature size $\varOmega (| \mathcal {D}|)$.

Remark 3

It may seem from the table that our functional encryption based scheme contradicts the theorem, but this is not the case. It can be instantiated such that signatures can be simulated by collusions up to a certain maximal size $t$, and then signatures will be of size $\varOmega (|\mathcal {C}|)$. However, if we want any subset to be able to simulate, the signature size is $\varOmega (| \mathcal {D}|)$, in accordance with the theorem.

Proof

Imagine that we give all the verifiers’ keys to a sender and a receiver; the sender can now encode an arbitrary subset $\mathcal {C}\subseteq \mathcal {D}$ by letting $\mathcal {C}$ construct a simulated signature $\sigma$ on some default message, and sending it to the receiver. The receiver can infer $\mathcal {C}$ from $\sigma$: by strong unforgeability, all verifiers’ keys outside $\mathcal {C}$ will reject $\sigma$, whereas keys in $\mathcal {C}$ will accept, since we require the simulation to look convincing even given the secret keys in $\mathcal {C}$. It follows that $\sigma$ must consist of enough bits to determine $\mathcal {C}$, which is $\log _2(2^{|\mathcal {D}|}) = |\mathcal {D}|$.    $\square$

Why First Ideas Fail

Using MACs. Black-box usage of a standard MAC scheme cannot help us combine unforgeability with consistency.⁷ There are two straightforward ways to use a standard MAC scheme in this context: sharing a MAC key among the entire group, and sharing MAC keys pairwise. Sharing a single key does not provide the desired notion of unforgeability, since any member of the group can forge messages from any other member. Sharing keys pairwise does not provide the desired notion of consistency. If recipients $\mathsf {R} _1$ and $\mathsf {R} _2$ are the chosen recipients of a message, and $\mathsf {R} _1$ receives a message he accepts as coming from $\mathsf {S}$, he cannot be sure that $\mathsf {R} _2$ would also accept that message: If $\mathsf {S}$ is corrupt, he could include a valid MAC for $\mathsf {R} _1$ and an invalid MAC for $\mathsf {R} _2$.

Using Proofs of Knowledge. A standard technique for making designated verifier signatures for a single verifier is to start from an interactive protocol that proves knowledge of either the signer’s or the verifier’s secret key, and turn this into a signature scheme using the Fiat-Shamir paradigm. It may seem natural to try to build an MDVS from this. However, it turns out to be challenging to achieve strong unforgeability using this technique; a signature cannot consist of a proof of knowledge of the signer’s or one of the verifiers’ secret keys, since any verifier will be able to convince other verifiers to accept a signature that did not come from the signer. For the same reason, a signature cannot consist of a proof of knowledge of the signer’s secret key or some subset of the verifiers’ secret keys.

MDVS from Standard Primitives. Our first class of MDVS constructions is based only on standard primitives. With one exception specified below, all of these constructions can be instantiated in the random oracle model with no trusted setup. (Without random oracles, we would need to set up a common reference string.)

The idea is that the signer creates a DVS signature for each verifier individually, and then proves the consistency of those signatures.⁸. To support such proofs, we define a new primitive called Publicly Simulatable Designated Verifier Signatures (PSDVS) in Sect. 3.1, which is a single-verifier DVS equipped with extra properties. We then show, in Sect. 3.2, that a PSDVS together with a non-interactive zero knowledge proof of knowledge (NIZK-PoK) imply an MDVS for any number of signers and verifiers. Finally, we give some constructions of PSDVS. Our first PSDVS construction (in Sect. 3.3) uses only generic tools, namely psedudorandom functions, non-interactive key exchange (such as Diffie-Hellman), and non-interactive zero-knowledge proofs of knowledge. Our second PSDVS construction (in Sect. 3.4) aims at better concrete efficiency. It is based on DDH, strong RSA and Paillier encryption, is secure in the random oracle model, and requires a constant number of exponentiations for all operations. This scheme requires the trusted generation of an RSA modulus so that the factorization remains unknown. We also sketc.h a variant that requires no trusted setup, is secure in the random oracle model, and only requires (a variant of) the DDH assumption. However, this version requires double discrete log proofs, and therefore requires a non-constant number of exponentiations.

In order to support one of our constructions in which the signer sends an encrypted MAC key, we introduce a new tool we call Authenticated and Verifiable Encryption (AVPKE), which may be of independent interest. This is a variant of Paillier encryption with built-in authentication, and as such it is related to the known primitive “signcryption” [Zhe97]. However, our AVPKE scheme has the additional property that we can give efficient zero-knowledge proofs involving the encrypted message, using the algebraic properties of Paillier encryption.

To sign in our PSDVS schemes, the signer and verifiers first must establish a shared symmetric key $k$. In some cases they can do this non-interactively, using their secret and public keys, while in other cases the signer must send an encrypted key alongside the signature. After this, the signer sends a MAC on the message under key $k$; this MAC is based on a pseudorandom function.

MDVS from Functional Encryption. Our last construction is based on Verifiable Functional Encryption (VFE). It has the advantages of additionally meeting the privacy of identities and verifier-identity-based signing properties. Additionally, it can be set up to have smaller signatures if we are willing to make a stronger assumption on the number of colluding verifiers. Namely, the signature size is $O(t)$, where $t$ is the size of the largest number of colluding verifiers we want to tolerate. The downsides are that, with current state of the art, VFE requires non-standard computational assumptions and a trusted setup.

Remark 4

If we are going to put a bound on the size of a collusion, it may seem we can use bounded collusion FE, which can be realized from standard assumptions [GVW12, AV19], and then there is no need for our other constructions from standard primitives. However, this is not true. Bounded collusion FE requires us to fix the bound on collusion size at key generation time; a bound that may later turn out to be too small. Additionally, ciphertext sizes in bounded collusion FE depend on the bound; thus, choosing a large bound to make sure we can handle the application implies a cost in efficiency. The MDVS signature sizes would depend on some upper bound on number of corrupt parties in the system, as opposed to on the number of recipients for the signature in question, which may be orders of magnitude smaller.

In a nutshell, the idea behind the functional encryption based construction is to do the proof of knowledge of one of the relevant secret keys “inside the ciphertext”. In a little more detail, the idea is to encrypt a list of t standard signatures, where t is the maximal size of collusion we want to protect against (that is, $t \ge |\mathcal {C}|$), and the MDVS signature will simply be this ciphertext. To sign, the signer will generate their own standard signature $\sigma _\mathsf {S}$ on the message, and then encrypt a list a signatures consisting of $\sigma _\mathsf {S}$ followed by $t-1$ dummy values. To verify a signature, a verifier $\mathsf {R}$ gets a functional decryption key that will look at the list of signatures inside the ciphertext and output accept or reject. It will accept if the list contains a valid signature from $\mathsf {S}$ or a valid signature from $\mathsf {R}$. Now, if a corrupt set of verifiers $\mathcal {C}$ wants to simulate a signature, they will all sign the message and encrypt the list of these signatures. By security of the encryption scheme, this looks like a real signature, and will indeed verify under all verification keys belonging to verifiers in $\mathcal {C}$. However, no honest verifier will accept it as a signature from $\mathsf {S}$, so we have strong unforgeability.

2 Multi-designated Verifier Signatures

MDVS Algorithms. A multi-designated verifier signature (MDVS) scheme is defined by the following probabilistic polynomial-time algorithms:

• $\mathsf {Setup}(1^{\kappa }) \rightarrow ({pp}, {msk})$: On input the security parameter $\kappa \in \mathbb {N}$, outputs public parameters ${pp}$ and the master secret key ${msk}$.

• $\mathsf {SignKeyGen}({pp}, {msk}) \rightarrow ({spk}, {ssk})$: On input the public parameter ${pp}$ and the master secret key ${msk}$, outputs the public key ${spk}$ and secret key ${ssk}$ for a signer.

• $\mathsf {VerKeyGen}({pp}, {msk}) \rightarrow ({vpk}, {vsk})$: On input the public parameter ${pp}$ and the master secret key ${msk}$, outputs the public key ${vpk}$ and secret key ${vsk}$ for a verifier.

• $\mathsf {Sign}({pp}, {ssk}_{i}, \{{vpk}_{j}\}_{j\in \mathcal {D}}, m) \rightarrow \sigma$: On input the public parameters ${pp}$, a secret signing key ${ssk}_{i}$, the public keys of the designated verifiers $\{{vpk}_j\}_{j\in \mathcal {D}}$, and a message $m$, outputs a signature $\sigma$.

• $\mathsf {Verify}({pp}, {spk}_{i}, {vsk}_{j}, \{{vpk}_{j'}\}_{j' \in \mathcal {D}}, m, \sigma ) \rightarrow d$: On input the public parameters ${pp}$, a public verification key ${spk}_{i}$, a secret key ${vsk}_{j}$ of a verifier such that $j\in \mathcal {D}$, the public keys of the designated verifiers $\{{vpk}_j\}_{j\in \mathcal {D}}$, a message $m$, and a signature $\sigma$, outputs a boolean decision $d$: $d= 1$ (accept) or $d= 0$ (reject).

• $\mathsf {Sim}({pp}, {spk}_{i}, \{{vpk}_{j}\}_{j\in \mathcal {D}}, \{{vsk}_{j}\}_{j\in \mathcal {C}}, m) \rightarrow \sigma '$: On input public parameters ${pp}$, a public verification key ${spk}_{i}$, the public keys of the designated verifiers $\{{vpk}_j\}_{j\in \mathcal {D}}$, the secret keys of the corrupt designated verifiers $\{{vsk}_{j}\}_{j\in \mathcal {C}}$, and a message $m$, outputs a simulated signature $\sigma '$.

The different algorithms take many different inputs, which are not all needed for all of our constructions. Thus, to simplify the notation we exclude these inputs in later sections whenever they are not needed.

MDVS Properties. Let $\sigma$ be a signature from signer $i$ on message $m$ and designated for verifiers $\mathcal {D}$. We ask for the following (informal) properties:

• Correctness: All verifiers $j\in \mathcal {D}$ are able to verify an honestly generated signature $\sigma$.

• Consistency: If there exists one verifier $j\in \mathcal {D}$ that accepts the signature $\sigma$, then all other designated verifiers (i.e. all $j' \in \mathcal {D}{\setminus }\{j\}$) also accept $\sigma$.

• Unforgeability: An adversary without knowledge of the secret key ${ssk}_{i}$ for signer $i$ cannot create a signature $\sigma '$ that is accepted by any designated verifier as a signature from signer $i$.

• Off-The-Record: Given a signature $\sigma$, any malicious subset of the designated verifiers $\mathcal {C}\subseteq \mathcal {D}$ cannot convince any outsider that $\sigma$ is a signature from signer $i$ (i.e. the malicious set could have simulated the signature themselves).

• (Optionally) Privacy of Identities: Any outsider (without colluding with any designated verifiers) cannot determine the identity of the signer and/or the identities of the designated verifiers.

• (Optionally) Verifier-Identity-Based Signing: The signer should be able to produce a signature for a set of designated verifiers without requiring any information about them apart from their identities. In other words, we should have ${vpk}_{j} = j$ for a verifier with identity $j$.

Throughout our formal definitions we use the following six oracles:

• Signer Key Generation Oracle: $\mathcal {O}_{SK}(i)$

  • 1. If a signer key generation query has previously been performed for $i$, look up and return the previously generated key.

  • 2. Otherwise, output and store $({spk}_{i},{ssk}_{i}) \leftarrow \mathsf {SignKeyGen}({pp}, {msk})$.

• Verifier Key Generation Oracle: $\mathcal {O}_{VK}(j)$

  • 1. If a verifier key generation query has previously been performed for $j$, look up and return the previously generated key.

  • 2. Otherwise, output and store $({vpk}_{j},{vsk}_{j}) \leftarrow \mathsf {VerKeyGen}({pp}, {msk})$.

• Public Signer Key Generation Oracle: $\mathcal {O}_{SPK}(i)$

  • 1. $({spk}_{i}, {ssk}_{i}) \leftarrow \mathcal {O}_{SK}(i)$.

  • 2. Output ${spk}_{i}$.

• Public Verifier Key Generation Oracle: $\mathcal {O}_{VPK}(j)$

  • 1. $({vpk}_{j}, {vsk}_{j}) \leftarrow \mathcal {O}_{VK}(j)$.

  • 2. Output ${vpk}_{j}$.

• Signing Oracle: $\mathcal {O}_{S}(i, \mathcal {D}, m)$

  • 1. $({spk}_{i}, {ssk}_{i}) \leftarrow \mathcal {O}_{SK}(i)$.

  • 2. For all $j\in \mathcal {D}$: ${vpk}_{j} \leftarrow \mathcal {O}_{VPK}(j)$.

  • 3. Output $\sigma \leftarrow \mathsf {Sign}({pp}, {ssk}_{i}, \{{vpk}_j\}_{j\in \mathcal {D}}, m)$.

• Verification Oracle: $\mathcal {O}_{V}(i, j, \mathcal {D}, m, \sigma )$

  • 1. ${spk}_{i} \leftarrow \mathcal {O}_{SPK}(i)$.

  • 2. $({vpk}_{j}, {vsk}_{j}) \leftarrow \mathcal {O}_{VK}(j)$.

  • 3. Output $d\leftarrow \mathsf {Verify}({pp}, {spk}_{i}, {vsk}_{j}, \{{vpk}_{j'}\}_{j' \in \mathcal {D}}, m, \sigma )$.

Definition 1

(Correctness). Let $\kappa \in \mathbb {N}$ be the security parameter, and let $\mathsf {MDVS}=(\mathsf {Setup},\mathsf {SignKeyGen},\mathsf {VerKeyGen},\mathsf {Sign},\mathsf {Verify},\mathsf {Sim})$ be an MDVS scheme. $\mathsf {MDVS}$ is correct if for all signer identities $i$, messages $m$, verifier identity sets $\mathcal {D}$ and $j\in \mathcal {D}$, it holds that

$$\begin{aligned} \mathsf {Pr}\left[ \mathsf {Verify}({pp}, {spk}_{i}, {vsk}_{j}, \{{vpk}_{j'}\}_{j' \in \mathcal {D}}, m, \sigma ) \ne 1 \right] =0, \end{aligned}$$

where the inputs to $\mathsf {Verify}$ are generated as follows:

• $({pp}, {msk}) \leftarrow \mathsf {Setup}(1^{\kappa })$;

• $({spk}_{i}, {ssk}_{i}) \leftarrow \mathsf {SignKeyGen}({pp}, {msk}, i)$;

• $({vpk}_{j}, {vsk}_{j}) \leftarrow \mathsf {VerKeyGen}({pp}, {msk}, j)$ for $j\in \mathcal {D}$;

• $\sigma \leftarrow \mathsf {Sign}({pp}, {ssk}_{i}, \{{vpk}_{j}\}_{j\in \mathcal {D}}, m)$.

In Definition 1, we require that all the designated verifiers can verify the signature, without considering what happens for parties that are not designated verifiers (i.e. parties who should not be able to verify the signature). Parties that are not designated verifiers are accounted for by the off-the-record property.

Definition 2

(Consistency). Let $\kappa \in \mathbb {N}$ be the security parameter, and let $\mathsf {MDVS}=(\mathsf {Setup},\mathsf {SignKeyGen},\mathsf {VerKeyGen},\mathsf {Sign},\mathsf {Verify},\mathsf {Sim})$ be an MDVS scheme. Consider the following game between a challenger and an adversary $\mathcal {A}$:

We say that $\mathcal {A}$ wins the game if there exist verifiers $j_0,j_1\in \mathcal {D}^*$ such that:

$$\begin{aligned} \mathsf {Verify}({pp}, {spk}_{i^*},{vsk}_{j_0},\{{vpk}_{j'}\}_{j' \in \mathcal {D}^*}, m^*,\sigma ^*)&= 0, \\ \mathsf {Verify}({pp}, {spk}_{i^*},{vsk}_{j_1},\{{vpk}_{j'}\}_{j' \in \mathcal {D}^*}, m^*,\sigma ^*)&= 1, \end{aligned}$$

where all keys are the honestly generated outputs of the key generation oracles, and $\mathcal {O}_{VK}$ is never queried on $j_0$ or $j_1$.

$\mathsf {MDVS}$ is consistent if, for all PPT adversaries $\mathcal {A}$,

$$\begin{aligned} \mathsf {adv}^{con}_{\mathsf {MDVS},\mathcal {A}}(\kappa ) = \Pr \left[ \mathcal {A}\text { wins } \mathsf {Game}^{con}_{\mathsf {MDVS},\mathcal {A}}(\kappa ) \right] \le \mathsf {negl}(\kappa ). \end{aligned}$$

Definition 2 states that even a valid signer (i.e. someone who knows a secret signing key) cannot create an inconsistent signature that will be accepted by some designated verifiers and rejected by others. By the correctness property, an honestly generated signature is accepted by all designated verifiers. By design, corrupt designated verifiers can construct an inconsistent signature, since some verifiers will accept it (i.e. those verifiers that created it), while the remaining honest designated verifiers will reject the simulated signature. Thus, we need to ask for $j\ne j_0,j_1$ for all queries $j$ to the oracle $\mathcal {O}_{VK}$.

Definition 3

(Existential Unforgeability). Let $\kappa \in \mathbb {N}$ be the security parameter, and let $\mathsf {MDVS}=(\mathsf {Setup},\mathsf {SignKeyGen},\mathsf {VerKeyGen},\mathsf {Sign},\mathsf {Verify},\mathsf {Sim})$ be an MDVS scheme. Consider the following game between a challenger and an adversary $\mathcal {A}$:

We say that $\mathcal {A}$ wins the game if we have all of the following:

• for all queries $i$ to oracle $\mathcal {O}_{SK}$, it holds that $i^* \ne i$;

• for all queries $(i,\mathcal {D},m)$ to oracle $\mathcal {O}_{S}$ that result in signature $\sigma$, it holds that $(i^*,\mathcal {D}^*,m^*) \ne (i,\mathcal {D},m)$;

• there exists a verifier $j'\in \mathcal {D}^*$ such that for all queries $j$ to oracle $\mathcal {O}_{VK}$, it holds that $j' \ne j$ and

  $$\begin{aligned} \mathsf {Verify}({pp}, {spk}_{i^*},{vsk}_{j'},\{{vpk}_{j''}\}_{j''\in \mathcal {D}^*},m^*,\sigma ^*) = 1, \end{aligned}$$

  where all keys are honestly generated outputs of the key generation oracles.

$\mathsf {MDVS}$ is existentially unforgeable if, for all PPT adversaries $\mathcal {A}$,

$$\begin{aligned} \mathsf {adv}^{euf}_{\mathsf {MDVS},\mathcal {A}}(\kappa ) = \Pr \left[ \mathcal {A}\text { wins }\mathsf {Game}^{euf}_{\mathsf {MDVS},\mathcal {A}}(\kappa ) \right] \le \mathsf {negl}(\kappa ). \end{aligned}$$

Definition 3 states that an adversary cannot create a signature that any honest verifier will accept as coming from a signer whose secret signing key the adversary does not know. The adversary will always get the public keys of the involved parties, i.e. signer with identity $i^*$ and the designated verifiers $\mathcal {D}$, through the key generation oracles. He is also allowed to obtain the secret keys of every party except the signer $i^*$ and at least one designated verifier. The reason why we need at least one honest verifier is that corrupt verifiers can create a simulated signature that will look like a real signature with respect to their own verifier secret keys. However, this simulation will be rejected by any honest designated verifier, i.e. the simulation will be a valid forgery for the corrupt verifiers, but not for the honest verifiers.

Definition 4

(Off-The-Record). Let $\kappa \in \mathbb {N}$ be the security parameter, let $\mathsf {MDVS}=(\mathsf {Setup},\mathsf {SignKeyGen},\mathsf {VerKeyGen},\mathsf {Sign},\mathsf {Verify},\mathsf {Sim})$ be an MDVS scheme, and let $t$ be an upper bound on the number of verifiers an adversary $\mathcal {A}$ can corrupt. Consider the following game between a challenger and a stateful adversary $\mathcal {A}$, where all keys are honestly generated outputs of the key generation oracles:

We say that $\mathcal {A}$ wins the game if $b' = b$, and all of the following hold:

• $|\mathcal {C}^*| \le t$ and $\mathcal {C}^* \subseteq \mathcal {D}^*$;

• for all queries $i$ to oracle $\mathcal {O}_{SK}$ it holds that $i^* \ne i$;

• for all queries $j$ to oracle $\mathcal {O}_{VK}$ it holds that $j\notin \mathcal {D}^* \backslash \mathcal {C}^*$;

• for all queries $(i, j, \mathcal {D}, m, \sigma )$ to $\mathcal {O}_{V}$ it holds that $\sigma _b \ne \sigma$.

We say that an MDVS scheme is $t$-off-the-record if, for all PPT adversaries $\mathcal {A}$,

$$ \mathsf {adv}^{otr}_{\mathsf {MDVS},\mathsf {Sim},\mathcal {A}}(\kappa ) = \Pr \left[ \mathcal {A}\text { wins }\mathsf {Game}^{otr}_{\mathsf {MDVS},\mathsf {Sim},\mathcal {A}}(\kappa ) \right] - \frac{1}{2}\le \mathsf {negl}(\kappa ). $$

If a scheme supports $t= |\mathcal {D}|$, we say that it is off-the-record.

Definition 4 states that any adversary that corrupts a subset (of size $t$) of the designated verifiers $\mathcal {C}^*$ cannot determine whether the received signature was created by real signer $i^*$ or simulated by the corrupt verifiers $\mathcal {C}^*$. The adversary is not allowed to see the secret keys for the designated verifiers that are in $\mathcal {D}^*\backslash \mathcal {C}^*$. If the adversary was allowed to get secret keys of additional parties in $\mathcal {D}^*$ (which are not in $\mathcal {C}^*$), then he would be able to distinguish trivially, since any honest designated verifiers (i.e. any $j\in \mathcal {D}^* \backslash \mathcal {C}^*$) can distinguish simulated signatures from real signatures (from the unforgeability property).

Definition 5

(Privacy of Identities). Let $\kappa \in \mathbb {N}$ be the security parameter, and let $\mathsf {MDVS}=(\mathsf {Setup},\mathsf {SignKeyGen},\mathsf {VerKeyGen},\mathsf {Sign},\mathsf {Verify},\mathsf {Sim})$ be an MDVS scheme. Consider the following game between a challenger and a stateful adversary $\mathcal {A}$, where all keys are the honestly generated outputs of the key generation oracles:

We say that $\mathcal {A}$ wins the game if $b = b'$, and all of the following hold:

• $|\mathcal {D}_0| = |\mathcal {D}_1|$;

• for all queries $i$ to $\mathcal {O}_{SK}$, it holds that $i\notin \{i_0, i_1\}$;

• for all gueries $j$ to $\mathcal {O}_{VK}$, it holds that $j\notin \mathcal {D}_0 \cup \mathcal {D}_1$;

• for all queries $(i,j,\mathcal {D}, m, \sigma )$ to $\mathcal {O}_{V}$, it holds that $\sigma ^* \ne \sigma$.

$\mathsf {MDVS}$ has privacy of identities if, for all PPT adversaries $\mathcal {A}$,

$$\begin{aligned} \mathsf {adv}^{pri}_{\mathsf {MDVS},\mathcal {A}}(\kappa ) = \Pr \left[ \mathcal {A}\text { wins } \mathsf {Game}^{pri}_{\mathsf {MDVS},\mathcal {A}}(\kappa ) \right] - \frac{1}{2} \le \mathsf {negl}(\kappa ). \end{aligned}$$

We say that $\mathsf {MDVS}$ has additional properties as follows:

• privacy of the signer’s identity (PSI) if we make the restriction that $\mathcal {D}_0 = \mathcal {D}_1$;

• privacy of the designated verifiers’ identities (PVI) if we make the restriction that $i_0 = i_1$.

Definition 5 states that an adversary cannot distinguish between signatures from two different signers (PSI) if he does not know the secret key of any of the signers or designated verifiers (as designated verifiers are allowed to identify the signer). Furthermore, it should not help him to see other signatures that he knows are from the signers in question.

In addition, if we vary the verifier sets ($\mathcal {D}_0 \ne \mathcal {D}_1$), then the MDVS scheme has privacy of designated verifier’s identities (PVI), which means that any outsider without knowledge of any secret keys cannot distinguish between signatures meant for different verifiers.

Definition 6

(Verifier-Identity-Based Signing). We say that an MDVS scheme has verifier-identity-based signing if for honestly generated verifier keys $({vsk}_{j}, {vpk}_{j})$ for verifier with identity $j$, we have ${vpk}_{j} = j$.

Note that, in order to achieve verifier-identity-based signing, verifier key generation must require a master secret key ${msk}$. Otherwise, any outsider would be able to generate a verification key for verifier $j$, and use it to verify signatures meant only for that verifier.

Relation to Previous Definitions. Our definition of MDVS is consistent with previous work in this area, but with some differences. Our MDVS syntax closely follows the one introduced by [LV04], but we allow for a master secret key in the case where the keys are generated by a trusted party (like in our construction based on functional encryption). Our security definitions are adapted from those in [LV04, ZAYS12] to capture the flexibility introduced by allowing any subset of designated verifiers to simulate a signature, thus providing better deniability properties. Finally, we formalize consistency as an additional and desirable requirement.

3 Standard Primitive-Based MDVS Constructions

In this section we show how to create an MDVS scheme that uses only standard primitives, such as key exchange, commitments, pseudorandom functions and generators, and non-interactive zero knowledge proofs.

On a high level, one way to build an MDVS is for the signer to use a separate DVS with each verifier; the MDVS signature would then consist of a vector of individual DVS signatures. This gives us almost everything we need—the remaining issue is consistency. Each verifier can verify one of the DVS signatures, but is not convinced that all of the other verifiers will come to the same conclusion.

A solution to this consistency issue is to include as part of the MDVS signature a zero knowledge proof that all of the DVS signatures verify. However, this introduces a new issue with off-the-record. Now, a colluding set of verifiers will not be able to simulate a signature unless all of the verifiers collude. In order to produce such a convincing zero knowledge proof as part of the signature, they would need to forge signatures for the other verifiers in the underlying DVS scheme, which they should not be able to do.

So, instead of using a zero knowledge proof of knowledge that all of the DVS signatures verify, we use a proof that either all of the DVS signatures verify, or they are all simulated. Then, a corrupt set of verifiers can simulate all of the underlying DVS signatures—with the caveat that the signatures they simulate for themselves should be convincing simulations even in the presence of their secret keys—and, instead of proving that all of the signatures verify, they prove that all of the signatures are simulations.

3.1 New Primitive: Provably Simulatable Designated-Verifier Signatures (PSDVS)

Designated Verifier Signatures (DVS) have a simulation algorithm $\mathsf {Sim}$ which is used to satisfy the off-the-record property. Given the signer’s public key, the verifier’s secret key and a message $m$, $\mathsf {Sim}$ should return a signature which is indistinguishable from a real signature. A Provably Simulatable DVS (PSDVS) has some additional properties:

Definition 7

A PSDVS must satisfy the standard notions of correctness and existential unforgeability. Additionally, it should satisfy PubSigSim indstinguishability (Definition 8), PubSigSim correctness (Definition 9), PubSigSim soundness (Definition 10), VerSigSim indstinguishability (Definition 11), VerSigSim correctness (Definition 12), VerSigSim soundness (Definition 13), provable signing correctness (Definition 14), and provable signing soundness (Definition 15).

Provable Public Simulation. As in PSI (Definition 5), anyone should be able to produce a signature that is indistinguishable from a real signature. Additionally, the party simulating the signature should be able to produce a proof that this is not a real signature. This proof will be incorporated into the MDVS proof of consistency; the colluding verifiers, when producing a simulation, need to prove that all underlying PSDVS signatures are real, or that they are all fake.

In other words, we require two additional algorithms, as follows:

• 1. $\mathsf {PubSigSim}({pp}, {spk}, {vpk}, m) \rightarrow (\sigma , \pi )$

• 2. $\mathsf {PubSigVal}({pp}, {spk}, {vpk}, m, \sigma , \pi ) \rightarrow d\in \{0,1\}$

The colluding verifiers will produce a public simulation in the underlying PSDVS for verifiers outside their coalition, and use $\mathsf {PubSigSim}$ to prove that this simulation is not a real signature. $\pi$ will not be explicitly included in the proof of “the underlying PSDVS signatures are all real or all fake,” of course, as it would give away the fact that all underlying signatures are fake, as opposed to all being real; rather, it will be wrapped in a larger zero knowledge proof.

Definition 8

(PubSigSim Indistinguishability). We say that the PSDVS has PubSigSim Indistinguishability if $\mathsf {PubSigSim}$ produces a signature $\sigma$ that is indistinguishable from real. More formally, an adversary should not be able to win the following game with probability non-negligibly more than half:

We say that $\mathcal {A}$ wins the PubSigSim-Ind game if $b = b'$ and for all queries $(m,\sigma )$ to $\mathcal {O}_{V}$, it holds that $(m, \sigma ) \ne (m^*, \sigma _b)$.

Definition 9

(PubSigSim Correctness). We say that the PSDVS has PubSigSim Correctness if for all ${pp}\leftarrow \mathsf {Setup}(1^\kappa )$; $({spk}, {ssk}) \leftarrow \mathsf {SignKeyGen}({pp})$; $({vpk}, {vsk}) \leftarrow \mathsf {VerKeyGen}({pp})$; $m\in \{0,1\}^{*}$; $(\sigma , \pi ) \leftarrow \mathsf {PubSigSim}({pp}, {spk}, {vpk}, m)$;

$$\begin{aligned} \Pr [\mathsf {PubSigVal}({pp}, {spk}, {vpk}, m, \sigma , \pi ) = 1] = 1. \end{aligned}$$

Definition 10

(PubSigSim Soundness). We say that the PSDVS has PubSigSim Soundness if it is hard to construct a signature $\sigma$ which is accepted by the verifier algorithm and at the same time can be proven to be a simulated signature. More formally, an adversary should not be able to win the following game with non-negligible probability:

We say that $\mathcal {A}$ wins the PubSigSim-Sound game if $\mathsf {Verify}({pp}, {vsk}, m^*, \sigma ^*) = 1$ and $\mathsf {PubSigVal}({pp}, {spk}, {vpk}, m^*, \sigma ^*, \pi ^*) = 1$.

Provable Verifier Simulation. As in off-the-record (Definition 4), a verifier should be able to produce a signature that is indistinguishable from a real signature, even given its secret key. Additionally, the verifier should be able to produce a proof that the signature is not a real signature (that is, that the verifier, and not the signer, produced it). This proof will be incorporated into the MDVS proof of consistency.

In other words, we require two additional algorithms, as follows:

• 1. $\mathsf {VerSigSim}({pp}, {spk}, {vpk}, {vsk}, m) \rightarrow (\sigma , \pi )$

• 2. $\mathsf {VerSigVal}({pp}, {spk}, {vpk}, m, \sigma , \pi ) \rightarrow d\in \{0,1\}$

The colluding verifiers will produce a verifier simulation in the underlying PSDVS for verifiers inside their coalition, and use $\mathsf {VerSigSim}$ to prove that this simulation is not a real signature.

Definition 11

(VerSigSim Indistinguishability). We say that the PSDVS has VerSigSim Indistinguishability if $\mathsf {VerSigSim}$ produces a signature $\sigma$ that is indistinguishable from real. More formally, an adversary should not be able to win the following game with probability non-negligibly more than half:

We say that $\mathcal {A}$ wins the VerSigSim-Ind game if $b = b'$.

Definition 12

(VerSigSim Correctness). We say that the PSDVS has VerSigSim Correctness if for all ${pp}\leftarrow \mathsf {Setup}(1^\kappa )$, $({spk}, {ssk}) \leftarrow \mathsf {SignKeyGen}({pp})$, $({vpk}, {vsk}) \leftarrow \mathsf {VerKeyGen}({pp})$, $m\in \{0,1\}^{*}$, $(\sigma , \pi ) \leftarrow \mathsf {VerSigSim}({pp}, {spk}, {vpk}, {vsk}, m)$,

$$\begin{aligned} \Pr [\mathsf {VerSigVal}({pp}, {spk}, {vpk}, m, \sigma , \pi ) = 1] = 1. \end{aligned}$$

Definition 13

(VerSigSim Soundness). We say that the PSDVS has VerSigSim Soundness if the signer is not able to produce $\sigma$ and $\pi$ that pass the validation check $\mathsf {VerSigVal}$, i.e. $\pi$ is a proof that $\sigma$ was not produced by the signer. More formally, an adversary should not be able to win the following game with non-negligible probability:

$\mathcal {A}$ wins the VerSigSim-Sound game if $\mathsf {VerSigVal}({pp}, {spk}, {vpk}, m^*, \sigma ^*, \pi ^*) = 1$.

Provable Signing. Lastly, we require a provable variant of signing, so that the signer is able to produce a proof that a signature is real. In other words, we require the signing algorithm $\mathsf {Sign}({pp}, {spk}, {ssk}, {vpk}, m) \rightarrow (\sigma , \pi )$ to output $\pi$ as well. We also require one additional validation algorithm, as follows:

$$\begin{aligned} \mathsf {RealSigVal}({pp}, {spk}, {vpk}, m, \sigma , \pi ) \rightarrow d\in \{0,1\}\end{aligned}$$

Definition 14

(Provable Signing Correctness). We say that the PSDVS has Provable Signing Correctness if $\forall {pp}\leftarrow \mathsf {Setup}(1^\kappa )$, $({spk}, {ssk}) \leftarrow \mathsf {SignKeyGen}({pp})$, $({vpk}, {vsk}) \leftarrow \mathsf {VerKeyGen}({pp})$, $m\in \{0,1\}^{*}$, $(\sigma , \pi ) \leftarrow \mathsf {Sign}({pp}, {spk}, {ssk}, {vpk}, m)$,

$$\begin{aligned} \Pr [\mathsf {RealSigVal}({pp}, {spk}, {vpk}, m, \sigma , \pi ) = 1] = 1. \end{aligned}$$

Definition 15

(Provable Signing Soundness). We say that the PSDVS has Provable Signing Soundness if the proof of correctness $\pi$ produced by $\mathsf {Sign}$ does not verify unless $\sigma$ verifies. More formally, an adversary should not be able to win the following game with non-negligible probability:

We say that $\mathcal {A}$ wins the Sign-Sound game if $\mathsf {RealSigVal}({pp}, {spk}, {vpk}, m^*, \sigma ^*, \pi ^*) = 1$ and $\mathsf {Verify}({pp}, {spk}, {vsk}, m^*, \sigma ^*) = 0$.

Note that none of these proofs $\pi$ are parts of the signature. If included in the signature, such proofs would allow an adversary to distinguish a simulation from a real signature.

3.2 Standard Primitive-Based MDVS Construction

Given a PSDVS, as defined in Sect. 3.1, we can build an MDVS. The transformation is straightforward: the signer uses the PSDVS to sign a message for each verifier, and proves consistency using a non-interactive zero knowledge proof of knowledge. The proof of consistency will claim that either all of the PSDVS signatures verify, or all of them are simulated.

Construction 1

Let $\mathsf {PSDVS}= (\mathsf {Setup},\ \mathsf {SignKeyGen},\ \mathsf {VerKeyGen},\ \mathsf {Sign}, \mathsf {Verify}, \mathsf {RealSigVal},\mathsf {PubSigSim}, \mathsf {PubSigVal}, \mathsf {VerSigSim}, \mathsf {VerSigVal})$ be a provably simulatable designated verifier signature scheme, and $\mathsf {NIZK\text {-}PoK}= (\mathsf {Setup}, \mathsf {Prove}, \mathsf {Verify})$ be a non-interactive zero knowledge proof of knowledge system and $\mathcal {R}_{cons}$ a relation that we will define later in the protocol.

• $\mathsf {Setup}(1^{\kappa })$:

  • 1. ${crs}\leftarrow \mathsf {NIZK\text {-}PoK}{.}\mathsf {Setup}(1^{\kappa }, \mathcal {R}_{cons})$.

  • 2. $\mathsf {PSDVS}{.}{pp}\leftarrow \mathsf {PSDVS}{.}\mathsf {Setup}(1^{\kappa })$.

  Output $({crs}, \mathsf {PSDVS}{.}{pp})$ as the public parameters ${pp}$.

• $\mathsf {SignKeyGen}({pp})$: $({spk}_{i}, {ssk}_{i}) \leftarrow \mathsf {PSDVS}{.}\mathsf {SignKeyGen}(\mathsf {PSDVS}{.}{pp})$.

  Output $({spk}_{i}, {ssk}_{i})$ as signer ${i}$’s public/secret key pair.

• $\mathsf {VerKeyGen}({pp})$: $({vpk}_{j}, {vsk}_{j}) \leftarrow \mathsf {PSDVS}{.}\mathsf {VerKeyGen}(\mathsf {PSDVS}{.}{pp})$.

  Output $({vpk}_{j}, {vsk}_{j})$ as verifier ${j}$’s public/secret key pair.

• $\mathsf {Sign}({pp},{ssk}_{i}, \{{vpk}_{j}\}_{j\in \mathcal {D}},m)$:

  • 1. For every verifier $j\in \mathcal {D}$, compute a signature and proof of signature validity as $(\sigma _{j}, \pi _{j}) \leftarrow \mathsf {PSDVS}{.}\mathsf {Sign}(\mathsf {PSDVS}{.}{pp}, {ssk}_{i}, {vpk}_{j}, m)$.

  • 2. Create a proof $\pi$ of consistency, i.e a proof of knowledge of $\{\pi _{j}\}_{j\in \mathcal {D}}$ such that either all signatures are real (as demonstrated by $\{\pi _{j}\}_{j\in \mathcal {D}}$), or all signatures are fake (as could be demonstrated by the proofs produced by $\mathsf {PSDVS}{.}\mathsf {PubSigSim}$ or $\mathsf {PSDVS}{.}\mathsf {VerSigSim}$).

  • 3. $\sigma = (\{\sigma _{j}\}_{j\in \mathcal {D}}, \pi )$.

  Output $\sigma$ as the signature.

• $\mathsf {Verify}({pp},{spk}_{i}, {vsk}_{j}, m, \sigma = (\{\sigma _{j}\}_{j\in \mathcal {D}}, \pi ))$:

  • 1. Let $d_{\pi } \leftarrow \mathsf {NIZK\text {-}PoK}{.}\mathsf {Verify}({crs}, u=(\mathsf {PSDVS}{.}{pp}, {spk}_{i},\{{vpk}_{j}\}_{j\in \mathcal {D}}, \{\sigma _{j}\}_{j\in \mathcal {D}}), \pi )$.

  • 2. Let $d\leftarrow \mathsf {PSDVS}{.}\mathsf {Verify}(\mathsf {PSDVS}{.}{pp}, {spk}_{i}, {vsk}_{j}, m, \sigma _{j}) \wedge d_{\pi }$.

  Output $d$ as the verification decision.

• $\mathsf {Sim}({pp}, {spk}_{i}, \{{vpk}_{j}\}_{j\in \mathcal {D}}, \{{vsk}_{j}\}_{j\in \mathcal {C}}, m)$:

  • 1. For $j\in \mathcal {D}\cap \mathcal {C}$: $(\sigma _{j}, \pi _{j}) \leftarrow \mathsf {VerSigSim}(\mathsf {PSDVS}{.}{pp}, {spk}_{i}, {vpk}_{j}, {vsk}_{j}, m)$.

  • 2. For $j\in \mathcal {D}\backslash \mathcal {C}$: $(\sigma _{j}, \pi _{j}) \leftarrow \mathsf {PubSigSim}(\mathsf {PSDVS}{.}{pp}, {spk}_{i}, {vpk}_{j}, m)$.

  • 3. Use these signatures and proofs to produce the NIZK $\pi$ for consistency.

  • 4. $\sigma = (\{\sigma _{j}\}_{j\in \mathcal {D}}, \pi )$.

  Output $\sigma$ as the signature.

Theorem 2

Assume $\mathsf {PSDVS}$ is a secure provably simulatable designated verifier signature scheme and $\mathsf {NIZK\text {-}PoK}$ is a secure non-interactive zero knowledge proof of knowledge system. Then Construction 1 is a correct and secure MDVS scheme (without privacy of identities (Definition 5)).

Due to space limitations, the proof of Theorem 2 is deferred to the full version.

3.3 Standard Primitive-Based PSDVS Construction

We can build a PSDVS from a special message authentication code (MAC) which looks uniformly random without knowledge of the secret MAC key—such a MAC can be built from any pseudorandom function. A signature on a message $m$ will be a MAC on $(m, t)$, where $t$ is some random tag. Proving that the signature is real simply involves proving knowledge of a MAC key that is consistent with the MAC and some global public commitment to the MAC key. A public proof that the signature is simulated and does not verify would involve proving that the MAC was pseudorandomly generated. A verifier’s proof that the signature is simulated would involve proving that the tag was generated in a way that only the verifier could use (e.g. from a PRF to which only the verifier knows the key).

Of course, this is not ideal, since MACs require knowledge of a shared key; in order to use MACs, we would need to set up shared keys between every possible pair of signer and verifier. However, we can get around this using non-interactive key exchange (NIKE). Each signer and verifier publishes a public key, and any pair of them can agree on a shared secret key by simply using their own secret key and the other’s public key. The construction is as follows:

Construction 2

Let:

• $\mathsf {COMM}= (\mathsf {Setup}, \mathsf {Commit}, \mathsf {Open})$ be a commitment scheme,

• $\mathsf {PRF}= (\mathsf {KeyGen}, \mathsf {Compute})$ be a length-preserving pseudorandom function,

• $\mathsf {PRG}$ be a length-doubling pseudorandom generator,

• $\mathsf {NIZK}= (\mathsf {Setup}, \mathsf {Prove}, \mathsf {Verify})$ be a non-interactive zero knowledge proof system, and

• $\mathsf {NIKE}= (\mathsf {KeyGen}, \mathsf {KeyExtract}, \mathsf {KeyMatch})$ be a non-interactive key exchange protocol. $\mathsf {KeyMatch}$ is an additional algorithm that checks if a public key and a secret key match. $\mathsf {KeyMatch}$ is not typically defined as a part of a $\mathsf {NIKE}$ scheme; however, such an algorithm always exists.

• $\mathsf {Setup}(1^{\kappa })$:

  • 1. ${crs}_i \leftarrow \mathsf {NIZK}{.}\mathsf {Setup}(1^{\kappa }, \mathcal {R}_i), i=1,2,3$.

  • 2. ${ck}\leftarrow \mathsf {COMM}{.}\mathsf {Setup}(1^{\kappa })$.

  Output $(\{{crs}_1, {crs}_2, {crs}_3\}, {ck})$ as the public parameters ${pp}$.

• $\mathsf {SignKeyGen}({pp})$:

  • 1. $(\mathsf {NIKE}{.}{pk}_{\mathsf {S}}, \mathsf {NIKE}{.}{sk}_{\mathsf {S}}) \leftarrow \mathsf {NIKE}{.}\mathsf {KeyGen}(1^{\kappa })$.

  • 2. ${ssk}= \mathsf {NIKE}{.}{sk}_{\mathsf {S}}$.

  • 3. ${spk}= \mathsf {NIKE}{.}{pk}_{\mathsf {S}}$.

  Output ${ssk}$ as the signer’s secret key and ${spk}$ as the signer’s public key.

• $\mathsf {VerKeyGen}({pp})$:

  • 1. $(\mathsf {NIKE}{.}{pk}_{\mathsf {R}}, \mathsf {NIKE}{.}{sk}_{\mathsf {R}}) \leftarrow \mathsf {NIKE}{.}\mathsf {KeyGen}(1^{\kappa })$.

  • 2. $k_{\mathsf {R}} \leftarrow \mathsf {PRF}{.}\mathsf {KeyGen}(1^{\kappa })$. (Informally, this key will be used by the verifier to simulate signatures using $\mathsf {VerSigSim}$.)

  • 3. Choose randomness (i.e. decommitment value) $r_{\mathsf {R}}$ at random.

  • 4. $c_{\mathsf {R}} = \mathsf {COMM}{.}\mathsf {Commit}({ck}, k_{\mathsf {R}}; r_{\mathsf {R}})$. (Informally, this commitment will be used by the verifier to support its proofs of fake-ness.)

  • 5. ${vsk}= (\mathsf {NIKE}{.}{sk}_{\mathsf {R}}, k_{\mathsf {R}}, r_{\mathsf {R}})$.

  • 6. ${vpk}= (\mathsf {NIKE}{.}{pk}_{\mathsf {R}}, c_{\mathsf {R}})$.

  Output ${vsk}$ as the verifier’s secret key and ${vpk}$ as the verifier’s public key.

• $\mathsf {Sign}({pp}, {ssk}= \mathsf {NIKE}{.}{sk}_{\mathsf {S}}, {vpk}= (\mathsf {NIKE}{.}{pk}_{\mathsf {R}}, c_{\mathsf {R}}), m)$:

  The signer computes a shared key with the designated verifier and proceeds to sign the message $m$:

  • 1. $k_{shared} = \mathsf {NIKE}{.}\mathsf {KeyExtract}(\mathsf {NIKE}{.}{sk}_{\mathsf {S}}, \mathsf {NIKE}{.}{pk}_{\mathsf {R}})$. (Informally, this key will be used as a MAC key.)

  • 2. Choose $t$ at random.

  • 3. $\sigma = (\sigma _1, \sigma _2) \leftarrow (t, \mathsf {PRF}_{k_{shared}}((m, t)))$.

  • 4. $\pi \leftarrow \mathsf {NIZK}{.}\mathsf {Prove}({crs}_1, u, w )$ where $u=( (\sigma _1, \sigma _2), \mathsf {NIKE}{.}{pk}_{\mathsf {S}}, \mathsf {NIKE}{.}{pk}_{\mathsf {R}}, m)$ and $w = (\mathsf {NIKE}{.}{sk}_{\mathsf {S}}, k_{shared}))$

    We define the relation $\mathcal {R}_1$ indexed by $\mathsf {NIKE}$ public parameters and $\mathsf {PRF}$ for a statement u and witness w:

    $$\begin{aligned} \mathcal {R}_{1} = \{&( u=(\sigma _1, \sigma _2, \mathsf {NIKE}{.}{pk}_{\mathsf {S}}, \mathsf {NIKE}{.}{pk}_{\mathsf {R}}, m), w=(\mathsf {NIKE}{.}{sk}_{\mathsf {S}}, k_{shared})) : \\&\mathsf {KeyMatch}(\mathsf {NIKE}{.}{pk}_{\mathsf {S}}, \mathsf {NIKE}{.}{sk}_{\mathsf {S}})=1\\&\wedge ~ k_{shared} = \mathsf {NIKE}{.}\mathsf {KeyExtract}(\mathsf {NIKE}{.}{sk}_{\mathsf {S}}, \mathsf {NIKE}{.}{pk}_{\mathsf {R}})\\&\wedge ~ \sigma _2 = \mathsf {PRF}_{k_{shared}}((m, \sigma _1)) \} \end{aligned}$$

  Output $\sigma$ as the signature, and $\pi$ as the proof of real-ness.

• $\mathsf {Verify}({pp}, {spk}= \mathsf {NIKE}{.}{pk}_{\mathsf {S}}, {vsk}= (\mathsf {NIKE}{.}{sk}_{\mathsf {R}}, k_{\mathsf {R}}, r_{\mathsf {R}}), m, \sigma = (\sigma _{1}, \sigma _{2}))$:

  • 1. $k_{shared} = \mathsf {NIKE}{.}\mathsf {KeyExtract}(\mathsf {NIKE}{.}{sk}_{\mathsf {R}}, \mathsf {NIKE}{.}{pk}_{\mathsf {S}})$. (Informally, this key will be used as a MAC key.)

  • 2. If $\mathsf {PRF}_{k_{shared}}((m, \sigma _{1})) = \sigma _{2}$, set $d= 1$. Otherwise, set $d= 0$.

  Output $d$ as the verification decision.

• $\mathsf {RealSigVal}({pp}, {spk}, {vpk}, m, \sigma , \pi )$:

  Output $d\leftarrow \mathsf {NIZK}{.}\mathsf {Verify}({crs}_1,\sigma , \pi )$ as the validation decision.

• $\mathsf {PubSigSim}({pp}, m)$:

  • 1. Choose a $\mathsf {PRG}$ seed $\mathsf {seed}$.

  • 2. Choose $\sigma _{1}$ and $\sigma _{2}$ pseudorandomly by running $\mathsf {PRG}$ on $\mathsf {seed}$.

  • 3. $\sigma \leftarrow (\sigma _{1}, \sigma _{2})$.

  • 4. Let $\pi \leftarrow \mathsf {NIZK}{.}\mathsf {Prove}({crs}_2, u=\sigma ,w=\mathsf {seed})$.

    We define the relation $\tilde{\mathcal {R}}_2$ indexed by the $\mathsf {PRG}$ for a statement $u=(\sigma =(\sigma _{1}, \sigma _{2}))$ and the witnesses $w = \mathsf {seed}$:

    $$\begin{aligned} \tilde{\mathcal {R}}_2 = \{ (u=\sigma ; w=\mathsf {seed}) : u= \mathsf {PRG}(w) \} \end{aligned}$$

    (1)

  Output $\sigma$ as the simulated signature, and $\pi$ as the proof of fake-ness.

• $\mathsf {PubSigVal}({pp}, {spk}, {vpk}, m, \sigma =(\sigma _1, \sigma _2), \pi )$:

  Output $d\leftarrow \mathsf {NIZK}{.}\mathsf {Verify}({crs}_2,\sigma , \pi )$ as the validation decision.

• $\mathsf {VerSigSim}({pp}, {spk}= \mathsf {NIKE}{.}{pk}_{\mathsf {S}}, {vpk}= (\mathsf {NIKE}{.}{pk}_{\mathsf {R}}, c_{\mathsf {R}}), {vsk}= (\mathsf {NIKE}{.}{sk}_{\mathsf {R}}, k_{\mathsf {R}}, r_{\mathsf {R}}), m)$:

  The verifier can fake a signature using its $\mathsf {PRF}$ key $k_{\mathsf {R}}$.

  • 1. $k_{shared} = \mathsf {NIKE}{.}\mathsf {KeyExtract}(\mathsf {NIKE}{.}{sk}_{\mathsf {R}}, \mathsf {NIKE}{.}{pk}_{\mathsf {S}})$.

  • 2. Choose $r$ at random.

  • 3. $t\leftarrow \mathsf {PRF}_{k_{\mathsf {R}}}(r)$.

  • 4. $\sigma \leftarrow (t, \mathsf {PRF}_{k_{shared}}((m, t)))$.

  • 5. Let $\pi \leftarrow \mathsf {NIZK}{.}\mathsf {Prove}({crs}_3, u=(c_{\mathsf {R}}, \sigma _1), w=(k_{\mathsf {R}}, r_{\mathsf {R}}, r))$.

    We define the relation $\tilde{\mathcal {R}}_{3}$ indexed by the $c$ public parameters and $\mathsf {PRF}$ for statements u and witnesses w:

  $$ \tilde{\mathcal {R}}_{3} \text {=} \{ ( u=(c_{\mathsf {R}}, \sigma _1), w=(k_{\mathsf {R}}, r_{\mathsf {R}}, r))\text {:}~ k_{\mathsf {R}} = \mathsf {COMM}{.}\mathsf {Open}( c_{\mathsf {R}},r_{\mathsf {R}} ) \wedge ~ \sigma _1 = \mathsf {PRF}_{k_{\mathsf {R}}}(r)\}$$

  Output $\sigma$ as the simulated signature and $\pi$ as the proof of fake-ness.

• $\mathsf {VerSigVal}({pp}, {spk}, {vpk}, m, \sigma , \pi )$:

  Output $d\leftarrow \mathsf {NIZK}{.}\mathsf {Verify}({crs}_3,(c_{\mathsf {R}},\sigma _1), \pi )$ as the validation decision.

Theorem 3

If the schemes $\mathsf {COMM}, \mathsf {PRF}, \mathsf {PRG}, \mathsf {NIZK}, \mathsf {NIKE}$ are secure, then Construction 2 is a correct and secure PSDVS scheme as per Definition 7.

Due to space limitations, the proof of Theorem 3 is deferred to the full version.

3.4 DDH and Paillier-Based PSDVS Construction

The goal of this section is to construct a PSDVS scheme based on DDH and the security of Paillier encryption. The idea in the PSDVS construction is that the authenticator for a message $m$ will be $\mathsf {H}(m, t)^{k}$ in a group G where $t$ is a nonce, $k$ is a key known to both parties and $\mathsf {H}$ is a hash function modeled as a random oracle. The construction requires that certain properties of the key can be proved in zero-knowledge, and we can do this efficiently using standard $\varSigma$-protocols because the key is in the exponent. However, naive use of this idea would mean that a sender needs to store a key for every verifier he talks to, and the set-up must generate correlated secret keys for the parties. To get around this, we will instead let the sender choose $k$ on the fly and send it to the verifier, encrypted using a new variant of Paillier encryption. In the following subsection we describe and prove this new encryption scheme, and then we specify the actual PSDVS construction. Paillier-style encryption comes in handy since its algebraic properties are useful in making our zero knowledge proofs efficient.

Paillier-Based Authenticated and Verifiable Encryption. An authenticated and verifiable encryption scheme (AVPKE) involves a sender $\mathsf {S}$ and a receiver $\mathsf {R}$. Such a scheme comes with the following polynomial time algorithms:

• $\mathsf {Setup}(1^\kappa ) \rightarrow {pp}$: A probabilistic algorithm for setup which outputs public parameters.

• $\mathsf {KeyGen}_\mathsf {S} ({pp}) \rightarrow ({sk}_\mathsf {S}, {pk}_\mathsf {S})$: A probabilistic sender key generation algorithm.

• $\mathsf {KeyGen}_\mathsf {R} ({pp}) \rightarrow ({sk}_\mathsf {R}, {pk}_\mathsf {R})$: A probabilistic receiver key generation algorithm.

• $\mathsf {Enc}_{{pp}, {sk}_{\mathsf {S}}, {pk}_{\mathsf {R}}}(k) \rightarrow c$: A probabilistic encryption algorithm for message $k$.

• $\mathsf {Dec}_{{pp}, {sk}_\mathsf {R}, {pk}_\mathsf {S}}(c) \rightarrow \{k, \bot \}$: A decryption algorithm that outputs either reject or a message.

We require, of course, that $\mathsf {Dec}_{{pp}, {sk}_\mathsf {R}, {pk}_\mathsf {S}}(\mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k)) =k$ for all messages $k$.

Intuitively, the idea is that given only the receiver public key ${pk}_{\mathsf {R}}$ and his own secret key ${sk}_{\mathsf {S}}$, the sender $\mathsf {S}$ can encrypt a message $k$ in such a way that on receiving the ciphertext, $\mathsf {R}$ can check that $k$ comes from $\mathsf {S}$, no third party knows $k$ and finally, the encryption is verifiable in that it allows $\mathsf {S}$ to efficiently prove in zero-knowledge that $k$ satisfies certain properties.

Our AVPKE scheme adds an authentication mechanism on top of Paillier encryption:

Construction 3

Let:

• $\mathsf {Ggen}$ be a Group Generator, a probabilistic polynomial time algorithm which on input $1^\kappa$ outputs the description of a cyclic group G and a generator g, such that the order of G is a random $\kappa$-bit RSA modulus n, which is the product of so-called safe primes. (That is, $n=pq$ where $p=2p'+1, q= 2q'+1$ and $p', q'$ are also primes.) Finally, we need the algorithm to output an element $\hat{g}\in \mathbb {Z}_n^*$ of order $p'q'$.

• $\mathsf {NIZK}= (\mathsf {Setup}, \mathsf {Prove}, \mathsf {Verify})$ be a simulation-sound non-interactive zero knowledge proof system. In this section, we will use $\varSigma$-protocols made non-interactive using the Fiat-Shamir heuristic, so in this case $\mathsf {Setup}$ is empty and there is no common reference string.

$\mathsf {Ggen}$ can be constructed using standard techniques. For instance, first generate n using standard techniques, then repeatedly choose a small random number r until $P=2rn+1$ is a prime. Let $g'$ be a generator of $\mathbb {Z}_P^*$. Then let G be the subgroup of $\mathbb {Z}_P^*$ generated by $g= g'^{2r} \bmod P$.⁹ Finally, to construct the element $\hat{g}$, let $u\mathsf {\in _R}\ \mathbb {Z}_n$ and set $\hat{g} = u^2 \bmod n$. Indeed, this is a random square, and since the subgroup of squares modulo n has only large prime factors in its order ($p'$ and $q'$), a random element is a generator with overwhelming probability¹⁰.

• $\mathsf {Setup}(1^\kappa )$: Run $\mathsf {Ggen}$ to generate a modulus n and $\hat{g}\in \mathbb {Z}_n^*$ as explained above. Output ${pp}= (n, \hat{g})$.

• $\mathsf {KeyGen}_\mathsf {S} ({pp})$: Pick ${sk}_\mathsf {S} \mathsf {\in _R}\ \mathbb {Z}_n$, and set ${pk}_\mathsf {S} = \hat{g}^{{sk}_\mathsf {S}}$. Output $({sk}_{\mathsf {S}}, {pk}_{\mathsf {S}})$.

• $\mathsf {KeyGen}_\mathsf {R} ({pp})$: Pick $\alpha _1, \alpha _2 \mathsf {\in _R}\ \mathbb {Z}_n$, set ${sk}_\mathsf {R} =(\alpha _1, \alpha _2)$, and set ${pk}_\mathsf {R} = (\beta _1, \beta _2) = (\hat{g}^{\alpha _1}, \hat{g}^{\alpha _2})$.

The public key values are statistically indistinguishable from random elements in the group generated by $\hat{g}$ since n is a sufficiently good “approximation” to the order $p'q'$ of $\hat{g}$.

• $\mathsf {Enc}_{{pp}, {sk}_{\mathsf {S}}, {pk}_{\mathsf {R}}}(k; r, b_1, b_2)$:

  • 1. The randomness should have been picked as follows: $r \mathsf {\in _R}\ \mathbb {Z}_n$ and $b_1,b_2 \mathsf {\in _R}\ \{0,1\}$.

  • 2. Set $c_1 = (-1)^{b_1} \hat{g}^r\bmod n$.

  • 3. Set $c_2 = (n+1)^k((-1)^{b_2}\beta _1^{sk_\mathsf {S}} \beta _2^r\bmod n)^n \bmod n^2$.

  • 4. Let $\pi _{valid}$ be a non-interactive zero-knowledge proof of knowledge wherein given public data $(n, \hat{g}, (c_1, c_2))$, the prover shows knowledge of a witness $w = (k, r, b_1, v)$ such that $c_1= (-1)^{b_1} \hat{g}^r$ and $c_2= (n+1)^kv^n\bmod n^2$. An honest prover can use $v= (-1)^{b_2}\beta _1^{sk_\mathsf {S}} \beta _2^r\bmod n$. The factor $(-1)^{b_1}$ is only in the ciphertext for technical reasons: it allows $\pi _{valid}$ to be efficient.

  Output $c= (c_1, c_2, \pi _{valid})$.

• $\mathsf {Dec}_{{pp}, {sk}_\mathsf {R} = (\alpha _1, \alpha _2), {pk}_\mathsf {S}}(c= (c_1, c_2, \pi _{valid}))$:

  • 1. Check that $c_1, c_2$ have Jacobi symbol 1 modulo n, and check $\pi _{valid}$. Output reject if either check fails.

  • 2. Let $u = {pk}_\mathsf {S} ^{\alpha _1} c_1^{\alpha _2}\bmod n$ and check that $(c_2 u^{-n})^n \bmod n^2 = \pm 1$. $\mathbb {Z}_{n^2}^*$ contains a unique subgroup of order n, generated by $n+1$. So here we are verifying that – up to a sign difference – $c_2 u^{-n} \bmod n^2$ is in the subgroup generated by $n+1$. If the check fails, output reject.

  • 3. Otherwise, compute $k$ such that $(n+1)^k= \pm c_2 u^{-n} \bmod n^2$.¹¹

An AVPKE scheme should allow anyone to make “fake” ciphertexts that look indistinguishable from real encryptions, given only the system parameters. Furthermore, the receiver $\mathsf {R}$ should be able to use his own secret key ${sk}_{\mathsf {R}}$ and the public key ${pk}_{\mathsf {S}}$ of the sender to make ciphertexts with exactly the same distribution as real ones. This is indeed true for our scheme:

• Fake Encryption: Let $r\mathsf {\in _R}\ \mathbb {Z}_n, b, b'\mathsf {\in _R}\ \{0, 1\}$ and $v\in \mathbb {Z}_n^*$ be a random square.

Then, $\mathsf {Enc}_{{pp}, \textit{fake}}(k; r, b, b', v) = ((-1)^b \hat{g}^r \bmod n, (n+1)^k ((-1)^{b'}v)^n \bmod n^2), \pi _{valid}$ where $\pi _{valid}$ is constructed following the NIZK prover algorithm.

$\mathsf {R}$’s Equivalent Encryption: $\mathsf {Enc}_{{pp}, {sk}_\mathsf {R}, {pk}_\mathsf {S}}(k; r, b_1, b_2) = ((-1)^{b_1} \hat{g}^r\bmod n, (n+1)^k(-1)^{b_2} ({pk}_\mathsf {S} ^{\alpha _1} \hat{g}^{ r \alpha _2} \bmod n)^n \bmod n^2),\ \pi _{valid}$

where $r\mathsf {\in _R}\ \mathbb {Z}_n$, $b_1,b_2 \mathsf {\in _R}\ \{0,1\}$ and $\pi _{valid}$ is constructed following the NIZK prover algorithm.

In the following, we will sometimes suppress the randomness from the notation and just write, e.g., $\mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k)$.

By simple inspection of the scheme it can be seen that:

Lemma 1

For all $k$, $\mathsf {Dec}_{{pp}, {sk}_\mathsf {R}, {pk}_\mathsf {S}}(\mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k)) = k$. Furthermore, encryption by $\mathsf {S}$ and by $\mathsf {R}$ returns the same ciphertexts: for all messages $k$ and randomness $r, b_1, b_2$, we have $\mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k; r, b_1, b_2) = \mathsf {Enc}_{{pp}, {sk}_\mathsf {R}, {pk}_\mathsf {S}}(k; r, b_1, b_2)$.

Lemma 2

If DDH in $\langle \hat{g}\rangle$ is hard, then $(k, \mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k; r, b_1, b_2))$ is computationally indistinguishable from $(k, \mathsf {Enc}_{{pp}, \textit{fake}}(k; r', b, b', v))$ for any fixed message $k$ and randomness $r, b_1, b_2, r', b, b', v$, as long as the discrete log of $\beta _2$ to the base $\hat{g}$ is unknown.

Definition 16

Consider the following experiment for an AVPKE scheme and a probabilistic polynomial time adversary $\mathcal {A}$: Run the set-up and key generation and run $A^{\mathcal {O}_{E}, \mathcal {O}_{D}}({pp}, pk_\mathsf {R}, pk_\mathsf {S})$. Here, $\mathcal {O}_{E}$ takes a message $k$ as input and returns $\mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k)$, while $\mathcal {O}_{D}$ takes a ciphertext and returns the result of decrypting it under ${pk}_\mathsf {S}, {sk}_\mathsf {R}$ (which will be either reject or a message). $\mathcal {A}$ wins if it makes $\mathcal {O}_{D}$ accept a ciphertext that was not obtained from $\mathcal {O}_{E}$. The scheme is authentic if any PPT $\mathcal {A}$ wins with negligible probability.

Lemma 3

If the DDH problem in $\langle \hat{g} \rangle$ is hard, the AVPKE scheme defined above is authentic.

Due to space limitations, the proof of Lemma 3 is deferred to the full version.

We proceed to show that the AVPKE scheme hides the message encrypted even if adversary knows the secret key of the sender, and even if a decryption oracle is given. This is essentially standard CCA security.

Definition 17

Consider the following experiment for an AVPKE scheme and a probabilistic polynomial time adversary $\mathcal {A}$: Run the set-up and key generation and run $\mathcal {A}^{\mathcal {O}_{E}}({pp}, {pk}_\mathsf {R}, {sk}_\mathsf {S})$. Here, $\mathcal {O}_{E}$ takes two messages $k_0, k_1$ as input, selects a bit $\eta$ at random and returns $c^*= \mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k_\eta )$. $\mathcal {O}_{D}$ takes a ciphertext and returns the result of decrypting it under ${pk}_\mathsf {S}, {sk}_\mathsf {R}$ (which will be either reject or a message). $\mathcal {A}$ may submit anything other than $c^*$ to $\mathcal {O}_{D}$, and must output a bit $\eta '$ at the end. It wins if $\eta '=\eta$. The scheme is private if any PPT $\mathcal {A}$ wins with negligible advantage over $\frac{1}{2}$.

In the following we will use the assumption underlying the Paillier encryption scheme, sometimes known as the composite degree residuosity assumption (CDRA): a random element x in $\mathbb {Z}_{n^2}^*$ where $x \bmod n$ has Jacobi symbol 1 is computationally indistinguishable from $y^n \bmod n^2$ where $y\in \mathbb {Z}_n^*$ is random of Jacobi symbol 1¹².)

Lemma 4

Assume that DDH in $\langle \hat{g}\rangle$ is hard and that CDRA holds. Then the AVPKE scheme satisfies Definition 17.

Due to space limitations, the proof of Lemma 4 is deferred to the full version.

We say that an AVPKE scheme is secure if it is authentic, private, supports equivalent encryption by $\mathsf {R}$ and indistinguishable fake encryption.

Construction 4

(PSDVS Scheme). Let:

• $\mathsf {Ggen}$ be a Group Generator, a probabilistic polynomial time algorithm which on input $1^\kappa$ outputs $G, g, n, \hat{g}$ exactly as in the previous AVPKE construction.

• $\mathsf {H}$ be a hash function which we model as a random oracle. We assume it maps onto the group G.

• $\mathsf {NIZK}= (\mathsf {Setup}, \mathsf {Prove}, \mathsf {Verify})$ be a simulation-sound non-interactive zero knowledge proof system. In this section, we will use $\varSigma$-protocols made non-interactive using the Fiat-Shamir heuristic, so in this case $\mathsf {Setup}$ is empty and there is no common reference string.

• $\mathsf {Setup}(1^{\kappa })$: Let $(G,g,\hat{g}, n) \leftarrow \mathsf {Ggen}(1^{\kappa })$ and let $h\mathsf {\in _R}\ G$. Set ${pp}= (G,g,\hat{g}, n,h)$. Return ${pp}$ as the public parameters.

• $\mathsf {SignKeyGen}({pp})$: Run key generation for the AVPKE scheme as defined above to get keys ${ssk}= {sk}_{\mathsf {S}}, {spk}= {pk}_{\mathsf {S}}$ for the signer $\mathsf {S}$. Output ${ssk}$ as the signer’s secret key and ${spk}$ as the signer’s public key.

• $\mathsf {VerKeyGen}({pp})$:

  • 1. Run key generation for the AVPKE scheme as defined above to get keys ${sk}_{\mathsf {R}}, {pk}_{\mathsf {R}}$ for the verifier $\mathsf {R}$. (These keys will be used to sign messages and verify signatures.)

  • 2. Choose $k_{\mathsf {R}} \mathsf {\in _R}\ \mathbb {Z}_n$. (This key will be used by the verifier to simulate signatures using $\mathsf {VerSigSim}$.)

  • 3. Choose $r_\mathsf {R} \mathsf {\in _R}\ \mathbb {Z}_n$ and let $c_{\mathsf {R}} = g^{k_\mathsf {R}}h^{r_\mathsf {R}}$. (This commitment will be used by the verifier to support its proofs of fake-ness.)

  • 4. ${vsk}= ({sk}_{\mathsf {R}}, k_{\mathsf {R}}, r_\mathsf {R})$, ${vpk}= ({pk}_{\mathsf {R}}, c_{\mathsf {R}})$.

  Output ${vsk}$ as the verifier’s secret key and ${vpk}$ as the verifier’s public key.

• $\mathsf {Sign}({pp}, {ssk}= {sk}_\mathsf {S}, {pk}_\mathsf {R}, m)$:

  • 1. Choose $t\mathsf {\in _R}\ G, r\mathsf {\in _R}\ \mathbb {Z}_n, b_1, b_2\mathsf {\in _R}\ \{0, 1\}, s\mathsf {\in _R}\ \mathbb {Z}_n^*, k_s \mathsf {\in _R}\ \mathbb {Z}_n$.

  • 2. Let $\sigma \leftarrow ( t, \mathsf {H}(m, t)^{k_s}, \mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k_s; r, b_1, b_2))$.

  • 3. $\pi \leftarrow \mathsf {NIZK}{.}\mathsf {Prove}(u=(\sigma = (\sigma _1, \sigma _2, \sigma _3), pk_V, pk_S, m), w=(sk_S, k_{s}, r, b_1, b_2))$ be a zero knowledge proof of knowledge of witness w such that:

    $$\sigma _2 = \mathsf {H}(m, \sigma _1 )^{k_s} \wedge \sigma _3= \mathsf {Enc}_{{pp}, {sk}_\mathsf {S}, {pk}_\mathsf {R}}(k_s; r , b_1, b_2) $$

  Output $\sigma$ as the signature, and $\pi$ as the proof of real-ness.

• $\mathsf {Verify}({pp}, {spk}= {pk}_\mathsf {S}, {vsk}= ({sk}_\mathsf {R}, k_\mathsf {R}, r_\mathsf {R}), m, \sigma = (\sigma _{1}, \sigma _{2}, \sigma _3))$:

  • 1. Decrypt $\sigma _3$ as $k_s = \mathsf {Dec}_{{pp}, {sk}_\mathsf {R}, {pk}_\mathsf {S}}(\sigma _3)$. If this fails, set $d=0$ and abort.

  • 2. If $\sigma _2 = \mathsf {H}(m, \sigma _1 )^{k_s}$ , set $d= 1$. Otherwise, set $d= 0$.

  Output $d$ as the verification decision.

• $\mathsf {PubSigSim}({pp}, m)$:

  • 1. Choose $k, k' \mathsf {\in _R}\ \mathbb {Z}_n$, such that $k\ne k'$.

  • 2. Choose $t\mathsf {\in _R}\ G$, $r\mathsf {\in _R}\ \mathbb {Z}_n, b, b' \mathsf {\in _R}\ \{0,1\}$, $v\mathsf {\in _R}\ \mathbb {Z}_n$, such that v has Jacobi symbol 1.

  • 3. $\sigma \leftarrow (t, \mathsf {H}(m, t)^{k}, \mathsf {Enc}_{{pp}, \textit{fake}}(k'; r, b, b', v))$.

  • 4. Let $\pi \leftarrow \mathsf {NIZK}{.}\mathsf {Prove}(u=\sigma = (\sigma _1, \sigma _2, \sigma _3),w= (k, k'))$ be a zero-knowledge proof of knowledge such that:

    $$ \sigma _2 = \mathsf {H}(m, \sigma _1)^k\wedge \sigma _3 = \mathsf {Enc}_{{pp}, \textit{fake}}(k'; \cdot , \cdot , \cdot , \cdot ) \wedge k\ne k'. $$

  Output $\sigma$ as the simulated signature, and $\pi$ as the proof of fake-ness. The notation $\mathsf {Enc}_{{pp}, \textit{fake}}(k'; \cdot , \cdot , \cdot , \cdot )$ means that the proof only has to establish that the plaintext inside the encryption is some value $k'$ different from $k$.

• $\mathsf {VerSigSim}({pp}, {spk}= {pk}_\mathsf {S}, {vpk}= ({pk}_\mathsf {R}, c_{\mathsf {R}}), {vsk}= ({sk}_{\mathsf {R}}, k_{\mathsf {R}}, r_\mathsf {R}), m)$:

  • 1. Choose $r_{t} \mathsf {\in _R}\ \mathbb {Z}_n$, $t= g^{k_\mathsf {R}}h^{r_{t}}$, $k_s \mathsf {\in _R}\ \mathbb {Z}_n$, $b_1, b_2\mathsf {\in _R}\ \{0, 1\}$ and $v\mathsf {\in _R}\ \mathbb {Z}_n^*$ of Jacobi symbol 1.

  • 2. $\sigma \leftarrow (t, \mathsf {H}(m, t)^{k_s}, \mathsf {Enc}_{{pp}, {sk}_\mathsf {R}, {pk}_\mathsf {S}}(k_s; r, b_1, b_2))$.

  • 3. Let $\pi \leftarrow \mathsf {NIZK}{.}\mathsf {Prove}(u=((\sigma _1, \sigma _2, \sigma _3), c_{\mathsf {R}}, m), w=(k_{\mathsf {R}}, r_\mathsf {R}, r_{t}) )$ be a zero-knowledge proof of knowledge of witness $w=(k_{\mathsf {R}}, r_\mathsf {R}, r_{t})$ such that:

    $$ \sigma _1 = g^{k_\mathsf {R}}h^{r_{t}} \wedge c_{\mathsf {R}} = g^{k_\mathsf {R}}h^{r_\mathsf {R}}. $$

  Output $\sigma$ as the simulated signature and $\pi$ as the proof of fake-ness.

Theorem 4

If the AVPKE scheme is secure, and under the DDH assumption, Construction 4 is a secure PSDVS scheme.

Due to space limitations, the proof of Theorem 4 is deferred to the full version.

In the full version we describe a PSDVS scheme based on prime order groups. It gets around the need to generate a Paillier modulus securely, at the cost of requiring double discrete log proofs.

4 FE-Based Construction

In this section, we present an MDVS scheme based on functional encryption. One disadvantage of this scheme is that it requires a trusted setup; secret verification keys must be derived from a master secret key. However, the accompanying advantage is that this scheme has verifier-identity-based signing; verifiers’ public keys consist simply of their identity, allowing any signer to encrypt to any set of verifiers without needing to retrieve their keys from some PKI first.

At a high level, we are first given a digital signature scheme (DS) and a functional encryption scheme (FE). The keys of the signer with identity ${i}$ are a secret DS signing key ${sk}_{i}$ and corresponding public DS verification key ${vk}_{i}$. An MDVS signature $c$ is a FE ciphertext obtained by encrypting the plaintext that consists of the message $m$, the signer’s DS verification key ${vk}_{i}$, a set of designated verifier identities $\mathcal {D}$, and the signer’s DS signature $\sigma$ on the message using the secret DS signing key ${sk}_{i}$. That is, $c= \mathsf {FE}{.}\mathsf {Enc}({pp},(m,{vk}_{i}, \mathcal {D}, \sigma ))$. Verifier $j$’s public key is simply their identity $j$ (that is, ${vpk}_j=j$). Their secret key consists of a DS key pair $({sk}_{j},{vk}_{j})$, and an FE secret key ${dk}_{j}$. ${dk}_j$ is the secret key for a function that checks whether $j$ is among the specified designated verifiers, and then checks whether the DS signature $\sigma$ inside the ciphertext $c$ is either a valid signature under the signer’s verification key ${vk}_{i}$, or under the verifier’s verification key ${vk}_{j}$. However, this basic scheme does not give us the off-the-record property; we therefore tweak it slightly, as we describe below.

From One to Many DS Signatures. In order to ensure that any subset of valid verifiers cannot convince an outsider of the origin of the MDVS signature, we need to replace the one DS signature in the ciphertext with a set of DS signatures. The reason is that, if only one signature is contained in the ciphertext, any designated verifier can prove to an outsider that “it was either me or the signer that constructed the signature”. If more than one verifier proves this about the same MDVS signature, then the signature must have come from the signer.

To prevent this kind of “intersection attack”, we allow the ciphertext to contain a set $\varSigma$ of DS signatures, and change the corresponding FE secret keys to check if there exists a DS signature in the set that either verifies under the signer’s or the verifier’s DS verification key. Now, an outsider will no longer be convinced that it was the signer who constructed the MDVS signature, since each of the colluding verifiers could have constructed a DS signature that verifies under their own verification key, and then encrypted this set together with the public verification key of the signer.

Achieving Consistency. In order to achieve consistency, we need security against malicious encryption in the underlying FE scheme. We need to ensure that any (possibly maliciously generated) ciphertext is consistent with one specific message across decryption with different functions. Otherwise, a malicious MDVS signer may be able to construct a ciphertext (i.e. a signature) that will be valid for one designated verifier but not valid for another, thereby breaking the consistency property. Security against a malicious encryption is a property of verifiable functional encryption (VFE), which was introduced by Badrinarayanan et al. [BGJS16]. However, it turns out that we do not need the full power of VFE, which also includes precautions against a malicious setup. Thus, we define a weaker notion of VFE, and substitute the standard FE scheme with this new scheme allowing us to achieve the MDVS consistency property.

4.1 Ciphertext Verifiable Functional Encryption

The formal definition of Functional Encryption and Ciphertext Verifiable FE and the security notions can be found in the full version. Informally, the ciphertext verifiability property states that for all ciphertexts $c$, it must hold that if $c$ passes the verification algorithm, then there exists a unique plaintext x asociated with $c$, meaning that for all functions $f\in \mathcal {F}$ the decryption of $c$ will yield f(x).

4.2 The MDVS Construction

Construction 5

Let $\mathsf {SIGN}= (\mathsf {KeyGen}, \mathsf {Sign}, \mathsf {Verify})$ be a standard digital signature scheme and let $\mathsf {VFE}= (\mathsf {Setup},\mathsf {KeyGen},\mathsf {Enc},\mathsf {Dec},\mathsf {Verify})$ be a functional encryption scheme secure with ciphertext verifiability. Then we define a MDVS scheme $\mathsf {FEMDVS}= (\mathsf {Setup}, \mathsf {KeyGen}, \mathsf {Sign}, \mathsf {Verify}, \mathsf {Sim})$ as follows:

• $\mathsf {Setup}(1^{\kappa })$: $(pp^\mathsf {FE}, msk^\mathsf {FE}) \leftarrow \mathsf {VFE}{.}\mathsf {Setup}(1^\kappa )$.

  Output public parameter $pp = pp^\mathsf {FE}$ and master secret key $msk = msk^\mathsf {FE}$.

• $\mathsf {SignKeyGen}(i)$: $({sk}_i,{vk}_i) \leftarrow \mathsf {SIGN}{.}\mathsf {KeyGen}(1^\kappa )$.

  Output the signer’s secret key ${ssk}_i = {sk}_i$ and public key ${spk}_i = {vk}_i$.¹³

• $\mathsf {VerKeyGen}({msk}, j)$:

  • 1. ${vpk}_j = j$,

  • 2. $({sk}_j,{vk}_j) \leftarrow \mathsf {SIGN}{.}\mathsf {KeyGen}(1^\kappa )$,

  • 3. ${dk}_j \leftarrow \mathsf {VFE}{.}\mathsf {KeyGen}(msk^\mathsf {FE},f_j)$, where $f_j$ is defined as follows.

• Output the verifiers secret key ${vsk}_j = ({sk}_j,{dk}_j)$ and public key ${vpk}_j = j$.¹⁴

• $\mathsf {Sign}({pp}, {ssk}_{i}, \{{vpk}_{j}\}_{j\in \mathcal {D}}, m)$:

  • 1. $\sigma \leftarrow \mathsf {SIGN}{.}\mathsf {Sign}({sk}_i,m)$.

  • 2. Output $c= \mathsf {VFE}{.}\mathsf {Enc}(pp^\mathsf {FE}, (m, {vk}_i, \{{vpk}_{j}\}_{j\in \mathcal {D}}, \{\sigma , \bot ,\cdots ,\bot \}))$.

• $\mathsf {Verify}({pp},{spk}_{i}, {vsk}_{j}, \{{vpk}_{j}\}_{j\in \mathcal {D}}, m, c)$:

  • 1. Check whether $\mathsf {VFE}{.}\mathsf {Verify}(pp^\mathsf {FE},c) = 1$. If not, output 0.

  • 2. Compute $(m',{vk}'_i,\{{vpk}_{j}\}_{j\in \mathcal {D}'}) \backslash \bot \leftarrow \mathsf {VFE}{.}\mathsf {Dec}({dk}_j,c)$. If the output is $\bot$, output 0.

  • 3. Check $m' = m$, ${vk}'_i = {vk}_i$ (with ${spk}_i = {vk}_i$), and $\mathcal {D}' = \mathcal {D}$. If all hold, output 1. Otherwise output 0.

• $\mathsf {Sim}({pp}, {spk}_{i}, \{{vpk}_{j}\}_{j\in \mathcal {D}}, \{{vsk}_{j}\}_{j\in \mathcal {C}}, m)$:

  • 1. For each $j\in \mathcal {C}$, ${vsk}_{j} = ({sk}_{j},{dk}_{j})$.

  • 2. Compute $\sigma _{j} \leftarrow \mathsf {SIGN}{.}\mathsf {Sign}({sk}_{j},m^*)$.

  • 3. Let $\varSigma = \{ \sigma _{j} \}_{{j}\in \mathcal {C}^*}$, add default values to get the required size.

  • 4. Output $c= \mathsf {VFE}{.}\mathsf {Enc}(pp^\mathsf {FE}, (m^*, {spk}_{i}, \{{vpk}_{j}\}_{j\in \mathcal {D}}, \varSigma ))$.

Theorem 5

Assume that $\mathsf {VFE}$ is an IND-CPA secure functional encryption scheme with ciphertext verifiability, and $\mathsf {SIGN}$ is an existential unforgeable digital signature scheme. Then Construction 5 is a correct and secure MDVS scheme with privacy of identities and verifier-identity-based signing.

Due to space limitations, the proof of Theorem 5 is deferred to the full version.