1 Introduction

Proxy re-cryptography [11] is a powerful concept which allows proxies to transform cryptographic objects under one key to cryptographic objects under another key using a transformation key (a so called re-key). In particular, proxy re-encryption has shown to be of great practical interest in cloud scenarios such as data storage [12, 16], data sharing [49], publish-subscribe [15] as well as cloud-based identity management [41, 42, 47, 50]. In contrast, other proxy re-primitives, and in particular proxy re-signatures (or MACs), seem to unleash their full potential not before considering them in combination with homomorphic properties on the message space. Interestingly, however, this direction has received no attention so far. To this end, we introduce the notion of homomorphic proxy re-authenticators (\(\mathsf {HPRA}\)s), which allows distinct senders to authenticate data under their own keys, and an evaluator (aggregator) can transform these single signatures or message authentication codes (MACs) to a MAC under a receiver’s key without knowing it. Most importantly, the aggregator can evaluate arithmetic circuits (functions) on the inputs so that the resulting MAC corresponds to the evaluation of the respective function. Furthermore, we investigate whether we can hide the input messages from the aggregator. On the way to solve this, we formally define the notion of homomorphic proxy re-encryption (\(\mathsf {HPRE}\)). Data aggregation is the central application of our framework, but it is not limited to this application.

Motivation. Data aggregation is an important task in the Internet of Things (IoT) and cloud computing. We observe a gap in existing work as the important issue of end-to-end authenticity and verifiability of computations on the data (aggregation results) is mostly ignored. We address this issue and propose a versatile non-interactive solution which is tailored to a multi-user setting. The additional authenticity features of our solution add robustness to errors occurring during transmission or aggregation even in the face of a non-trusted aggregator.

Multi-User Data Aggregation. Assume a setting where n senders, e.g., sensor nodes, regularly report data to some entity denoted the aggregator. The aggregator collects the data and then reports computations (evaluations of functions) on these data to a receiver. For example, consider environmental monitoring of hydroelectric plants being located in a mountainous region, where small sensors are used for monitoring purposes. Due to the lack of infrastructure (e.g., very limited cell coverage) sensors are not directly connected to the Internet and collected data is first sent to a gateway running at the premise of some telecommunication provider. This gateway aggregates the data and forwards it to some cloud service operated by the receiver.

Obviously, when the involved parties communicate via public networks, security related issues arise. Apart from achieving security against outsiders, there are also security and privacy related issues with respect to the involved parties.

In general, we identify three main goals. (1) End-to-end authenticity, i.e., protecting data items from unauthorized manipulation and preserving the source authenticity. (2) Concealing the original data from the aggregator and the receiver, and, even further, concealing the result of the computation from the aggregator. Clearly, in (2) we also want to conceal data from any outsider. (3) Establishing independent secret keys for the involved parties so that they do not share a single secret. Latter facilitates a dynamic setting.

Below, we present such an aggregation scenario, discuss why straightforward solutions fall short, and sketch our solution. Then, we discuss the problems popping up when we require stronger privacy guarantees and show how our primitives help to overcome these issues.

Authenticity and Input Privacy. In our first scenario, the n senders each hold their own signing key and within every period sender i reports a signed data item \(d_i\) to the aggregator. The aggregator must be able to evaluate functions \(f\in \mathcal F\) (where \(\mathcal F\) is some suitable class of functions, e.g., linear functions) on \(d_1,\ldots ,d_n\) so that a receiver will be convinced of the authenticity of the data and the correctness of the computation without fully trusting the aggregator (recall the end-to-end authenticity requirement). Moreover, although the inputs to the aggregator are not private, we still want them to be hidden relative to the function f, i.e., so that a receiver only learns what is revealed by f and \(\hat{d} = f(d_1, \dots , d_n)\), as a receiver might not need to learn the single input values.

A central goal is that the single data sources have individual keys. Thus, we can not directly employ homomorphic signatures (or MACs). Also the recent concept of multikey-homomorphic signatures [25, 26, 33] does not help: even though they allow homomorphic operations on the key space, they do not consider transformations to some specific target key.Footnote 1 With \(\mathsf {HPRA}\)s we can realize this, as the aggregator (who holds re-keys from the senders to some receiver) can transform all the single signatures or MACs to a MAC under the receiver’s key (without having access to it). Moreover, due to the homomorphic property, a MAC which corresponds to the evaluation of a function f on the inputs can be computed. The receiver can then verify the correctness of the computation, i.e., that \(\hat{d} = f(d_1, \dots , d_n)\), and the authenticity of the used inputs (without explicitly learning them) using its independent MAC key.

Adding Output Privacy. In our second scenario, we additionally want data privacy guarantees with respect to the aggregator. This can be crucial if the aggregator is running in some untrusted environment, e.g., the cloud. We achieve this by constructing an output private \(\mathsf {HPRA}\). In doing so, one has to answer the question as how to confidentially provide the result of the computation to the receiver and how to guarantee the authenticity (verifiability) of the computation. We tackle this issue by introducing a \(\mathsf {HPRE}\) where the homomorphism is compatible to the one of the \(\mathsf {HPRA}\). The sources then additionally encrypt the data under their own keys and the aggregator re-encrypts the individual ciphertexts to a ciphertext under a receiver’s key and evaluates the same function f as on the MACs on the ciphertexts. This enables the receiver to decrypt the result \(\hat{d}\) using its own decryption key and to verify the MAC on \(\hat{d}\) together with a description of the function f. In addition, we use a trick to prevent public verifiability of the signatures from the single data sources, as public verifiability potentially leaks the signed data items which trivially would destroy output privacy.

Contribution. Our contributions in this paper can be summarized as follows.

  • We introduce the notion of homomorphic proxy re-authenticators (\(\mathsf {HPRA}\)). Our framework tackles multi-user data aggregation in a dynamic setting. For the first time, we thereby consider independent keys of the single parties, the verifiability of the evaluation of general functions on the authenticated inputs by the sources, as well as privacy with respect to the aggregator.

  • As a means to achieve the strong privacy requirements imposed by our security model, we formally define the notion of homomorphic proxy re-encryption (\(\mathsf {HPRE}\)), which may be of independent interest.

  • We present two modular constructions of \(\mathsf {HPRA}\) schemes for the class \(\mathcal{F}_\mathsf{lin}\) of linear functions, which differ regarding the strength of the provided privacy guarantees. On our way, we establish various novel building blocks. Firstly, we present a linearly homomorphic MAC which is suitable to be used in our construction. Secondly, to achieve the stronger privacy guarantees, we construct a \(\mathsf {HPRE}\) scheme for linear functions. All our proofs are modular in the sense that we separately prove the security of our building blocks; our overall proofs then build upon the results obtained for the building blocks. Thus, our building blocks may as well easily be used in other constructions.

