# Signer-Anonymous Designated-Verifier Redactable Signatures for Cloud-Based Data Sharing

## Abstract

Redactable signature schemes allow to black out predefined parts of a signed message without affecting the validity of the signature, and are therefore an important building block in privacy-enhancing cryptography. However, a second look shows, that for many practical applications, they cannot be used in their vanilla form. On the one hand, already the identity of the signer may often reveal sensitive information to the receiver of a redacted message; on the other hand, if data leaks or is sold, everyone getting hold of (redacted versions of) a signed message will be convinced of its authenticity.

We overcome these issues by providing a definitional framework and practically efficient instantiations of so called *signer-anonymous designated-verifier redactable signatures* (AD-RS). As a byproduct we also obtain the first *group redactable signatures*, which may be of independent interest. AD-RS are motivated by a real world use-case in the field of health care and complement existing health information sharing platforms with additional important privacy features. Moreover, our results are not limited to the proposed application, but can also be directly applied to various other contexts such as notary authorities or e-government services.

## 1 Introduction

Digitalization of data and processes as well as the use of promising IT-trends such as cloud computing is prevalent, steadily increasing and meanwhile outreaches even sensitive fields such as the health care sector.^{1} Given the sensitivity of the involved data and the high demands in data correctness and quality, the health care domain is a prime example for the beneficial application of cryptographic means such as encryption and digital signatures. This work is dedicated to the development of a cryptographically enhanced solution for a real world hospital, which is currently planning to complement its existing information sharing system for electronic patient data with additional privacy features. The overall idea of the system is to grant patients access to all their medical records via a cloud-based platform. The patients are then able to use this as a central hub to distribute their documents to different stakeholders, e.g., to request reimbursement by the insurance, or to forward (parts of) the documents to the family doctor for further treatment. While means for access control and data confidentiality are already in place, the system should be complemented by strong authenticity guarantees. At the same time a high degree of privacy should be maintained, i.e., by allowing the patients, on a fine-granular basis, to decide which parts of which document should be visible to which party. For instance, the family doctor might *not* need to learn the precise costs of a treatment; similarly a medical research laboratory should *not* learn the patients’ identities.

From a research point of view, one motivation behind this work is to show how rather complex real world scenarios with conflicting interests and strong security and privacy requirements can be elegantly and securely realized by means of rigorous cryptographic design and analysis. More importantly, we can indeed come up with provably secure and practical solutions being well suited for real world use. Now, we discuss the motivation for our design.

*Redactable Signatures.* A trivial solution for the above problem would be to let the hospital cloud create a fresh signature on the information to be revealed every time the user wishes to forward authentic subsets of a document to other parties. However, this is not satisfactory as it would require strong trust assumptions into the cloud: one could not efficiently guarantee that the signed data has not been altered over time by the cloud or by a malicious intruder. It is therefore preferable to use *redactable signatures* (RS). These are signature schemes that allow to black out (redact) predefined parts of a signed message while preserving the validity of the signature, thereby guaranteeing the authenticity of the redacted message. That is, it is not necessary to let the cloud attest the authenticity of the forwarded data, as the signature on the redacted document can be extracted from the doctor’s signature on the original document without requiring the doctor’s secret signing key or further interaction with the doctor.

*Designated Verifiers.* Unfortunately, using redactable signatures in their vanilla form in our scenario would lead to severe privacy problems, i.e., everyone getting hold of a signed document would be convinced of its authenticity. In such a case, for instance, an employer who gets hold of a signed health record of an employee, might reliably learn the employee’s disease, who, in further consequence, might get dismissed. What is therefore needed is a *designated verifier* for each redacted version of a document. That is, when redacting a document, the patient should be able to define the intended receiver. Then, while everybody can check the validity of a leaked document, *only* the designated verifier is convinced about its authenticity. This can be achieved by constructing the schemes in a way that the designated verifier can fake indistinguishable signatures on its own. Moreover, the public verifiability property might as well be a motivation for designated verifiers to not leak/sell documents, as this reduces the circle of possible suspects to the data owner and the designated verifier.

*Group Signatures.* Another problem of RS is that they only support a single signer. However, a hospital potentially employing hundreds of doctors will not use a single signing key that is shared by all its employees. By doing so, the identity of the signing doctor could not be revealed in case of a dispute, e.g., after a malpractice. However, using different keys for different doctors poses a privacy risk again. For instance, if the document was signed using an oncologist’s key, one could infer sensitive information about the disease—even though the diagnosis was blacked out. What is therefore needed are features known from *group signatures*, where towards the verifier the doctor’s identity remains hidden within the set of doctors in the hospital, while re-identification is still possible by a dedicated entity.

**Contribution.** The properties we need for our scenario are contributed by three distinct cryptographic concepts and what we actually need can be considered as a *signer-anonymous designated-verifier redactable signature scheme*. However, while a lot of existing work studies the different concepts in isolation, there is no work which aims at combining them in a way to profit from a combination of their individual properties. Trying to obtain this by simply combining them in an ad-hoc fashion, however, is dangerous. It is well known that the ad-hoc combination of cryptographic primitives to larger systems is often problematic (as subtle issues often remain hidden when omitting formal analysis) and security breaches resulting from such approaches are often seen in practice. Unlike following such an ad-hoc approach, we follow a rigorous approach and formally model what is required by the use-case, introduce a comprehensive security model and propose two (semi-)black-box constructions that are provably secure within our model. While such a (semi-)black-box construction is naturally interesting from a theoretical point of view, our second construction is also entirely practical and thus also well suited to be used within the planned system. Finally, as a contribution which may be of independent interest, we also obtain the first *group redactable signatures* as a byproduct of our definitional framework.

*Technical Overview.* Our constructions provably achieve the desired functionality by means of a two-tier signature approach: a message is signed using a freshly generated RS key pair where the corresponding public key of this “one-time RS” is certified using a group signature. For the designated verifier feature, we follow two different approaches. Firstly, we follow the naïve approach and use a disjunctive non-interactive proof of knowledge which either demonstrates knowledge of a valid RS signature on the message, *or* it demonstrates knowledge of a valid signature of the designated verifier on the same message. While this approach is very generic, its efficiency largely depends on the complexity to prove knowledge of an \(\mathsf{RS}\) signature. To this end, we exploit key-homomorphic signatures, which we introduce and which seem to be of independent interest. In particular, we use the observation that a large class of \(\mathsf{RS}\) can easily be turned into RS admitting the required key-homomorphism, to obtain a practical construction. More precisely, besides conventional group signatures and conventional redactable signatures, our approach only requires to prove a single statement demonstrating knowledge of the relation between two RS keys *or* demonstrating knowledge of the designated verifier’s secret key. For instance, in the discrete logarithm setting when instantiating this proof using Fiat-Shamir transformed [15] \(\varSigma \)-protocols, they are highly efficient as they only require two group exponentiations.