Related Work. Subsequently, we review related work. As our focus is on non-interactive approaches, we omit interactive approaches where clients download all the data, decrypt them locally, compute a function, and send the results back along with a zero-knowledge proof of correctness (as, e.g., in [24]).

Proxy Re-Cryptography. Proxy re-encryption (\(\mathsf {PRE}\)) [11] allows a semi-trusted proxy to transform a message encrypted under the key of some party into a ciphertext to the same message under a key of another party, where the proxy performing the re-encryption learns nothing about the message. This primitive has been introduced in [11], further studied in [30] and the first strongly secure constructions have been proposed by Ateniese et al. in [5]. Boneh et al. construct \(\mathsf {PRE}\) in the symmetric setting [14]. Follow-up work focuses on even stronger (\(\mathsf{IND}\)-\(\mathsf{CCA2}\) secure) schemes (cf. [17, 39, 43, 44]). Since we, however, require certain homomorphic properties, we focus on \(\mathsf{IND}\)-\(\mathsf{CPA}\) secure schemes (as \(\mathsf{IND}\)-\(\mathsf{CCA2}\) security does not allow any kind of malleability). In previous work by Ayday et al. [7], a variant of the linearly homomorphic Paillier encryption scheme and proxy encryption in the sense of [30] were combined. Here, the holder of a key splits the key and gives one part to the proxy and one to the sender; with the drawback that the secret key is exposed when both collude. We are looking for proxy re-encryption that is homomorphic, works in a multi-user setting but is collusion-safe and non-interactive, i.e., re-encryption keys can be computed by the sender using only the public key of the receiver without any interaction and a collusion of sender and proxy does not reveal the receiver’s key. Also note that, as our focus is on practically efficient constructions, we do not build upon fully homomorphic encryption [27], which allows to build \(\mathsf {HPRE}\) using the rather expensive bootstrapping technique. In concurrent work Ma et al. [40] follow this approach and propose a construction of a \(\mathsf {PRE}\) scheme with homomorphic properties which additionally achieves key privacy. They build upon [28] using the bootstrapping techniques in [4] and apply some modifications for key privacy. While their construction can be seen as a \(\mathsf {HPRE}\) in our sense, they do not formally define a corresponding security model and we are not aware of a suitable formalization for our purposes.

Proxy re-signatures, i.e., the signature analogue to proxy re-encryption, have been introduced in [11] and formally studied in [30]. Later, [6] introduced stronger security definitions, constructions and briefly discussed some applications. However, the schemes in [6] and follow up schemes [38] do not provide a homomorphic property and it is unclear how they could be extended. The concept of homomorphic proxy re-authenticators, which we propose, or a related concept, has to the best of our knowledge not been studied before.

Homomorphic Authenticators. General (non-interactive) verifiable computing techniques (cf. [48] for a recent overview) are very expressive, but usually prohibitive regarding proof computation (proof size and verification can, however, be very small and cheap respectively). In addition, the function and/or the data needs to be fixed at setup time and inputs are not authenticated. Using homomorphic authenticators allows evaluations of functions on authenticated inputs under a single key (cf. [19] for a recent overview). They are dynamic with respect to the authenticated data and the evaluated function, and also efficient for interesting classes of functions. Evaluating results is typically not more efficient than computing the function (unless using an amortized setting [8, 21]). Yet, they provide benefits when saving bandwidth is an issue and/or the inputs need to be hidden from evaluators (cf. [22, 32]). Computing on data authenticated under different keys using so called multi-key homomorphic authenticators [25, 26, 33], has only very recently been considered. Even though they are somewhat related, they are no replacement for what we are proposing in this paper.

Aggregator-Oblivious Encryption (AOE). AOE [45, 46] considers data provided by multiple producers, which is aggregated by a semi-honest aggregator. The aggregator does not learn the single inputs but only the final result. Follow-up work [10, 31, 34] improved this approach in various directions. Furthermore, [23] introduced a method to achieve fault tolerance, being applicable to all previous schemes. There are also other lines of work on data aggregation, e.g., [18, 29, 36, 37]. Very recently, [35] combined AOE with homomorphic tags to additionally provide verifiability of the aggregated results. Here, every user has a tag key and the aggregator additionally aggregates the tags. Verification can be done under a pre-distributed combined fixed tag key. Their approach is limited to a single function (the sum) and requires a shared secret key-setting, which can be problematic.

In all previous approaches it is impossible to hide the outputs (i.e., the aggregation results) from the aggregator. In contrast to only hiding the inputs, we additionally want to hide the outputs. In addition, we do not want to assume a trusted distribution of the keys, but every sender should authenticate and encrypt under his own key and the aggregator can then perform re-operations (without any secret key) to the receiver.

2 Preliminaries

Unless stated otherwise, all algorithms run in polynomial time and return a special symbol \(\bot \) on error. By \(y\leftarrow \mathcal{A}(x)\), we denote that y is assigned the output of the potentially probabilistic algorithm \(\mathcal{A}\) on input x and fresh random coins (we may also use sans serif font to denote algorithms). Similarly, means that y is assigned a uniformly random value from a set S. If a and b are strings, \(a\Vert b\) is the concatenated string and \(\vec {a}\Vert b\) means extending the vector \(\vec {a}\) with element b. For a sequence of vectors \((\vec {v}_i)_{i\in [n]}\) of length \(\ell \), we use \(f((\vec {v}_i)_{i\in [n]})\) to denote the element-wise application of the function f, i.e., . We let and let \(\Pr [\varOmega : E]\) denote the probability of an event E over the probability space \(\varOmega \). 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}\). A polynomial function is denoted by \(\mathsf{poly}(\cdot )\).

Let \(\mathbb {G}_1 = \langle g \rangle \), \(\mathbb {G}_2 = \langle \hat{g} \rangle \), and \(\mathbb {G}_T\) be cyclic groups of prime order q. A paring \(e: \mathbb {G}_1 \times \mathbb {G}_2 \rightarrow \mathbb {G}_T\) is an efficiently computable, bilinear, non-degenerate map. For simplicity we present our results in the (symmetric) Type-1 setting where \(\mathbb {G}_1 = \mathbb {G}_2\). We stress that there are tools [1, 3] to automatically translate them to the more efficient (asymmetric) Type-3 setting. Henceforth we use \(\mathsf{BG}\) to denote a description of a bilinear group and use boldface letters to denote elements in \(\mathbb {G}_T\). We formally define bilinear group generation and the required computational hardness assumptions in the full version.