**Related Work.** Redactable signature schemes have been independently introduced in [18, 27]. Although such schemes suffer from the aforementioned problems, we can use them as an important building block. In particular, we will rely on the general framework for such signatures as presented in [13]. Besides that, redactable signatures with an unlinkability property have been introduced in [9, 21].^{2} Unfortunately, apart from lacking practical efficiency, even unlinkable redactable signatures are not useful to achieve the desired designated verifier functionality. There is a large body of work on signatures with designated verifiers, which are discussed subsequently. However, none of the approaches considers selective disclosure via redaction or a group signing feature.

In designated verifier (DV) signatures (or proofs) [17], a signature produced by a signer can only be validated by a single user who is designated by the signer during the signing process (cf. [19] for a refined security model). Designation can only be performed by the signer and verification requires the designated verifier’s secret. Thus, this concept is not directly applicable to our setting. In [17] also the by now well known “*OR trick*” was introduced as a DV construction paradigm.

Undeniable signatures [11] are signatures that can not be verified without the signer’s cooperation and the signer can either prove that a signature is valid or invalid. This is not suitable for us as this is an interactive process.

Designated confirmer signatures [10] introduce a third entity besides the signer and the verifier called designated confirmer. This party, given a signature, has the ability to privately verify it as well as to convince anyone of its validity or invalidity. Additionally, the designated confirmer can convert a designated confirmer signature into an ordinary signature that is then publicly verifiable. This is not suitable for our scenario, as it is exactly the opposite of what we require, i.e., here the signature for the confirmer is not publicly verifiable, but the confirmer can always output publicly verifiable versions of this signature.

Another concept, which is closer to the designation functionality that we require, are universal designated verifier (UDV) signatures introduced in [26]. They are similar to designated verifier signatures, but universal in the sense that any party who is given a publicly verifiable signature from the signer can designate the signature to any designated verifier by using the verifiers public key. Then, the designated verifier can verify that the message was signed by the signer, but is unable to convince anyone else of this fact. Like with ordinary DV signatures, UDV signatures also require the designated verifier’s secret key for verification. There are some generic results for UDV signatures. In [29] it was shown how to convert various pairing-based signature schemes into UDV signatures. In [25] it was shown how to convert a large class of signature schemes into UDV signatures. Some ideas in our second construction are conceptually related to this generic approach. However, as we only require to prove relations among public keys, our approach is more tailored to efficiency.

## 2 Preliminaries

We denote algorithms by sans-serif letters, e.g., \(\mathsf {A}, \mathsf {B}\). All algorithms are assumed to return a special symbol \(\bot \) on error. By \(y\leftarrow \mathsf{A}(x)\), we denote that *y* is assigned the output of the potentially probabilistic algorithm \(\mathsf{A}\) on input *x* and fresh random coins. Similarly, Open image in new window means that *y* was sampled uniformly at random from a set *S*. We let \([n]:=\{1,\dots , n\}\). We write \(\Pr [\varOmega : \mathcal {E}]\) to denote the probability of an event \(\mathcal {E}\) over the probability space \(\varOmega \). We use \(\mathcal {C}\) to denote challengers of security experiments, and \(\mathcal {C}_\kappa \) to make the security parameter explicit.

A function \(\varepsilon (\cdot ):\mathbb {N}\rightarrow \mathbb {R}_{\ge 0}\) is called negligible, iff it vanishes faster than every inverse polynomial, i.e., \(\forall ~k:\exists ~n_k:\forall ~n>n_k: \varepsilon (n)<n^{-k}\).

Followingly, we recap required cryptographic building blocks. Due to space constraints we omit formal definitions for well known primitives such as a digital signature scheme \(\mathsf {\Sigma }= (\mathsf{KeyGen}, \mathsf{Sign}, \mathsf{Verify})\) and a (non-interactive) proof system \(\mathsf{\Pi }= (\mathsf{Setup}, \mathsf{Proof},\mathsf{Verify})\) here, and present them in the extended version.

**Redactable Signatures.** Below, we recall the generalized model for redactable signatures from [13], which builds up on [6]. As done in [13], we do not make the structure of the message explicit. That is, we assume that the message \(\mathsf{m}\) to be signed is some arbitrarily structured data. We use \({{{\mathsf{{\textsc {ADM}}}}}}\) to denote a data structure encoding the admissible redactions of some message \(\mathsf{m}\) and we use \({{{\mathsf{{\textsc {MOD}}}}}}\) to denote a data structure containing modification instructions for some message. We use Open image in new window to denote that a message \(\mathring{\mathsf{m}}\) is derivable from a message \(\mathsf{m}\) under \({{{\mathsf{{\textsc {ADM}}}}}}\) and Open image in new window to denote that \(\mathring{\mathsf{m}}\) is obtained by applying \({{{\mathsf{{\textsc {MOD}}}}}}\) to \(\mathsf{m}\). Likewise, we use Open image in new window to denote the derivation of \(\mathring{{{{\mathsf{{\textsc {ADM}}}}}}}\) from \({{{\mathsf{{\textsc {ADM}}}}}}\) with respect to \({{{\mathsf{{\textsc {MOD}}}}}}\). We use \({{{\mathsf{{\textsc {ADM}}}}}}\preceq \mathsf{m}\) to denote that \({{{\mathsf{{\textsc {ADM}}}}}}\) matches \(\mathsf{m}\), and \({{{\mathsf{{\textsc {MOD}}}}}}\preceq {{{\mathsf{{\textsc {ADM}}}}}}\) to denote that \({{{\mathsf{{\textsc {MOD}}}}}}\) matches \({{{\mathsf{{\textsc {ADM}}}}}}\).

### Definition 1

\(\mathsf{KeyGen}(1^\kappa )\): Takes a security parameter \(\kappa \) as input and outputs a keypair \((\mathsf{sk}, \mathsf{pk})\).

\(\mathsf{Sign}(\mathsf{sk}, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}})\): Takes a secret key \(\mathsf{sk}\), a message \(\mathsf{m}\) and admissible modifications \({{{\mathsf{{\textsc {ADM}}}}}}\) as input, and outputs a message-signature pair \((\mathsf{m}, \sigma )\) together with some auxiliary redaction information \({{\mathsf{{\textsc {RED}}}}}\).

^{3}\(\mathsf{Verify}(\mathsf{pk}, \mathsf{m}, \sigma )\): Takes a public key \(\mathsf{pk}\), a message \(\mathsf{m}\), and a signature \(\sigma \) as input, and outputs a bit

*b*.\(\mathsf{Redact}(\mathsf{pk}, \mathsf{m}, \sigma , {{{\mathsf{{\textsc {MOD}}}}}}, {{\mathsf{{\textsc {RED}}}}})\): Takes a public key \(\mathsf{pk}\), a message \(\mathsf{m}\), a valid signature \(\sigma \), modification instructions \({{{\mathsf{{\textsc {MOD}}}}}}\), and auxiliary redaction information \({{\mathsf{{\textsc {RED}}}}}\) as input. It returns a redacted message-signature pair \((\mathring{\mathsf{m}}, \mathring{\sigma })\) and an updated auxiliary redaction information \(\mathring{{{\mathsf{{\textsc {RED}}}}}}\).

While we omit correctness, we recall the remaining RS security definitions below.

### Definition 2 (Unforgeability)

### Definition 3 (Privacy)

Here, the admissible modifications \(\mathring{{{{\mathsf{{\textsc {ADM}}}}}}}_0\) and \(\mathring{{{{\mathsf{{\textsc {ADM}}}}}}}_1\) corresponding to the redacted messages are implicitly defined by (and recoverable from) the tuples \((\mathring{\mathsf{m}}_0, \mathring{\sigma }_0)\) and \((\mathring{\mathsf{m}}_1, \mathring{\sigma }_1)\) and the oracle returns \(\bot \) if any of the algorithms returns \(\bot \).

We call an RS *secure*, if it is correct, unforgeable, and private.

**Group Signatures.** Subsequently, we recall the established model for static group signatures from [3]. Again, we slightly adapt the notation to ours.

### Definition 4

\(\mathsf{KeyGen}(1^\kappa , n)\): Takes a security parameter \(\kappa \) and the group size

*n*as input. It generates and outputs a group verification key \(\mathsf{gpk}\), a group opening key \(\mathsf{gok}\), as well as a list of group signing keys \(\mathsf{gsk}= \{\mathsf{gsk}_i\}_{i\in [n]}\).\(\mathsf{Sign}(\mathsf{gsk}_i, \mathsf{m})\): Takes a group signing key \(\mathsf{gsk}_i\) and a message \(\mathsf{m}\) as input and outputs a signature \(\sigma \).

\(\mathsf{Verify}(\mathsf{gpk}, \mathsf{m}, \sigma )\): Takes a group verification key \(\mathsf{gpk}\), a message \(\mathsf{m}\) and a signature \(\sigma \) as input, and outputs a bit

*b*.\(\mathsf{Open}(\mathsf{gok}, \mathsf{m}, \sigma )\): Takes a group opening key \(\mathsf{gok}\), a message \(\mathsf{m}\) and a signature \(\sigma \) as input, and outputs an identity

*i*.

The \(\mathsf{GS}\) security properties are formally defined as follows (we omit correctness).

### Definition 5 (Anonymity)

### Definition 6 (Traceability)

We call a \(\mathsf{GS}\)*secure*, if it is correct, anonymous and traceable.

## 3 Security Model

Now we formally define signer-anonymous designated-verifier redactable signature schemes (AD-RS). To obtain the most general result, we follow [13] and do not make the structure of the messages to be signed explicit. Inspired by [20], we view signatures output by \(\mathsf{Sign}\) as being of the form \(\sigma = (\underline{\sigma }, \overline{\sigma })\). That is, signatures are composed of a public signature component \(\underline{\sigma }\) and a private signature component \(\overline{\sigma }\), where \(\underline{\sigma }\) may also be empty. For the sake of simple presentation we model our system for static groups, since an extension to dynamic groups [4] is straight forward.

### Definition 7

(AD-RS)**.** An AD-RS is a tuple \((\mathsf{Setup}\), \(\mathsf{DVGen}\), \(\mathsf{Sign}\), \(\mathsf{GVerify}\), \(\mathsf{Open}\), \(\mathsf{Redact}\), \(\mathsf{Verify}\), \(\mathsf{Sim})\) of PPT algorithms, which are defined as follows.

\(\mathsf{Setup}(1^\kappa , n)\): Takes a security parameter \(\kappa \) and the group size

*n*as input. It generates and outputs a group public key \(\mathsf{gpk}\), a group opening key \(\mathsf{gok}\), and a list of group signing keys \(\mathsf{gsk}= \{\mathsf{gsk}_i \}_{i\in [n]}\).\(\mathsf{DVGen}(1^\kappa )\): Takes a security parameter \(\kappa \) as input and outputs a designated verifier key pair \((\mathsf{vsk}_j, \mathsf{vpk}_j)\).

\(\mathsf{Sign}(\mathsf{gsk}_i, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}})\): Takes a group signing key \(\mathsf{gsk}_i\), a message \(\mathsf{m}\), and admissible modifications \({{{\mathsf{{\textsc {ADM}}}}}}\) as input, and outputs a signature \(\sigma \).

\(\mathsf{GVerify}(\mathsf{gpk}, \mathsf{m}, \sigma )\): Takes a group public key \(\mathsf{gpk}\), a message \(\mathsf{m}\), and a signature \(\sigma \) as input, and outputs a bit

*b*.\(\mathsf{Open}(\mathsf{gok}, \mathsf{m}, \sigma )\): Takes a group opening key \(\mathsf{gok}\), a message \(\mathsf{m}\), and a valid signature \(\sigma \) as input, and outputs an identity

*i*.\(\mathsf{Redact}(\mathsf{gpk}, \mathsf{vpk}_j, \mathsf{m}, \sigma , {{{\mathsf{{\textsc {MOD}}}}}})\): Takes a group public key \(\mathsf{gpk}\), a designated-verifier public key \(\mathsf{vpk}_j\), a message \(\mathsf{m}\), a valid signature \(\sigma \), and modification instructions \({{{\mathsf{{\textsc {MOD}}}}}}\) as input, and returns a designated-verifier message-signature pair \((\mathring{\mathsf{m}}, \rho )\).

\(\mathsf{Verify}(\mathsf{gpk}, \mathsf{vpk}_j, \mathsf{m}, \rho )\): Takes a group public key \(\mathsf{gpk}\), a designated-verifier public key \(\mathsf{vpk}_j\), a message \(\mathsf{m}\), and a designated-verifier signature \(\rho \). It returns a bit