Linearly Homomorphic MACs. Our definition is inspired by [2] and covers homomorphic MACs for the family of linear function classes \(\{\mathcal{F}_\mathsf {pp}^\mathsf{lin}\}\), further referred to as HOM-MAC.

Definition 1

(HOM-MAC). A HOM-MAC is a tuple \((\mathcal{P}, \mathcal{G},\mathcal{S},\mathcal{C},\mathcal{V})\) of algorithms defined as:

  • \(\mathcal{P}(\kappa , \ell )\! :\) Takes a security parameter \(\kappa \) and an upper bound \(\ell \) on the vector length as input and outputs public parameters \(\mathsf {pp}\), determining the message space \(\mathcal{M}^\ell \), function class \(\mathcal{F}_\mathsf {pp}^\mathsf{lin}\) containing functions \(f : (\mathcal{M}^\ell )^n \rightarrow \mathcal{M}^\ell \), as well as a tag space being exponentially large in \(\kappa \), where \(\ell ,n \le \mathsf{poly}(\kappa )\).

  • \(\mathcal{G}(\mathsf {pp})\! :\) Takes the public parameters \(\mathsf {pp}\) as input and outputs a secret key \(\mathsf {sk}\).

  • \(\mathcal{S}(\mathsf {sk}, \vec {v}, \mathsf {id}, \tau )\! :\) Takes a MAC key \(\mathsf {sk}\), a vector \(\vec {v}\), an identifier \(\mathsf {id}\), and a tag \(\tau \) as input, and outputs a MAC \(\mu \).

  • \(\mathcal{C}(\mathsf {pp}, f, (\mu _i)_{i\in [n]})\! :\) Takes public parameters \(\mathsf {pp}\), a function \(f\in \mathcal {F}_\mathsf{lin}\) and a sequence of valid MACs \((\mu _i)_{i\in [n]}\) on vectors \((\vec {v}_i)_{i\in [n]}\) as input, and outputs a MAC \(\mu \) on \(\vec {v} = f((\vec {v}_i)_{i\in [n]})\).

  • \(\mathcal{V}(\mathsf {sk}, \vec {v}, \mu , \tau , (\mathsf{id}_i)_{i\in [n]},f)\! :\) Takes a MAC key \(\mathsf {sk}\), a vector \(\vec {v}\), a MAC \(\mu \), a tag \(\tau \), a sequence of identifiers \((\mathsf{id}_i)_{i\in [n]}\), and a function \(f\in \mathcal {F}_\mathsf{lin}\) as input, and outputs a bit.

A linearly homomorphic MAC is required to be correct and unforgeable. Formal definitions are presented in the full version.

Proxy Re-Encryption. A proxy re-encryption (\(\mathsf {PRE}\)) scheme is an encryption scheme that allows a proxy to transform a message m encrypted under public key \(\mathsf{rpk}_A\) of party A into a ciphertext to m under \(\mathsf{rpk}_B\) for another party B, so that the proxy learns nothing about m. A \(\mathsf {PRE}\) scheme is called non-interactive if party A can produce a re-encryption key from A to B locally by having access to its private key and only B’s public key, collusion-safe if the proxy colluding with either of the parties can not recover the other parties private key, unidirectional if a re-encryption key only allows transformations in one direction (e.g., from A to B), and single-use if one ciphertext can be transformed only once. For our formal definitions, we largely follow [5].

Definition 2

(\(\mathsf {PRE}\)). A \(\mathsf {PRE}\) is a tuple \((\mathcal{P},\mathcal{G}, \vec {\mathcal{E}}, \vec {\mathcal{D}},\mathcal{RG},\mathcal{RE})\) of algorithms, where \(\vec {\mathcal{E}} = (\mathcal{E}^i)_{i\in [2]}\) and \(\vec {\mathcal{D}} = (\mathcal{D}^i)_{i\in [2]}\), which are defined as follows:

  • \(\mathcal{P}(1^\kappa )\! :\) Takes a security parameter \(\kappa \) and outputs parameters \(\mathsf{pp}\).

  • \(\mathcal{G}(\mathsf {pp})\! :\) Takes parameters \(\mathsf {pp}\) and outputs a key pair \((\mathsf{rsk},\mathsf{rpk})\).

  • \(\mathcal{RG}(\mathsf{rsk}_A, \mathsf{rpk}_B)\! :\) Takes a secret key \(\mathsf{rsk}_A\) and a public key \(\mathsf{rpk}_B\) and outputs a re-encryption key \(\mathsf{rk}_{A\rightarrow B}\).

  • \(\mathcal{E}^i(\mathsf{rpk}, m)\! :\) Takes a public key \(\mathsf{rpk}\) and a message m and outputs a ciphertext c.

  • \(\mathcal{RE}(\mathsf{rk}_{A\rightarrow B}, c_{A})\! :\) Takes a re-encryption key \(\mathsf{rk}_{A\rightarrow B}\) and a ciphertext \(c_{A}\) under \(\mathsf{rpk}_A\), and outputs a re-encrypted ciphertext \(c_{B}\) for \(\mathsf{rpk}_B\).

  • \(\mathcal{D}^i(\mathsf{rsk}, c)\! :\) Takes a secret key \(\mathsf{rsk}\) and a ciphertext c, and outputs m.

A \(\mathsf {PRE}\) scheme needs to be correct. This notion requires that for all security parameters \(\kappa \in {\mathbb {N}}\), all honestly generated parameters \(\mathsf {pp}\leftarrow \mathcal{P}(1^\kappa )\), all key pairs \((\mathsf{rsk}_A, \mathsf{rpk}_A) \leftarrow \mathcal{G}(\mathsf {pp})\), \((\mathsf{rsk}_B, \mathsf{rpk}_B) \leftarrow \mathcal{G}(\mathsf {pp})\), all re-encryption keys \(\mathsf{rk}_{A\rightarrow B} \leftarrow \mathcal{RG}(\mathsf{rsk}_A, \mathsf{rpk}_B)\), all messages m it holds with probability one that

$$\begin{aligned} \forall ~i \in [2] ~\exists ~j \in [2]~:~&\mathcal{D}^j(\mathsf{rsk}_A, \mathcal{E}^i(\mathsf{rpk}_A, m)) = m, \text { and }\\ \exists ~i \in [2] ~\exists ~j \in [2]~:~&\mathcal{D}^j(\mathsf{rsk}_B, \mathcal{RE}(\mathsf{rk}_{A\rightarrow B}, \mathcal{E}^i(\mathsf {pk}_A,m))) = m. \end{aligned}$$