*b*.\(\mathsf{Sim}(\mathsf{gpk}, \mathsf{vsk}_j, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}}, {{{\mathsf{{\textsc {MOD}}}}}}, \underline{\sigma })\): Takes a group public key \(\mathsf{gpk}\), a designated-verifier secret key \(\mathsf{vsk}_j\), a message \(\mathsf{m}\), admissible modifications \({{{\mathsf{{\textsc {ADM}}}}}}\), modification instructions \({{{\mathsf{{\textsc {MOD}}}}}}\), and a valid public signature component \(\underline{\sigma }\) as input and outputs a designated-verifier message signature pair \((\mathring{\mathsf{m}}, \rho )\).

**Oracles.** We base our security notions on the following oracles and assume that \((\mathsf{gpk}, \mathsf{gok}, \mathsf{gsk})\) generated in the experiments are implicitly available to them. The environment stores a list \(\mathtt {DVK}\) of designated-verifier key pairs, and a set of public signature components \(\mathtt {SIG}\). Each list entry and each set is initially set to \(\bot \).

\({\mathsf{Key}(i)}\): This oracle returns \(\mathsf{gsk}_i\).

\({\mathsf{DVGen}(j)}\): If \(\mathtt {DVK}[j] \ne \bot \) this oracle returns \(\bot \). Otherwise, it runs \((\mathsf{vsk}_j, \mathsf{vpk}_j) \leftarrow \mathsf{DVGen}(1^\kappa )\), sets \(\mathtt {DVK}[j] \leftarrow (\mathsf{vsk}_j, \mathsf{vpk}_j)\), and returns \(\mathsf{vpk}_j\).

\({\mathsf{DVKey}(j)}\): This oracle returns \(\mathsf{vsk}_j\).

\({\mathsf{Sig}(i, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}})}\): This oracle runs \(\sigma = (\underline{\sigma }, \overline{\sigma }) \leftarrow \mathsf{Sign}(\mathsf{gsk}_i, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}})\), sets \(\mathtt {SIG}\leftarrow \mathtt {SIG}\cup \{\underline{\sigma }\}\) and returns \(\sigma \).

\({\mathsf{Open}(\mathsf{m}, \sigma )}\): This oracle runs \(i \leftarrow \mathsf{Open}(\mathsf{gok}, \mathsf{m}, \sigma )\) and returns

*i*.\({{\mathsf{Sim}(j, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}}, {{{\mathsf{{\textsc {MOD}}}}}}, \underline{\sigma })}}\): If \(\underline{\sigma } \notin \mathtt {SIG}\), this oracle returns \(\bot \). Otherwise, it runs \((\mathring{\mathsf{m}}, \rho ) \leftarrow \mathsf{Sim}(\mathsf{gpk}, \mathsf{vsk}_j,\mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}}, {{{\mathsf{{\textsc {MOD}}}}}}, \underline{\sigma })\) and returns \((\mathring{\mathsf{m}}, \rho )\).

\(\mathsf{RoS}(b, j, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}}, {{{\mathsf{{\textsc {MOD}}}}}}, \sigma )\): If \(b=0\), this oracle runs \((\mathring{\mathsf{m}}, \rho ) \leftarrow \mathsf{Redact}(\mathsf{gpk}, \mathsf{vpk}_j, \mathsf{m},\sigma , {{{\mathsf{{\textsc {MOD}}}}}})\) and returns \((\mathring{\mathsf{m}}, \rho )\). Otherwise, it uses the \(\mathsf{Sim}\) oracle to obtain \((\mathring{\mathsf{m}}, \rho ) \leftarrow \mathsf{Sim}(j, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}}, {{{\mathsf{{\textsc {MOD}}}}}}, \underline{\sigma })\) and returns \((\mathring{\mathsf{m}}, \rho )\).

\({\mathsf{Ch}(i, j, (\mathsf{m}_0, {{{\mathsf{{\textsc {ADM}}}}}}_0, {{{\mathsf{{\textsc {MOD}}}}}}_0), (\mathsf{m}_1, {{{\mathsf{{\textsc {ADM}}}}}}_1, {{{\mathsf{{\textsc {MOD}}}}}}_1),b)}\): This oracle runs \(\sigma _c \leftarrow \mathsf{Sign}(\mathsf{gsk}_i,\mathsf{m}_c, {{{\mathsf{{\textsc {ADM}}}}}}_c)\), \((\mathring{\mathsf{m}}_c,\rho _c) \leftarrow \mathsf{Redact}(\mathsf{vpk}_j, \mathsf{m}_c, \sigma _c, {{{\mathsf{{\textsc {MOD}}}}}}_c)\), for \(c \in \{0,1\}\). If \(\mathring{\mathsf{m}}_0 \ne \mathring{\mathsf{m}}_1 ~\vee ~\mathring{{{{\mathsf{{\textsc {ADM}}}}}}}_0 \ne \mathring{{{{\mathsf{{\textsc {ADM}}}}}}}_1\), it returns \(\bot \) and \((\mathring{\mathsf{m}}_b, \underline{\sigma }_b, \rho _b)\) otherwise.

^{4}

The environment stores the oracle queries in lists. In analogy to the oracle labels, we use \(\mathcal {Q}^\mathsf{Key}, \mathcal {Q}^\mathsf{DVGen},\mathcal {Q}^\mathsf{DVKey}, \mathcal {Q}^\mathsf{Sig}, \mathcal {Q}^\mathsf{Open}, \mathcal {Q}^\mathsf{Sim}, \mathcal {Q}^\mathsf{RoS},\) and \(\mathcal {Q}^\mathsf{Ch}\) to denote them.

**Security Notions.** We require AD-RS to be correct, group unforgeable, designated-verifier unforgeable, simulatable, signer anonymous, and private.

*Correctness* guarantees that all honestly computed signatures verify correctly.

Formally, we require that for all \(\kappa \in \mathbb {N}\), for all \(n \in \mathbb {N}\), for all \((\mathsf{gpk}, \mathsf{gok}, \mathsf{gsk}) \leftarrow \mathsf{Setup}(1^\kappa , n)\), for all \((\mathsf{vsk}_j, \mathsf{vpk}_j) \leftarrow \mathsf{DVGen}(1^\kappa )\), for all \((\mathsf{vsk}_\ell , \mathsf{vpk}_\ell ) \leftarrow \mathsf{DVGen}(1^\kappa )\), for all \((\mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}},{{{\mathsf{{\textsc {MOD}}}}}})\) where \({{{\mathsf{{\textsc {MOD}}}}}}\preceq {{{\mathsf{{\textsc {ADM}}}}}}~\wedge ~ {{{\mathsf{{\textsc {ADM}}}}}}\preceq \mathsf{m}\), for all \((\mathsf{m}', {{{\mathsf{{\textsc {ADM}}}}}}', {{{\mathsf{{\textsc {MOD}}}}}}')\) where \({{{\mathsf{{\textsc {MOD}}}}}}' \preceq {{{\mathsf{{\textsc {ADM}}}}}}' ~\wedge ~ {{{\mathsf{{\textsc {ADM}}}}}}' \preceq \mathsf{m}'\) for all \(i \in [n]\), for all \(\sigma = (\underline{\sigma }, \overline{\sigma }) \leftarrow \mathsf{Sign}(\mathsf{gsk}_i, \mathsf{m}, {{{\mathsf{{\textsc {ADM}}}}}})\), for all \(u \leftarrow \mathsf{Open}(\mathsf{gok}, \mathsf{m}, \sigma )\), for all \((\mathring{\mathsf{m}}, \rho ) \leftarrow \mathsf{Redact}(\mathsf{gpk}, \mathsf{vpk}_j, \mathsf{m}, \sigma , {{{\mathsf{{\textsc {MOD}}}}}})\), for all \((\mathring{\mathsf{m}}', \rho ') \leftarrow \mathsf{Sim}(\mathsf{gpk}, \mathsf{vsk}_\ell , \mathsf{m}', {{{\mathsf{{\textsc {ADM}}}}}}', {{{\mathsf{{\textsc {MOD}}}}}}', \underline{\sigma })\), it holds with overwhelming probability that \(\mathsf{GVerify}(\mathsf{gpk}, \mathsf{m}, \sigma ) = 1 ~\wedge ~ i = u ~\wedge ~ \mathsf{Verify}(\mathsf{gpk}, \mathsf{vpk}_j, \mathring{\mathsf{m}}, \rho ) = 1 ~\wedge ~ \mathsf{Verify}(\mathsf{gpk}, \mathsf{vpk}_\ell , \mathring{\mathsf{m}}', \rho ') = 1\) and that Open image in new window.

*Group unforgeability* captures the intuition that the only way of obtaining valid signatures on messages is by applying “allowed” modifications to messages which were initially signed by a group member. Moreover, this property guarantees that every valid signature can be linked to the original signer by some authority.

Technically, the definition captures the traceability property of group signatures while simultaneously taking the malleability of RS into account.

### Definition 8

*Designated-verifier unforgeability* models the requirement that a designated-verifier signature can only be obtained in two ways: either by correctly redacting a signature (which can be done by everybody having access to the latter), or by having access to the secret key of the designated verifier. The former option would be chosen whenever a signature is to be legitimately forwarded to a receiver, while the latter enables the designated verifier to fake signatures.

Together with the previous definition, designated-verifier unforgeability guarantees that no adversary can come up with a designated-verifier signature for a foreign public key: by Definition 8 it is infeasible to forge a signature—and Definition 9 states that the only way of generating a designated-verifier signature for somebody else is to know a valid signature to start from.

### Definition 9

In our definition, we assume a simple key registration for designated verifiers to ensure that all designated-verifier key pairs have been honestly created and thus an adversary is not able to mount rogue key attacks. In practice, this requirement can often be alleviated by introducing an option to check the honest generation of the keys (cf. [23]), which we omit for simplicity.

*Simulatability* captures that designated verifiers can simulate signatures on arbitrary messages which are indistinguishable from honestly computed signatures.

### Definition 10

As mentioned earlier, we assume that signatures consist of a private and a public component (the latter being denoted by \(\underline{\sigma }\)). To eliminate potential privacy issues associated with a public \(\underline{\sigma }\), we also give \(\underline{\sigma }\) as input to the simulator and the adversary, and require that the adversary cannot tell real and faked signatures apart *even when knowing*\(\underline{\sigma }\). This way, our definitional framework guarantees that these parts do not contain any sensitive information.

In a realization of the system, the public parts of all signatures issued by the hospital would be made publicly available (without further meta-information).

*Signer anonymity* requires that only the opening authority can determine the identity of a signer.

### Definition 11

The definition guarantees that—no matter how many signatures already have been opened—the signers’ identities for all other signatures remain secret. The formulation is, up to the last clause of the winning condition, similar to the anonymity definition of group signature schemes (cf. Definition 5). We, however, need to adapt the last clause because Definition 5 requires signatures to be non-malleable. In contrast, our signatures are malleable by definition. However, we can still require parts of the signature, and in particular the public part, to be non-malleable. By doing so, we can achieve a strong notion that resembles anonymity in the sense of group signatures whenever honestly generated signatures have different public components with overwhelming probability. This is in particular the case for our instantiations provided in the next sections.

*Privacy* guarantees that a redacted designated-verifier signature does not leak anything about the blacked-out parts of the original message.

### Definition 12

We call an AD-RS *secure*, if it is correct, group unforgeable, designated-verifier unforgeable, simulatable, signer anonymous, and private.

**Group Redactable Signatures.** When omitting the \(\mathsf{DV}\)-related notions and oracles, one directly obtains a definition of group redactable signatures, which may also be useful for applications that require revocable signer-anonymity.

## 4 A Generic Construction

*R*required by the verification of designated-verifier signatures.The rationale behind choosing

*R*in this way is that this yields the most general result. That is, no further assumptions on RS or \(\mathsf {\Sigma }\) are required.

### Theorem 1 (proven in the extended version)

If \(\mathsf{GS}\), RS, and \(\mathsf {\Sigma }\) are secure and \(\mathsf{\Pi }\) is witness indistinguishable and admits proofs of knowledge, then Scheme 1 is secure.

For an instantiation of our construction we can use standard \(\mathsf{GS}\) and standard RS, where multiple practically efficient instantiations exist. Thus, the time required for signature creation/verification is mainly determined by the cost of the proof of knowledge of the RS signature \(\sigma _\mathsf{R}\). We, however, want to emphasize that—depending on the concrete RS—this proof can usually be instantiated by means of relatively cheap \(\varSigma \)-protocols. Ultimately, as we will show below, we can replace this proof with a much cheaper proof by exploiting properties of the used RS.

## 5 Boosting Efficiency via Key-Homomorphisms