Thereby i and j determine the level of the ciphertexts. We will henceforth use the following semantics: first-level ciphertexts (\(\mathcal{E}^1\)) cannot be re-encrypted by a proxy, whereas second-level ciphertexts \((\mathcal{E}^2)\) can be re-encrypted.

In addition, a \(\mathsf {PRE}\) needs to be \(\mathsf{IND}\)-\(\mathsf{CPA}\) secure. We, henceforth, only require a relaxed \(\mathsf{IND}\)-\(\mathsf{CPA}\) notion which we term \(\mathsf{IND}\)-\(\mathsf{CPA}^{-}\). It is clearly implied by the original \(\mathsf{IND}\)-\(\mathsf{CPA}\) notion from [5] (some oracles are omitted and the adversary only gets to see a second-level ciphertext).

Definition 3

(IND-CPA\(^-\)). A \(\mathsf {PRE}\) is IND-CPA\(^-\) secure, if for all PPT adversaries \(\mathcal {A}\) there is a negligible function \(\varepsilon (\cdot )\) such that

figure a

We remark that \(\mathcal{RG}\) as defined in [5] also takes the target secret key to cover interactive schemes. As we only deal with non-interactive ones, we omit it.

3 Homomorphic Proxy Re-Authenticators

We introduce homomorphic proxy re-authenticators (\(\mathsf {HPRA}\)s) and rigorously formalize a suitable security model. Our goal is to obtain a flexible framework with various possible instantiations. Accordingly, our definitions are rather generic. We stress that both the source and receiver re-key generation, besides the secret key of the executing party, only require public inputs, i.e., are non-interactive.

Definition 4

(\(\mathsf {HPRA}\)). A homomorphic proxy re-authenticator \((\mathsf {HPRA})\) for a family of function classes \(\{\mathcal{F}_{\mathsf {pp}}\}\) is a tuple of PPT algorithms \((\mathsf{Gen},\mathsf{SGen}, \mathsf{VGen},\mathsf{Sign}, \mathsf{Verify}, \mathsf{SRGen},\mathsf{VRGen}, \mathsf{Agg},\mathsf{AVerify})\), where \(\mathsf{Verify}\) is optional. They are defined as follows:

  • \(\mathsf{Gen}(1^\kappa , \ell )\! :\) Takes security parameter \(\kappa \) and vector length \(\ell \) and outputs parameters \(\mathsf {pp}\), determining the message space \(\mathcal{M}^\ell \), function class \(\mathcal{F}_\mathsf {pp}\) containing functions \(f : (\mathcal{M}^\ell )^n \rightarrow \mathcal{M}^\ell \), as well as a tag space being exponentially large in \(\kappa \), where \(\ell ,n \le \mathsf{poly}(\kappa )\).

  • \(\mathsf{SGen}(\mathsf {pp})\! :\) Takes parameters \(\mathsf {pp}\) as input, and outputs a signer key \((\mathsf {id},\mathsf {sk},\mathsf {pk})\).

  • \(\mathsf{VGen}(\mathsf {pp})\! :\) Takes parameters \(\mathsf {pp}\), and outputs a MAC key \(\mathsf {mk}\) and auxiliary information \(\mathsf {aux}\).

  • \(\mathsf{Sign}(\mathsf {sk}, \vec {m}, \tau )\! :\) Takes a signer secret key \(\mathsf {sk}\), a message vector \(\vec {m}\), and a tag \(\tau \) as input, and outputs a signature \(\sigma \).

  • \(\mathsf{Verify}(\mathsf {pk}, \vec {m}, \tau , \sigma )\! :\) Takes a signer public key \(\mathsf {pk}\), a message vector \(\vec {m}\), a tag \(\tau \), and a signature \(\sigma \) as input, and outputs a bit b.

  • \(\mathsf{SRGen}(\mathsf {sk}_i, \mathsf {aux})\! :\) Takes a signer secret key \(\mathsf {sk}_i\), some auxiliary information \(\mathsf {aux}\), and outputs a re-encryption key \(\mathsf{rk}_i\).

  • \(\mathsf{VRGen}(\mathsf {pk}_i, \mathsf {mk}, \mathsf{rk}_i)\! :\) Takes a signer public key \(\mathsf {pk}_i\) and a MAC key \(\mathsf {mk}\), as well as a re-encryption key \(\mathsf{rk}_i\) as input, and outputs an aggregation key \(\mathsf {ak}_{i}\).

  • \(\mathsf{Agg}((\mathsf {ak}_{i})_{i\in [n]}, (\sigma _i)_{i\in [n]}, \tau , f)\! :\) Takes n aggregation keys \((\mathsf {ak}_{i})_{i\in [n]}\), n signatures \((\sigma _i)_{i\in [n]}\), a tag \(\tau \), and a function \(f\in \mathcal{F}_\mathsf {pp}\) as input, and outputs an aggregate authenticated message vector \(\varLambda \).

  • \(\mathsf{AVerify}(\mathsf {mk}, \varLambda , \mathsf {ID}, f)\! :\) Takes a MAC key \(\mathsf {mk}\), an aggregate authenticated message vector \(\varLambda \), n identifiers \(\mathsf {ID}= (\mathsf {id}_i)_{i\in [n]}\), and a function \(f\in \mathcal{F}_\mathsf {pp}\). It outputs a message vector and a tag \((\vec {m}, \tau )\) on success and \((\bot ,\bot )\) otherwise.

Security Properties. Below we define the oracles, where the public parameters and the keys generated in the security games are implicitly available to the oracles. While most oracle definitions are fairly easy to comprehend and therefore not explicitly explained, we note that the \(\mathsf{RoS}\) oracle is used to model the requirement that signatures do not leak the signed data in a real-or-random style. The environment maintains the initially empty sets \(\mathtt {HU}\) and \(\mathtt {CU}\) of honest and corrupted users (\(\mathtt {CU}\) is only set in the output privacy game). Further, it maintains the initially empty sets \(\mathtt {S}\), \(\mathtt {RK}\) and \(\mathtt {AK}\) of signer, re-encryption and aggregation keys, and an initially empty set \(\mathtt {SIG}\) of message-identity pairs.

 

\(\mathsf{SG}(i)\! :\):

If \(\mathtt {S}[i] \ne \bot \) return \(\bot \). Otherwise run \((\mathsf {id}_i, \mathsf {sk}_i,\mathsf {pk}_i) \leftarrow \mathsf{SGen}(\mathsf {pp})\), set \(\mathtt {S}[i] \leftarrow (\mathsf {id}_i, \mathsf {sk}_i, \mathsf {pk}_i)\), and, if \(i\notin \mathtt {CU}\) set \(\mathtt {HU}\leftarrow \mathtt {HU}\cup \{i\}\). Return \((\mathsf {id}_i, \mathsf {pk}_i)\).