In [13] it is shown that RS can be generically constructed from any \(\mathsf{EUF}\)-\(\mathsf{CMA}\) secure signature scheme and indistinguishable accumulators [12]. In our setting it is most reasonable to consider messages as an (ordered) sequence of message blocks. A straight forward solution would thus be to build upon [13, Scheme 2], which is tailored to signing ordered sequences of messages \(\mathsf{m}= (m_1, \dots , m_n)\). Unfortunately, this construction aims to conceal the number of message blocks in the original message, and the positions of the redactions. This can be dangerous in our setting, since it might allow to completely change the document semantics. Besides that, it inherently requires a more complex construction.

To this end, we pursue a different direction and require another message representation: we make the position *i* of the message blocks \(m_i\) in the message explicit and represent messages as sets \(\mathsf{m}=\{1||m_1, \dots , n||m_n\}\). Besides solving the aforementioned issues, it also allows us to build upon the (simpler) RS paradigm for sets [13, Scheme 1]. This paradigm subsumes the essence of many existing RSs and works as follows. Secret keys, public keys, and signatures are split into two parts each. One corresponds to the signature scheme \(\mathsf {\Sigma }\), and one corresponds to the accumulator \(\varLambda \). Then, \(\varLambda \) is used to encode the message, whereas \(\mathsf {\Sigma }\) is used to sign the encoded message. Consequently, we can look at RS key pairs and signatures as being of the form \((\mathsf{sk}, \mathsf{pk}) = ((\mathsf{sk}_{\mathsf {\Sigma }}, \mathsf{sk}_{\varLambda }, \mathsf{pk}_{\varLambda }), (\mathsf{pk}_{\mathsf {\Sigma }},\mathsf{pk}_{\varLambda }))\) and \(\sigma _\mathsf{R} = (\sigma _{\mathsf {\Sigma }}, \sigma _{\varLambda })\) where the indexes denote their respective types. We emphasize that for accumulators it holds by definition that \(\mathsf{sk}_{\varLambda }\) is an optional trapdoor which may enable more efficient computations, but all algorithms also run without \(\mathsf{sk}_{\varLambda }\) and the output distribution of the algorithms does not depend on whether the algorithms are executed with or without \(\mathsf{sk}_{\varLambda }\) [12, 13]. We require this property to be able to create designated verifier signatures (cf. Sim) and use \((\mathsf{sk}_{\mathsf {\Sigma }}, \bot , \mathsf{pk}_{\varLambda })\) to denote an RS secret key without \(\mathsf{sk}_{\varLambda }\).

RS following this paradigm only require \(\mathsf {\Sigma }\) (besides correctness) to be \(\mathsf{EUF}\)-\(\mathsf{CMA}\) secure. We observe that additional constraints on \(\mathsf {\Sigma }\)—and in particular the key-homomorphism as we define it below—does not influence RS security, while it enables us to design the relation *R* such that it admits very efficient proofs.

**Key-Homomorphic Signatures.** Informally, we require signature schemes where, for a given public key and a valid signature under that key, one can adapt the public key and the signature so that the resulting signature is valid with respect to the initial message under the new public key. Moreover, adapted signatures need to be identically distributed as fresh signatures under the secret key corresponding to the adapted public key.

Key-malleability in the sense of adapting given signatures to other signatures under related keys has so far mainly been studied in context of related-key attacks (RKAs) [2], where one aims to rule out such constructions. Signatures with re-randomizable keys which allow to consistently update secret and public keys, but without considering adaption of existing signatures, have recently been introduced and studied in [16]. As we are not aware of any constructive use of and definitions for the functionality we require, we define key-homomorphic signatures inspired by key-homomorphic symmetric encryption (cf. [1]).

Let \(\mathsf {\Sigma }= (\mathsf{KeyGen}, \mathsf{Sign},\mathsf{Verify})\) be an \(\mathsf{EUF}\)-\(\mathsf{CMA}\) secure signature scheme where the secret and public keys live in groups \((\mathbb {H}, +)\) and \((\mathbb {G}, \cdot )\), respectively. Inspired by the definition for encryption schemes in [28], we define the following.

### Definition 13 (Secret-Key to Public-Key Homomorphism)

A signature scheme \(\mathsf {\Sigma }\) provides a secret-key to public-key homomorphism, if there exists an efficiently computable map \(\mu : \mathbb {H}\rightarrow \mathbb {G}\) such that for all \(\mathsf{sk}, \mathsf{sk}' \in \mathbb {H}\) it holds that \(\mu (\mathsf{sk}+\mathsf{sk}') = \mu (\mathsf{sk}) \cdot \mu (\mathsf{sk}')\), and for all \((\mathsf{sk}, \mathsf{pk})\) output by \(\mathsf{KeyGen}\), it holds that \(\mathsf{pk}= \mu (\mathsf{sk})\).

Now, we define key-homomorphic signatures, where we focus on the class of functions \(\varPhi ^+\) representing linear shifts. We stress that \(\varPhi ^+\) is a finite set of functions, all with the same domain and range, and, in our case depends on the public key of the signature scheme (which is not made explicit). Moreover, \(\varPhi ^+\) admits an efficient membership test and its functions are efficiently computable.

### Definition 14

**(**\(\varPhi ^+\)

**-Key-Homomorphic Signatures**

**).**A signature scheme is called \(\varPhi ^+\)-key-homomorphic, if it provides a secret-key to public-key homomorphism and an additional PPT algorithm \(\mathsf{Adapt}\), defined as:

\(\mathsf{Adapt}(\mathsf{pk}, \mathsf{m}, \sigma , \varDelta )\): Takes a public key \(\mathsf{pk}\), a message \(\mathsf{m}\), a signature \(\sigma \), and a function \(\varDelta \in \varPhi ^+\) as input, and outputs a public key \(\mathsf{pk}'\) and a signature \(\sigma '\),

For simplicity we sometimes identify a function \(\varDelta \in \varPhi ^+\) with its “shift amount” \(\varDelta \in \mathbb {H}\). To model that freshly generated signatures look identical as adapted signatures on the same message, we introduce the following additional property.

### Definition 15 (Adaptability of Signatures)

A \(\varPhi ^+\)-key-homomorphic signature scheme provides adaptability of signatures, if for every \(\kappa \in \mathbb {N}\), and every message \(\mathsf{m}\), it holds that \(\mathsf{Adapt}(\mathsf{pk}, \mathsf{m},\mathsf{Sign}(\mathsf{sk}, \mathsf{m}), \varDelta )\) and \((\mathsf{pk}\cdot \mu (\varDelta ), \mathsf{Sign}(\mathsf{sk}+\varDelta , \mathsf{m}))\) as well as \((\mathsf{sk}, \mathsf{pk})\) and \((\mathsf{sk}', \mu (\mathsf{sk}'))\) are identically distributed, where \((\mathsf{sk},\mathsf{pk})\leftarrow \mathsf{KeyGen}(1^\kappa )\), Open image in new window, and Open image in new window.