\(\mathsf{SKey}(i)\! :\):

If \(i \notin \mathtt {HU}\) return \(\bot \). Otherwise return \(\mathtt {S}[i]\).

\(\mathsf{Sig}((j_i)_{i\in [n]}, (\vec {m_i})_{i\in [n]})\! :\):

If \(\mathtt {S}[j_i] = \bot \) for any \(i\in [n]\), or there exists \(u,v\in [n], u\ne v\) so that \(j_{u} = j_{v}\), return \(\bot \). Otherwise sample a random tag \(\tau \) and compute \((\sigma _{j_i} \leftarrow \mathsf{Sign}(\mathtt {S}[j_i][2], \vec {m}_i, \tau ))_{i\in [n]}\), set \(\mathtt {SIG}[\tau ] \leftarrow \mathtt {SIG}[\tau ] ~\cup ~ \{(\vec {m}_i, \mathtt {S}[j_i][1])\}\) for \(i \in [n]\), and return \((\sigma _{j_i})_{i\in [n]}\) and \(\tau \).

\(\mathsf{RoS}((j_i)_{i\in [n]}, (\vec {m}_i)_{i\in [n]}, b)\! :\):

If \(\mathtt {S}[j_i] = \bot \) or \(j_i \in \mathtt {CU}\) for any \(i\in [n]\) return \(\bot \). Otherwise sample \(\tau \) uniformly at random and if \(b = 0\) compute \((\sigma _{j_i} \leftarrow \mathsf{Sign}(\mathtt {S}[j_i][2],\vec {m}_i, \tau ))_{i\in [n]}\). Else choose where \(\mathcal M\) is the message space and compute \((\sigma _{j_i} \leftarrow \mathsf{Sign}(\mathtt {S}[j_i][2],\vec {r}_i, \tau ))_{i\in [n]}\). Finally, return \((\sigma _{j_i})_{i\in [n]}\).

\(\mathsf{SR}(i)\! :\):

If \(\mathtt {S}[i] = \bot ~\vee ~ \mathtt {RK}[i] \ne \bot \) return \(\bot \). Else, set \(\mathtt {RK}[i] \leftarrow \mathsf{SRGen}(\mathtt {S}[i][2],\mathsf {aux})\) and return \(\mathtt {RK}[i]\).

\(\mathsf{VR}(i)\! :\):

If \(\mathtt {S}[i] = \bot ~\vee ~ \mathtt {RK}[i] = \bot ~\vee ~ \mathtt {AK}[i] \ne \bot \) return \(\bot \). Else, set \(\mathtt {AK}[i] \leftarrow \mathsf{VRGen}(\mathtt {S}[i][3],\mathsf {mk}, \mathtt {RK}[i])\).

\(\mathsf{VRKey}(i)\! :\):

Return \(\mathtt {AK}[i]\).

\(\mathsf{A}((\sigma _{j_i})_{i\in [n]}, (j_i)_{i\in [n]}, \tau , f)\! :\):

Check validity of all \(\sigma _{j_i}\), whether \(f \in \mathcal {F}_\mathsf {pp}\), whether \(\mathtt {SIG}[\tau ] = \bot \), and return \(\bot \) if any check fails. Further, check whether there exists \(u,v\in [n], u\ne v\) so that \(j_{u} = j_{v}\) and return \(\bot \) if so. Obtain \((\mathsf {ak}_{j_i})_{i\in [n]}\) from \(\mathtt {AK}\) and return \(\bot \) if \(\mathtt {AK}[j_i] = \bot \) for any \(i \in [n]\). Set \(\mathtt {SIG}[\tau ] \leftarrow \bigcup _{i\in [n]}\{(\vec {m}_{j_i},\mathtt {S}[j_i][1])\}\) and return \(\varLambda \leftarrow \mathsf{Agg}((\mathsf {ak}_{j_i})_{i\in [n]},(\sigma _{j_i})_{i\in [n]},\tau , f)\).

 

We require a \(\mathsf {HPRA}\) to be correct, signer unforgeable, aggregator unforgeable, and input private. We formally define those notions below. Intuitively, correctness requires that everything works as intended if everyone behaves honestly.

Definition 5

(Correctness). A \(\mathsf {HPRA}\) for a family of function classes \(\{\mathcal{F}_\mathsf {pp}\}\) is correct, if for all \(\kappa \), for all \(\ell \le \mathsf{poly}(\kappa )\), for all \(\mathsf {pp}\leftarrow \mathsf{Gen}(1^\kappa , \ell )\) determining \(\mathcal{F}_\mathsf {pp}\), for all \(n \le \mathsf{poly}(\kappa )\), for all \(((\mathsf {id}_i, \mathsf {sk}_i, \mathsf {pk}_i) \leftarrow \mathsf{SGen}(\mathsf {pp}))_{i \in [n]}\), for all \((\mathsf {mk}, \mathsf {aux}) \leftarrow \mathsf{VGen}(\mathsf {pp})\), for all \((\vec {m}_i)_{i\in [n]}\), for all \(\tau \), for all \((\sigma _i \leftarrow \mathsf{Sign}(\mathsf {sk}_i, \vec {m}_i, \tau ))_{i\in [n]}\), for all \((\mathsf {ak}_i \leftarrow \mathsf{VRGen}(\mathsf {pk}_i, \mathsf {mk}, \mathsf{SRGen}(\mathsf {sk}_i, \mathsf {aux})))_{i \in [n]}\), for all \(f\in \mathcal{F}_\mathsf {pp}\), for all \(\varLambda ^{\scriptscriptstyle \star } \leftarrow \mathsf{Agg}((\mathsf {ak}_i)_{i\in [n]}, (\sigma _i)_{i \in [n]}, \tau , f)\) it holds that \((\mathsf{Verify}(\mathsf {pk}_i, \vec {m}_i, \tau , \sigma _i) = 1)_{i\in [n]}\) and that \(\mathsf{AVerify}(\mathsf {mk}, \varLambda ^{\scriptscriptstyle \star }, \mathsf {ID}, f) = 1\), where we sometimes omit to make the domains of the values over which we quantify explicit for brevity.

Signer unforgeability requires that, as long as the aggregator remains honest, no coalition of dishonest signers can produce a valid aggregate authenticated message vector \(\varLambda \) with respect to function \(f\in \mathcal{F}_\mathsf {pp}\) so that \(\varLambda \) is outside of the range of f evaluated on arbitrary combinations of actually signed vectors. Aggregator unforgeability is the natural counterpart of signer unforgeability, where the aggregator is dishonest while the signers are honest.Footnote 2