For an in-depth treatment and examples of key-homomorphic signatures, we refer the reader to a more recent work [14]. The important bottom-line here is that there are various efficient schemes that satisfy Definition 15. For instance, Schnorr signatures [24], BLS signatures [5], the recent scheme by Pointcheval and Sanders [22] or Waters signatures [30].

\(\varPhi ^+\)**-Key-Homomorphic Redactable Signature Schemes.** When instantiating the RS construction paradigm from [13] (as outlined above) with a \(\varPhi ^+\)-key-homomorphic signature scheme, the key homomorphism of the signature scheme straight-forwardly carries over to the RS and we can define \(\mathsf{Adapt}\) as follows.

\(\mathsf{Adapt}(\mathsf{pk}, \mathsf{m}, \sigma , \varDelta )\): Parse \(\mathsf{pk}\) as \((\mathsf{pk}_{\mathsf {\Sigma }}, \mathsf{pk}_{\varLambda })\) and \(\sigma \) as \((\sigma _{\mathsf {\Sigma }}, \sigma _{\varLambda })\), run \((\mathsf{pk}_{\mathsf {\Sigma }}', \sigma _{\mathsf {\Sigma }}') \leftarrow \mathsf{Adapt}(\mathsf{pk}_{\mathsf {\Sigma }}, \varLambda (\mathsf{m}), \sigma _{\mathsf {\Sigma }},\varDelta )\) and return \((\mathsf{pk}', \sigma ') \leftarrow ((\mathsf{pk}_{\mathsf {\Sigma }}', \mathsf{pk}_{\varLambda }), (\sigma _{\mathsf {\Sigma }}', \sigma _{\varLambda }))\).

*two group exponentiations*.

## 6 Conclusion

We introduce the notion of signer-anonymous designated-verifier redactable signatures, extending redactable signatures in their vanilla form in several important directions. These additional features are motivated by a real world use-case in the health care field, demonstrating its practical relevance. Besides rigorously modelling this primitive, we provide two instantiations. While both are interesting from a theoretical point of view, the latter is also interesting in practice. In particular, due to using key-homomorphic signatures as we introduce them in this paper, we obtain a simple and practically efficient solution (a performance analysis confirming the practical efficiency is provided in the extended version).

## Footnotes

- 1.
See e.g., http://www.healthcaredive.com/news/407746/.

- 2.
- 3.
As it is common for RS, we assume that \({{{\mathsf{{\textsc {ADM}}}}}}\) can always be recovered from \((\mathsf{m}, \sigma )\).

- 4.
Here \(\mathring{{{{\mathsf{{\textsc {ADM}}}}}}}_0\) and \(\mathring{{{{\mathsf{{\textsc {ADM}}}}}}}_1\) are derived from \({{{\mathsf{{\textsc {ADM}}}}}}_0\) and \({{{\mathsf{{\textsc {ADM}}}}}}_1\) with respect to \({{{\mathsf{{\textsc {MOD}}}}}}_0\) and \({{{\mathsf{{\textsc {MOD}}}}}}_1\).

### References

- 1.Applebaum, B., Harnik, D., Ishai, Y.: Semantic security under related-key attacks and applications. In: ICS (2011)Google Scholar
- 2.Bellare, M., Cash, D., Miller, R.: Cryptography secure against related-key attacks and tampering. In: Lee, D.H., Wang, X. (eds.) ASIACRYPT 2011. LNCS, vol. 7073, pp. 486–503. Springer, Heidelberg (2011). doi:10.1007/978-3-642-25385-0_26 CrossRefGoogle Scholar
- 3.Bellare, M., Micciancio, D., Warinschi, B.: Foundations of group signatures: formal definitions, simplified requirements, and a construction based on general assumptions. In: Biham, E. (ed.) EUROCRYPT 2003. LNCS, vol. 2656, pp. 614–629. Springer, Heidelberg (2003). doi:10.1007/3-540-39200-9_38 CrossRefGoogle Scholar
- 4.Bellare, M., Shi, H., Zhang, C.: Foundations of group signatures: the case of dynamic groups. In: Menezes, A. (ed.) CT-RSA 2005. LNCS, vol. 3376, pp. 136–153. Springer, Heidelberg (2005). doi:10.1007/978-3-540-30574-3_11 CrossRefGoogle Scholar
- 5.Boneh, D., Lynn, B., Shacham, H.: Short signatures from the weil pairing. J. Cryptology
**17**(4), 297–319 (2004)MathSciNetCrossRefMATHGoogle Scholar - 6.Brzuska, C., et al.: Redactable signatures for tree-structured data: definitions and constructions. In: Zhou, J., Yung, M. (eds.) ACNS 2010. LNCS, vol. 6123, pp. 87–104. Springer, Heidelberg (2010). doi:10.1007/978-3-642-13708-2_6 CrossRefGoogle Scholar
- 7.Brzuska, C., Fischlin, M., Lehmann, A., Schröder, D.: Unlinkability of sanitizable signatures. In: Nguyen, P.Q., Pointcheval, D. (eds.) PKC 2010. LNCS, vol. 6056, pp. 444–461. Springer, Heidelberg (2010). doi:10.1007/978-3-642-13013-7_26 CrossRefGoogle Scholar
- 8.Brzuska, C., Pöhls, H.C., Samelin, K.: Efficient and perfectly unlinkable sanitizable signatures without group signatures. In: Katsikas, S., Agudo, I. (eds.) EuroPKI 2013. LNCS, vol. 8341, pp. 12–30. Springer, Heidelberg (2014). doi:10.1007/978-3-642-53997-8_2 CrossRefGoogle Scholar
- 9.Camenisch, J., Dubovitskaya, M., Haralambiev, K., Kohlweiss, M.: Composable and modular anonymous credentials: definitions and practical constructions. In: Iwata, T., Cheon, J.H. (eds.) ASIACRYPT 2015. LNCS, vol. 9453, pp. 262–288. Springer, Heidelberg (2015). doi:10.1007/978-3-662-48800-3_11 CrossRefGoogle Scholar
- 10.Chaum, D.: Designated confirmer signatures. In: Santis, A. (ed.) EUROCRYPT 1994. LNCS, vol. 950, pp. 86–91. Springer, Heidelberg (1995). doi:10.1007/BFb0053427 Google Scholar
- 11.Chaum, D., Antwerpen, H.: Undeniable signatures. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 212–216. Springer, Heidelberg (1990). doi:10.1007/0-387-34805-0_20 CrossRefGoogle Scholar
- 12.Derler, D., Hanser, C., Slamanig, D.: Revisiting cryptographic accumulators, additional properties and relations to other primitives. In: Nyberg, K. (ed.) CT-RSA 2015. LNCS, vol. 9048, pp. 127–144. Springer, Heidelberg (2015). doi:10.1007/978-3-319-16715-2_7 Google Scholar
- 13.Derler, D., Pöhls, H.C., Samelin, K., Slamanig, D.: A general framework for redactable signatures and new constructions. In: Kwon, S., Yun, A. (eds.) ICISC 2015. LNCS, vol. 9558, pp. 3–19. Springer, Heidelberg (2016). doi:10.1007/978-3-319-30840-1_1 CrossRefGoogle Scholar
- 14.Derler, D., Slamanig, D.: Key-homomorphic signatures and applications to multiparty signatures. IACR Cryptology ePrint Archive 2016, 792 (2016)Google Scholar
- 15.Fiat, A., Shamir, A.: How to prove yourself: practical solutions to identification and signature problems. In: Odlyzko, A.M. (ed.) CRYPTO 1986. LNCS, vol. 263, pp. 186–194. Springer, Heidelberg (1987). doi:10.1007/3-540-47721-7_12 Google Scholar
- 16.Fleischhacker, N., Krupp, J., Malavolta, G., Schneider, J., Schröder, D., Simkin, M.: Efficient unlinkable sanitizable signatures from signatures with re-randomizable keys. In: Cheng, C.-M., Chung, K.-M., Persiano, G., Yang, B.-Y. (eds.) PKC 2016. LNCS, vol. 9614, pp. 301–330. Springer, Heidelberg (2016). doi:10.1007/978-3-662-49384-7_12 CrossRefGoogle Scholar
- 17.Jakobsson, M., Sako, K., Impagliazzo, R.: Designated verifier proofs and their applications. In: Maurer, U. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 143–154. Springer, Heidelberg (1996). doi:10.1007/3-540-68339-9_13 Google Scholar
- 18.Johnson, R., Molnar, D., Song, D., Wagner, D.: Homomorphic signature schemes. In: Preneel, B. (ed.) CT-RSA 2002. LNCS, vol. 2271, pp. 244–262. Springer, Heidelberg (2002). doi:10.1007/3-540-45760-7_17 CrossRefGoogle Scholar
- 19.Lipmaa, H., Wang, G., Bao, F.: Designated verifier signature schemes: attacks, new security notions and a new construction. In: Caires, L., Italiano, G.F., Monteiro, L., Palamidessi, C., Yung, M. (eds.) ICALP 2005. LNCS, vol. 3580, pp. 459–471. Springer, Heidelberg (2005). doi:10.1007/11523468_38 CrossRefGoogle Scholar
- 20.Monnerat, J., Pasini, S., Vaudenay, S.: Efficient deniable authentication for signatures. In: Abdalla, M., Pointcheval, D., Fouque, P.-A., Vergnaud, D. (eds.) ACNS 2009. LNCS, vol. 5536, pp. 272–291. Springer, Heidelberg (2009). doi:10.1007/978-3-642-01957-9_17 CrossRefGoogle Scholar
- 21.Pöhls, H.C., Samelin, K.: Accountable redactable signatures. In: ARES (2015)Google Scholar
- 22.Pointcheval, D., Sanders, O.: Short randomizable signatures. In: Sako, K. (ed.) CT-RSA 2016. LNCS, vol. 9610, pp. 111–126. Springer, Heidelberg (2016). doi:10.1007/978-3-319-29485-8_7 CrossRefGoogle Scholar
- 23.Ristenpart, T., Yilek, S.: The power of proofs-of-possession: securing multiparty signatures against rogue-key attacks. In: Naor, M. (ed.) EUROCRYPT 2007. LNCS, vol. 4515, pp. 228–245. Springer, Heidelberg (2007). doi:10.1007/978-3-540-72540-4_13 CrossRefGoogle Scholar
- 24.Schnorr, C.: Efficient signature generation by smart cards. J. Cryptology
**4**(3), 161–174 (1991)MathSciNetCrossRefMATHGoogle Scholar - 25.Shahandashti, S.F., Safavi-Naini, R.: Construction of universal designated-verifier signatures and identity-based signatures from standard signatures. In: Cramer, R. (ed.) PKC 2008. LNCS, vol. 4939, pp. 121–140. Springer, Heidelberg (2008). doi:10.1007/978-3-540-78440-1_8 CrossRefGoogle Scholar
- 26.Steinfeld, R., Bull, L., Wang, H., Pieprzyk, J.: Universal designated-verifier signatures. In: Laih, C.-S. (ed.) ASIACRYPT 2003. LNCS, vol. 2894, pp. 523–542. Springer, Heidelberg (2003). doi:10.1007/978-3-540-40061-5_33 CrossRefGoogle Scholar
- 27.Steinfeld, R., Bull, L., Zheng, Y.: Content extraction signatures. In: Kim, K. (ed.) ICISC 2001. LNCS, vol. 2288, pp. 285–304. Springer, Heidelberg (2002). doi:10.1007/3-540-45861-1_22 CrossRefGoogle Scholar
- 28.Tessaro, S., Wilson, D.A.: Bounded-collusion identity-based encryption from semantically-secure public-key encryption: generic constructions with short ciphertexts. In: Krawczyk, H. (ed.) PKC 2014. LNCS, vol. 8383, pp. 257–274. Springer, Heidelberg (2014). doi:10.1007/978-3-642-54631-0_15 CrossRefGoogle Scholar
- 29.Vergnaud, D.: New extensions of pairing-based signatures into universal designated verifier signatures. In: Bugliesi, M., Preneel, B., Sassone, V., Wegener, I. (eds.) ICALP 2006. LNCS, vol. 4052, pp. 58–69. Springer, Heidelberg (2006). doi:10.1007/11787006_6 CrossRefGoogle Scholar
- 30.Waters, B.: Efficient identity-based encryption without random oracles. In: Cramer, R. (ed.) EUROCRYPT 2005. LNCS, vol. 3494, pp. 114–127. Springer, Heidelberg (2005). doi:10.1007/11426639_7 CrossRefGoogle Scholar