Definition 6

(T-Unforgeability). Let \(\mathsf{T} \in \{\text {Signer}, \text {Aggregator}\}\). A \(\mathsf {HPRA}\) for family of function classes \(\{\mathcal{F}_\mathsf {pp}\}\) is T-unforgeable, if for all PPT adversaries \(\mathcal {A}\) there is a negligible function \(\epsilon (\cdot )\) such that

$$\textstyle \Pr \left[ \begin{array}{l} \mathsf {pp}\leftarrow \mathsf{Gen}(1^\kappa , \ell ),\\ (\mathsf {mk}, \mathsf {aux}) \leftarrow \mathsf{VGen}(\mathsf {pp}),\\ (\varLambda ^{\scriptscriptstyle \star }, \mathsf {ID}^{\scriptscriptstyle \star }, f^{\scriptscriptstyle \star }) \leftarrow \mathcal {A}^{\mathcal {O}_\mathsf{T}}(\mathsf {pp}, \mathsf {aux}),\\ (\vec {m}, \tau ) \leftarrow \mathsf{AVerify}(\mathsf {mk}, \varLambda ^{\scriptscriptstyle \star }, \mathsf {ID}^{\scriptscriptstyle \star }, f^{\scriptscriptstyle \star }) \end{array}: \begin{array}{r} \vec {m} \ne \bot ~\wedge ~ f^{\scriptscriptstyle \star } \in \mathcal {F}_\mathsf {pp}~\wedge \\ 0 < n, \ell \le \mathsf{poly}(\kappa ) ~\wedge \\ \big (\not \exists ~ (\vec {m}_j)_{j \in [n]} : (\forall ~j \in [n] :\\ (\vec {m}_j, \mathsf {id}^{\scriptscriptstyle \star }_j) \in \mathtt {SIG}[\tau ]) ~\wedge \\ f^{\scriptscriptstyle \star }((\vec {m}_j)_{j \in [n]}) = \vec {m}\big ) \end{array} \right] \le \varepsilon (\kappa ), $$

where for \(\mathsf{T} = \text {Signer}\) and \(\mathcal {O}_\mathsf{T} := \{\mathsf{SG}(\cdot ), \mathsf{Sig}(\cdot , \cdot ),\mathsf{SR}(\cdot ), \mathsf{VR}(\cdot ), \mathsf{VRKey}(\cdot ) \}\) for \(\mathsf{T} = \text {Aggregator}\).

Input privacy captures the requirement that an aggregate authenticated message vector does not leak more about the inputs to f as the evaluation result and the description of f would leak on their own.

Definition 7

(Input Privacy). A \(\mathsf {HPRA}\) for a family of function classes \(\{\mathcal{F}_\mathsf {pp}\}\) is input private if for all \(\kappa \in {\mathbb {N}}\), for all \(\ell \le \mathsf{poly}(\kappa )\), for all \(\mathsf {pp}\leftarrow \mathsf{Gen}(1^\kappa ,\ell )\) determining \(\mathcal{F}_\mathsf {pp}\), for all \(f \in \mathcal{F}_\mathsf {pp}\) implicitly defining n, for all tags \(\tau \), and for all \((\vec {m}_{11}, \dots , \vec {m}_{n1})\) and \((\vec {m}_{12}, \dots , \vec {m}_{n2})\) where \(f(\vec {m}_{11}, \dots , \vec {m}_{n1}) = f( \vec {m}_{12}, \dots , \vec {m}_{n2})\), for all \((\mathsf {mk}, \mathsf {aux}) \leftarrow \mathsf{VGen}(\mathsf {pp})\), for all \(((\mathsf {sk}_i, \mathsf {pk}_i) \leftarrow \mathsf{SGen}(\mathsf {pp}))_{i\in [n]}, (\mathsf {ak}_i \leftarrow \mathsf{SRGen}(\mathsf {sk}_i, \mathsf {aux},\mathsf{VRGen}(\mathsf {pk}_i, \mathsf {mk})))_{i\in [n]}\), the following distributions are identical:

$$\begin{aligned} \{\mathsf{Agg}((\mathsf {ak}_i)_{i\in [n]}, (\mathsf{Sign}(\mathsf {sk}_i, \vec {m}_{i1}, \tau ))_{i\in [n]}, \tau , f)\}&,\\ \{\mathsf{Agg}((\mathsf {ak}_i)_{i\in [n]}, (\mathsf{Sign}(\mathsf {sk}_i, \vec {m}_{i2}, \tau ))_{i\in [n]}, \tau , f)\}&. \end{aligned}$$

Additionally, a \(\mathsf {HPRA}\) may provide output privacy. It models that the aggregator neither learns the inputs nor the result of the evaluation of f.

Definition 8

(Output Privacy). A \(\mathsf {HPRA}\) for a family of function classes \(\{\mathcal{F}_\mathsf {pp}\}\) is output private, if for all PPT adversaries \(\mathcal {A}\) there is a negligible function \(\epsilon (\cdot )\) such that:

figure b

4 An Input Private Scheme for Linear Functions

Now we present our first \(\mathsf {HPRA}\) for the family of linear function classes \(\{\mathcal{F}_\mathsf {pp}^\mathsf{lin}\}\). The main challenge we face is to construct a signature scheme with an associated HOM-MAC scheme, where the translation of the signatures under one key to a MAC under some other key works out. Since we believe that our HOM-MAC may as well be useful in other settings we present it as a standalone building block and then proceed with our full construction, where HOM-MAC is used as a submodule. Both build upon the ideas used in the signature scheme presented in [13].

A Suitable Linearly Homomorphic MAC. We present our HOM-MAC in Scheme 1. We can not recycle the security arguments from [13] as we require the ability to submit arbitrary tags \(\tau \) to the \(\mathsf{Sig}\) oracle. Thus we directly prove unforgeability.

Scheme 1.
scheme 1

Linearly homomorphic MAC based on [13].

Full size image

Lemma 1

(Proven in the full version). If the bilinear \(\mathsf{DDH}\) \((\mathsf{BDDH})\) assumption holds, then Scheme 1 is an unforgeable HOM-MAC in the ROM.

Our Input Private Construction. In Scheme 2 we present our \(\mathsf {HPRA}\) construction for the family of linear function classes \(\{\mathcal{F}_\mathsf {pp}^\mathsf{lin}\}\). It allows to authenticate vectors of length \(\ell \), so that the same function can be evaluated per vector component. In our application scenario we have \(\ell = 1\). We allow one to parametrize our construction with an algorithm \(\mathsf{Eval}(\cdot , \cdot )\), which defines how to compute \(f\in \mathcal{F}_\mathsf {pp}^\mathsf{lin}\) on the message vector. When directly instantiating Scheme 2, \(\mathsf{Eval}\) is defined as .

Scheme 2.
scheme 2

\(\mathsf {HPRA}\) scheme for the family of linear function families \(\{\mathcal{F}_\mathsf {pp}^\mathsf{lin}\}\) parametrized by \(\mathsf{Eval}\).

Full size image

Theorem 1

(Proven in the full version). If HOM-MAC in Scheme 1 is unforgeable and the \(\mathsf {eBCDH}\) assumption holds, then Scheme 2 represents a signer unforgeable, aggregator unforgeable and input private \(\mathsf {HPRA}\) for the family of linear function classes \(\{\mathcal{F}_\mathsf {pp}^\mathsf{lin}\}\) in the ROM.

5 Adding Output Privacy

An additional goal is that the aggregator neither learns the input nor the output (output privacy). On our way to achieve this, we formally define the notion of homomorphic proxy-re encryption (\(\mathsf {HPRE}\)) and develop an instantiation for the family of linear function classes \(\{\mathcal{F}_\mathsf {pp}^\mathsf{lin}\}\). Based on this, we extend Scheme 2 to additionally provide output privacy.

5.1 Homomorphic Proxy Re-Encryption

A homomorphic proxy re-encryption scheme (\(\mathsf {HPRE}\)) is a \(\mathsf {PRE}\) which additionally allows the homomorphic evaluation of functions on the ciphertexts. This functionality firstly allows to aggregate messages encrypted under the same public key, and, secondly, to transform the ciphertext holding the evaluation of a function to a ciphertext for another entity, when given the respective proxy re-encryption key. We stress that if the initial ciphertexts are with respect to different public keys, then one can use the respective re-encryption keys to transform them to a common public key before evaluating the function. More formally:

Definition 9

(\(\mathsf {HPRE}\)). A \(\mathsf {HPRE}\) for the family of function classes \(\{\mathcal{F}_\mathsf {pp}\}\) is a \(\mathsf {PRE}\) with an additional evaluation algorithm \(\mathcal{EV}\).

  • \(\mathcal{EV}(\mathsf {pp}, f,\vec {c})\! :\) This algorithm takes public parameters \(\mathsf {pp}\), a function \(f \in \mathcal{F}_\mathsf {pp}\), and a vector of ciphertexts \(\vec {c}=(c_i)_{i\in [n]}\) to messages \((m_i)_{i\in [n]}\) all under public key \(\mathsf {pk}\), and outputs a ciphertext c to message \(f((m_i)_{i\in [n]})\) under \(\mathsf {pk}\).

Additionally, we require the following compactness notion (analogous to [20]).

Definition 10

(Compactness). A \(\mathsf {HPRE}\) for the family of function classes \(\{\mathcal{F}_\mathsf {pp}\}\) is called compact if for all \(\mathsf {pp}\leftarrow \mathcal{P}(1^\kappa )\) and for all \(f \in \mathcal{F}_\mathsf {pp}\) the running time of the algorithms \(\vec {\mathcal{D}}\) is bounded by a fixed polynomial in the security parameter \(\kappa \).

Besides the straightforward adoption of correctness, \(\mathsf{IND}\)-\(\mathsf{CPA}^{-}\) remains identical (\(\mathcal{EV}\) is a public algorithm). However, we require an \(\mathsf{IND}\)-\(\mathsf{CPA}^{-}\) variant, where the adversary may adaptively choose the targeted user. To the best of our knowledge, such a notion does not exist for \(\mathsf {PRE}\). We introduce such a notion (termed mt-IND-CPA\(^{-}\)) and show that it is implied by the conventional \(\mathsf{IND}\)-\(\mathsf{CPA}\) notions.

Definition 11

(mt-IND-CPA\(^-\)). A \((\mathsf{H})\mathsf {PRE}\) is mt-IND-CPA\(^-\) secure, if for all PPT adversaries \(\mathcal {A}\) there is a negligible function \(\varepsilon (\cdot )\) such that

figure c

where the environment holds an initially empty list \(\mathtt {HU}\). \(\mathsf{G}\) and \(\mathsf{RG}\) are defined as:

  • \(\mathsf{G}(i)\! :\) If \(\mathtt {HU}[i] \ne \bot \) return \(\bot \). Otherwise, run \((\mathsf {sk}_i, \mathsf {pk}_i) \leftarrow \mathcal{G}(\mathsf {pp})\), set \(\mathtt {HU}[i] \leftarrow (\mathsf {sk}_i, \mathsf {pk}_i)\), and return \(\mathsf {pk}_i\).

  • \(\mathsf{RG}(i)\! :\) If \(\mathtt {HU}[i] = \bot \) return \(\bot \). Otherwise, set \(\mathsf{rk}_{i \rightarrow h} \leftarrow \mathcal{RG}(\mathtt {HU}[i][1],\mathsf {pk}_h)\) and return \(\mathsf{rk}_{i \rightarrow j}\).

Lemma 2

(proven in the full version). Every \(\mathsf{IND}\)-\(\mathsf{CPA}^{-}\) (and thus every \(\mathsf{IND}\)-\(\mathsf{CPA}\)) secure \(\mathsf{PRE}\) also satisfies \(\mathsf{mt}\)- \(\mathsf{IND}\)-\(\mathsf{CPA}^{-}\) security.

\(\mathsf {HPRE}\)Construction for the Family of Linear Function Classes. We state our construction in Scheme 3. Essentially, we build upon the \(\mathsf {PRE}\) scheme in [5, third attempt] and turn it into a \(\mathsf {HPRE}\) for the family of linear function classes \(\{\mathcal{F}_\mathsf {pp}^\mathsf{lin}\}\), henceforth referred to as \(\mathsf {HPRE}_\mathsf{lin}\). For the desired homomorphism we use a standard trick in the context of ElGamal-like encryption schemes: we encode messages \(m \in {\mathbb {Z}}_q\) into the exponent and encrypt \(\mathbf{g}^m\). Decryption then yields \(m'=\mathbf{g}^m\) and one additionally needs to compute \(m=\log _\mathbf{g} m'\) to obtain m. Thus, for the schemes to remain efficient, the size of the message space needs to be polynomial in the security parameter. While this might sound quite restrictive, we stress that in practical settings one deals with numerical values where messages in the order of millions to billions are by far sufficient. Thus, this type of decryption is not a limitation and entirely practical.

Scheme 3.
scheme 3

\(\mathsf {HPRE}_\mathsf{lin}\) based on [5, third attempt].

Full size image

As \(\mathcal {EV}\) is a public algorithm it does not influence \(\mathsf{IND}\)-\(\mathsf{CPA}\) security. Thus, our argumentation is identical to [5] and we can use the following theorem.

Theorem 2

(cf. [5]). If the \(\mathsf{eDBDH}\) assumption holds in \((\mathbb {G},\mathbb {G}_T)\) then Scheme 3 is an \(\mathsf{IND}\)-\(\mathsf{CPA}\) secure \(\mathsf {HPRE}_\mathsf{lin}\).

We note that compactness of Scheme 3 (Definition 10) is easy to verify.

\(\mathsf {HPRE}_\mathsf{lin}\)for Vectors. We extend \(\mathsf {HPRE}_\mathsf{lin}\) to vectors over \({\mathbb {Z}}_q\), while preserving the support for re-encryption and the homomorphic properties. It turns out that we can employ a communication efficient solution. That is, borrowing the idea of randomness re-use from [9] and applying it to \(\mathsf {HPRE}_\mathsf{lin}\), we can reduce the size of the ciphertexts as long as no re-encryption is performed. Upon setup, we have to fix a maximal length \(\ell \) of the message vectors. The secret and the public keys are then of the form \(\mathsf{rsk}\leftarrow (\mathsf{rsk}_i)_{i\in [\ell ]} = (( a_{1i}, a_{2i}))_{i \in [\ell ]}\), \(\mathsf{rpk}\leftarrow (\mathsf{rpk}_i)_{i\in [\ell ]} = ((\mathbf{g}^{a_{1i}}, g^{a_{2i}}))_{i \in [\ell ]}\), where . First and second level encryption are defined as

figure d

Decryption \(\mathcal{D}^j_\ell (\cdot , \cdot )\) of a ciphertext \((c[1], (c[i+1])_{i \in [\ell ]}, j)\) is defined as , and . Re-encryption key generation is . From a second level ciphertext \(\vec {c}_A\) for A and a re-encryption key \(\mathsf{rk}_{A\rightarrow B}\), one can compute a ciphertext \(\vec {c}_B\) for B as Note that re-encrypted ciphertexts have a different form. Thus we do not need to add the level as suffix. Decryption \(\mathcal{D}_\ell ^1(\cdot , \cdot )\) for re-encrypted ciphertexts is .

Theorem 3

If the \(\mathsf{eDBDH}\) assumption holds, then the extension of \(\mathsf {HPRE}_\mathsf{lin}\) as described above, yields an \(\mathsf{IND}\)- \(\mathsf{CPA}\) secure \(\mathsf {HPRE}_\mathsf{lin}\) for vectors.

Proof

(sketch). \(\mathsf{IND}\)-\(\mathsf{CPA}\) security of the original scheme implies Theorem 3 under a polynomial loss: using \(\ell \) hybrids, where in hybrid i (\(1 \le i \le \ell \)) the i-th ciphertext component is exchanged by random under the original strategy in [5].

Combining the theorem above with Lemma 2 yields:

Corollary 1

The extension of \(\mathsf {HPRE}_\mathsf{lin}\) as described above yields an \(\mathsf{mt}\)-\(\mathsf{IND}\)-\(\mathsf{CPA}^{-}\) secure \(\mathsf {HPRE}_\mathsf{lin}\) for vectors.

5.2 Putting the Pieces Together: Output Privacy

Our idea is to combine Scheme 2 with the \(\mathsf {HPRE}_\mathsf{lin}\) presented above. In doing so, we face some obstacles. First, a naïve combination of those primitives does not suit our needs: one can still verify guesses for signed messages using solely the signatures, since signatures are publicly verifiable. Second, switching to a MAC for the data sources is also no option, as this would require an interactive re-key generation. This is excluded by our model as we explicitly want to avoid it. Thus, we pursue a different direction and turn the signatures used in Scheme 2 into a MAC-like primitive by blinding a signature with a random element \(g^r\). An aggregated MAC holding an evaluation of f is then blinded by \(g^{f(\ldots ,r,\ldots )}\), i.e., the receiver needs to evaluate the function f on the all blinding values from the single sources. Now the question arises as how to transmit the blinding values to the receiver. Using our \(\mathsf {HPRE}_\mathsf{lin}\) for vectors yields an arguably elegant solution: by treating the randomness as an additional vector component, we can use the re-encryption features of the \(\mathsf {HPRE}_\mathsf{lin}\). More importantly, by executing the \(\mathcal EV\) algorithm the aggregator simultaneously evaluates the function f on the data and on the randomness so that the receiver can directly obtain the blinding value \(f(\ldots ,r,\ldots )\) upon decryption.

Scheme 4.
scheme 4

Output private \(\mathsf {HPRA}\) scheme for the family of linear function classes \(\{\mathcal{F}_{\mathsf {pp}}^\mathsf{lin}\}\) with \(\mathcal{F}_\mathsf{lin}\) with \(\mathsf {Eval}(\cdot , \cdot ) := \mathcal{EV}(\mathsf {pp}, \cdot , \cdot )\)

Full size image

Note on the Instantiation. Augmenting Scheme 2 to obtain Scheme 4 using \(\mathsf {HPRE}_\mathsf{lin}\) requires an alternative decryption strategy for the vector component containing r, as r is uniformly random in \({\mathbb {Z}}_q\) and can thus not be efficiently recovered. Fortunately, obtaining \(r\in {\mathbb {Z}}_q\) is not required, as \(g^r\) (resp. \(\mathbf{g}^r\)) is sufficient to unblind the signature (resp. MAC). Those values are efficiently recoverable.

Theorem 4

(proven in the full version). If Scheme 2 is signer and aggregator unforgeable, and \(\mathsf {HPRE}_\mathsf{lin}\) for vectors is \(\mathsf{mt}\)-\(\mathsf{IND}\)-\(\mathsf{CPA}^{-}\) secure, then Scheme 4 is a signer and aggregator unforgeable, input and output private \(\mathsf {HPRA}\) for class \(\mathcal{F}_\mathsf{lin}\).

6 Conclusion

In this paper we introduce the notion of homomorphic proxy re-authenticators. This concept covers various important issues in the multi-user data aggregation setting not considered by previous works. We present two provably secure and practically efficient instantiations of our novel concept, which differ regarding the strength of the privacy guarantees. Our schemes are modular in the sense that they are constructed from building blocks which may as well be useful in other settings. One important building block is the concept of homomorphic proxy re-encryption, which we also introduce and construct in this paper.