Keywords

1 Introduction

Considering recent legistlative initiatives [14], we may be soon storing many verifiable credentials about our sensitive attributes in our smartphones, supported by electronic wallet applications, streamlining the procurement and presentation of these credentials. By themselves, smartphones cannot provide sufficient confidentiality for these credentials. Rather, we expect to store them in some encrypted form, decrypted only while they are in use. The decryption keys are stored inside a Secure Element [22], a tamper-resistant piece of hardware contained in the phone. Hence we have to trust the producers of Secure Elements, and abstain from the use of e-Wallets (with credentials containing sensitive information) on phones without Secure Elements. This is not a desirable situation. We would like to replace trusted hardware with something that has weaker trust requirements, e.g. threshold cryptography.

Common constructions of primitives of threshold cryptography and their security definitions are difficult to map to a setting where some keyshares are stored and operations performed on platforms with weak security protections. We have proposed a server-supported signature scheme [7], where the signing key was shared between a phone and a server, and the keyshare in the phone was protected only by symmetrically encrypting it with a key with very low entropy (derived from a PIN that the user can remember). The security of our scheme was based on the infeasibility of offline guessing attacks by someone who has obtained the encrypted keyshare of the phone, and by the ability of the server to recognize online guessing attacks. The latter property allows the server to count wrong guesses, and a clone detection mechanism [19] allows to reset the counter.

In this paper, we propose an encryption scheme with similar properties, i.e. it has distributed decryption, where offline guesses by someone masquerading as the phone are impossible, and wrong guesses made online are detected by the server. We want the phone to initiate the decryption, and the server to learn nothing about the decrypted plaintext. We give a formalization of these properties. Combined with the clone detection mechanism, our scheme could be used as an alternative to Secure Elements, at least when the requirement for online connectivity during decryption is acceptable.

Related Work. Our encryption scheme is motivated by a set of requirements that have previously not been tried to address together. They have been considered in the context of server-supported signature schemes [7], where we attempt to avoid offline guessing attacks [2] and detect online guessing attacks [12]. This is also the case for scheme [8], where the server supports the functionality of a secure construction. It is in contrast to the schemes where a server is employed to reduce the client’s workload in performing computationally expensive operations [1, 4]. It is also in contrast to key-insulated encryption [13], where a mostly offline server is used to reduce the impact of repeatedly breaking a weakly secure device.

Our scheme builds upon threshold encryption schemes. Threshold cryptography has a long history, starting from [11], where a method for threshold creation of RSA signatures was proposed. IND-CCA secure encryption schemes with threshold decryption [21] were proposed shortly after IND-CCA secure asymmetric encryption schemes [10]. At present, threshold cryptography is a mature field, discussed in textbooks [5] and subject to standardization activities [6].

2 Desired Properties of Distributed Decryption

In this paper, we consider asymmetric key encapsulation [18] schemes, where the decapsulation functionality is distributed between two parties—the client, and the server. The roles of these parties are not identical, and the desired security properties for each of them are different.

An encapsulation scheme with client-server decryption consists of the following sets, algorithms, and protocols, parameterized with the security parameter \(\lambda \) and other public parameters (e.g. the definition of the used cyclic groups):

  • Sets of shared secrets \(\textsf{SS}\), ciphertexts \(\textsf{CT}\), public keys \(\textsf{PK}\), client’s private keys \(\textsf{SK}_\textrm{C}\), and server’s private keys \(\textsf{SK}_\textrm{S}\).

  • Key-generation protocol \(\langle \mathcal{K}\mathcal{G}_\textrm{C}|\mathcal{K}\mathcal{G}_\textrm{S}\rangle \), run by both parties. It returns \((\textsf{sk}_1,\textsf{pk})\in \textsf{SK}_\textrm{C}\times \textsf{PK}\) to the client, and \((\textsf{sk}_2,\textsf{pk})\in \textsf{SK}_\textrm{S}\times \textsf{PK}\) to the server.

  • Encapsulation algorithm \(\mathcal {E} nc \). It takes as input a public key \(\textsf{pk}\in \textsf{PK}\), and returns a shared secret \(k\in \textsf{SS}\) and a ciphertext \(c\in \textsf{CT}\).

  • Decapsulation protocol \(\langle \mathcal{D}\mathcal{C}_\textrm{C}|\mathcal{D}\mathcal{C}_\textrm{S}\rangle \), run by the client and the server. Client’s inputs are \(c\in \textsf{CT}\), \(\textsf{sk}_1\in \textsf{SK}_\textrm{C}\), and \(\textsf{pk}\in \textsf{PK}\). Server’s inputs are \(c\in \textsf{CT}\), \(\textsf{sk}_2\in \textsf{SK}_\textrm{S}\) and \(\textsf{pk}\in \textsf{PK}\). The protocol returns either \(k\in \textsf{SS}\) or the failure notice \(\bot \) to the client. It returns success/failure notice \(\top \)/\(\bot \) to the server.

We also define the decapsulation algorithm \(\mathcal {D} ec \), that on inputs \(c,\textsf{sk}_1,\textsf{sk}_2,\textsf{pk}\) invokes \(\langle \mathcal{D}\mathcal{C}_\textrm{C}(c,\textsf{sk}_1,\textsf{pk})|\mathcal{D}\mathcal{C}_\textrm{S}(\textsf{sk}_2,\textsf{pk})\rangle \) and returns client’s output.

In the following, we write to denote that values \(x_1,\ldots ,x_n\) are uniformly, independently sampled from a set X. We also write to denote that x is returned by a stochastic computation \(\textsf{X}\). Given an oracle \(\mathcal {O}(\cdot )\) and a value c, we let \(\textsf{EXCL}_{c}[{\mathcal {O}}]\) denote an oracle that on input \(c^*\) returns \(\bot \) if \(c^*=c\), and \(\mathcal {O}(c^*)\) otherwise. A protocol party executed as an oracle gives the adversary the messages this party produces.

Definition 1 (Correctness)

A encapsulation scheme is correct, if

figure c

The confidentiality properties of the encapsulation scheme are defined in the usual manner. The definitions refer to the experiments in Fig. 1 that follow general definitions of IND-CCA for threshold encryption schemes.

Fig. 1.
figure 1

Security against chosen-ciphertext attacks

Full size image

Definition 2 (IND-CCA against server/client)

The encapsulation scheme provides indistinguishability against the chosen-ciphertext attacks by the server [resp. client], if the experiment IND-CCA-S\({}^\mathcal {A}\) [resp. IND-CCA-C\({}^\mathcal {A}\)] is successful with probability at most negligibly larger than 1/2 for all efficient adversaries \(\mathcal {A}\).

The impossibility of offline guessing and detectability of online guessing is defined below, using the experiment defined in Fig. 2. Here \(\textsf{shuffle}\) returns a list that is a random permutation of its arguments. The list \( SK _1\) corresponds to the list of candidate private keys that an intruder may obtain after extracting the weakly encrypted (e.g. the encryption key has been derived from a PIN) private key from the smartphone, and trying to decrypt it with all possible values of the key. We see that the adversary may start sessions of the server, and may even submit it the challenge ciphertext, but no more than T sessions may finish with \(\bot \) (or not finish at all).

Fig. 2.
figure 2

Security against offline and online guessing

Full size image

Definition 3 (No guessing by client)

The encapsulation scheme provides offline guessing security against chosen-ciphertext attacks by the client, if the experiment OG-CCA-C\({}_{T,L}^\mathcal {A}\) is successful with probability at most negligibly larger than \(1/2+T/L\) for all efficient adversaries \(\mathcal {A}\), and numbers T, L.

Finally, we ask for the integrity of shared secrets, i.e. the client would not accept a secret \(k'\) different from the one output by the encapsulation algorithm.

Definition 4 (Integrity for client)

The encapsulation scheme provides key integrity for the client, if for all efficient adversaries \(\mathcal {A}\),

figure d

3 Building Blocks

Let \(\mathbb {G}\) be a cyclic group of size p, with generator g. The discrete logarithm problem is to find \(n\in \mathbb {Z}_p\), such that \(g^n=h\), for a value . The decisional Diffie-Hellman (DDH) problem is to distinguish tuples of the form \((g,g^x,g^y,g^{xy})\) (called Diffie-Hellman tuples) from tuples of the form \((g,g^x,g^y,g^z)\) for . A problem is hard if all efficient algorithms have at most negligible advantage (over a trivial algorithm) of solving it.

Our schemes build on top of the ElGamal KEM, the IND-CPA security of which is equivalent to the hardness of DDH in the used group \(\mathbb {G}\). In this KEM, private key is a random \(\textsf{sk}\in \mathbb {Z}_p\), while public key is \(\textsf{pk}=g^\textsf{sk}\). The encapsulation algorithm generates , and outputs the shared secret \( ss \leftarrow \textsf{pk}^r\) and ciphertext \(c=g^r\). The decapsulation algorithm computes \( ss =c^\textsf{sk}\). In hashed ElGamal, the shared secret is \(H'(\textsf{pk}^r)\) for some hash function \(H'\) that we model as a random oracle. Note that an input to a random oracle can be anything encodable as a bitstring.

A DDH proof  [9] is a non-interactive [16] zero-knowledge (NIZK) proof that \(\log _g u=\log _h v\), given in context \( ctx \), where \(r\in \mathbb {Z}_p\) is the discrete logarithm and H is a hash function, modeled as a random oracle. It is given by , \(\alpha \leftarrow g^s\), \(\alpha '\leftarrow h^s\), \(\beta \leftarrow H(g,h,u,v,\alpha ,\alpha ', ctx )\in \mathbb {Z}_p\), and \(\gamma \leftarrow s+r\cdot \beta \). The checking procedure recomputes \(\beta \), and checks that \(g^\gamma =\alpha \cdot u^\beta \) and \(h^\gamma =\alpha '\cdot v^\beta \).

In our schemes, similarly to [21], DDH proofs are often used to give simulatable proofs of knowledge of exponent . These prove that someone knows the value \(r=\log _g u\). Additionally, they allow the simulator to raise a value (an element of \(\mathbb {G}\)) of its choice to the power of r; the simulator has to choose that value at the time the adversary computes the proof. The construction makes use of two hash functions, both modeled as random oracles, where H returns elements of \(\mathbb {Z}_p\) and \(\tilde{H}\) returns elements of \(\mathbb {G}\). It is given by first computing \(h\leftarrow \tilde{H}(g,u, ctx )\) and \(v\leftarrow h^{r}\). The proof is \(\pi '=(\pi ,v)\), where . The checking procedure recomputes v and checks the DDH proof. During simulation, if the simulator wants to obtain \(z^{r}\), it will generate , and program \(\tilde{H}\) to return \(z^{1/t}\) when the adversary queries it with \(g,u, ctx \). Then \(z^{r}=v^t\).

4 The Encryption Scheme

Secret-sharing the private key will straightforwardly thresholdize the ElGamal KEM [15]. IND-CCA may be achieved by adding the non-interactive zero-knowledge proof of knowledge (NIZKPoK) of r to the ciphertext. For non-threshold systems, this may be a designated-verifier (DV) NIZKPoK [10], aimed towards the receiver. For general case, Schnorr’s proofs for discrete logarithm [20], made non-interactive through the Fiat-Shamir transform [16] using a random oracle (i.e. Schnorr signatures, using r as the signing key), are typically used to show the knowledge of r, but it is unknown how to combine them with ElGamal KEM in a way that allows IND-CCA to be derived only from the hardness of the DDH problem [3]. The TDH2 (threshold) cryptosystem [21] overcomes this by changing how the random oracle is used by the Fiat-Shamir transform, making certain additional computations possible in the simulation. The scheme \(\textsf{NPS}\) that we present here is quite similar to TDH2. Interestingly, only small changes are needed to make it secure against guessing attacks (Definition 3).

Let \(\mathbb {G}\) be a cyclic group of size p, with generator g, with hard DDH problem. Let \(H_1,H_2,H_3\) be hash functions outputting elements of \(\mathbb {Z}_p\), and \({\tilde{H}}_1, {\tilde{H}}_2\) be hash functions outputting elements of \(\mathbb {G}\), all modeled as random oracles. We put \(\textsf{NPS}.\textsf{SS}=\textsf{NPS}.\textsf{PK}=\mathbb {G}\), \(\textsf{NPS}.\textsf{SK}_\textrm{C}=\mathbb {Z}_p\), and \(\textsf{NPS}.\textsf{SK}_\textrm{S}=\mathbb {Z}_p\times \mathbb {G}^2\). The set \(\textsf{NPS}.\textsf{CT}\) is given together with the algorithm \(\textsf{NPS}.\mathcal {E} nc \) and protocol \(\textsf{NPS}.\mathcal{D}\mathcal{C}_\mathrm {}\) in Fig. 3. In the key-generation protocol, the client generates , and the server generates . They compute \(\textsf{pk}_i\leftarrow g^{\textsf{sk}_i}\), fairly exchange the values \(\textsf{pk}_i\) with each other (using some trapdoor commitment scheme [17]), and define \(\textsf{pk}\leftarrow \textsf{pk}_1\cdot \textsf{pk}_2\). The server stores \(\textsf{pk}_1,\textsf{pk}_2\) together with the private exponent \(\textsf{sk}_2\).

Fig. 3.
figure 3

Encryption and decryption for the scheme \(\textsf{NPS}\)

Full size image

We see that the ciphertext is simply an ElGamal ciphertext, together with a simulatable proof of knowledge of the exponent r. When decrypting, the client first verifies this proof. If an assertion fails, then \(\bot \) is immediately returned. As next, the client asks the server to apply its private key share \(\textsf{sk}_2\) to the ciphertext u. This request includes a Schnorr proof of knowing the private key \(\textsf{sk}_1\), where the challenge depends on the ciphertext; hence this proof cannot be reused. The request also contains the value \(h''\) that allows the simulator to perform an exponentiation with \(\textsf{sk}_1\). The server verifies the Schnorr proofs of knowing both r and \(\textsf{sk}_1\), and then computes \(w\leftarrow u^{\textsf{sk}_2}\). The value w is returned together with a Schnorr proof that it has been correctly computed—that \(\log _u w=\log _g \textsf{pk}_2\). The client verifies this proof, applies its private key share \(\textsf{sk}_1\) to u, and combines the result with the plaintext share w obtained from the server. It is clear that the scheme satisfies Definition 1 and Definition 4 due to the NIZK proofs.

Theorem 1

In ROM, if the DDH problem is hard in group \(\mathbb {G}\), then \(\textsf{NPS}\) provides IND-CCA against the server and the client.

Proof

To show IND-CCA against the server, let \(\mathcal {A}\) be an adversary that has non-negligible advantage in experiment IND-CCA-S\({}^\mathcal {A}\) with the scheme \(\textsf{NPS}\). We construct an algorithm \(\mathcal {S}\) that solves the DDH problem in \(\mathbb {G}\). The algorithm \(\mathcal {S}\) (called “simulator”) internally calls \(\mathcal {A}\), realizing the oracles it accesses, including the random oracle. It receives \((h_1,h_2,h_3)\in \mathbb {G}^3\) as an input, and outputs whether they are a DH tuple. In the experiment, the values \(h_i\) play the following roles: \(\textsf{pk}=h_1\), \(u=h_2\), \(k_b=h_3\). We see that if \((g,h_1,h_2,h_3)\) are [resp. are not] a DH tuple, then \((\textsf{pk},u,k_b)\) are distributed identically to the case \(b=0\) [resp. \(b=1\)].

The internal state of \(\mathcal {S}\) contains the tables \(\mathcal {T}_i,\tilde{\mathcal {T}}_j\) storing the current states of random oracles \(H_i\), \(\tilde{H}_j\). For tables \(\mathcal {T}_i\), a table row contains the argument made to the oracle, and the given response. For \(\tilde{\mathcal {T}}_j\), a table row additionally contains the exponent generated while responding a \(\tilde{H}_j\)-query.

We now describe how \(\mathcal {S}\) behaves in different interactions with \(\mathcal {A}\). For key generation, receive \(\textsf{pk}_2\) (committed and opened) from \(\mathcal {A}\), while sending it a commitment later opened to \(\textsf{pk}_1\leftarrow h_1/\textsf{pk}_2\). For responding a random oracle query (either directly from \(\mathcal {A}\), or from simulating the responses to other queries) \(H_i(x)\), look up the row (x, v) from \(\mathcal {T}_i\), generating and adding the row to the table, if it is not there. Then respond with v. Do the same for \(\tilde{H}_2\)-query (put \(\bot \) as the exponent). Also do the same for query \(\tilde{H}_j(x)\), but if the row (x, v, t) is not yet in \(\tilde{\mathcal {T}}_j\) then generate , define \(v=\textsf{pk}^{1/t}\), add (x, v, t) to \(\tilde{\mathcal {T}}_1\), and return v.

Simulator \(\mathcal {S}\) has to prepare a challenge ciphertext \(c=(u,h',\alpha ,\alpha ',\gamma )\) for \(\mathcal {A}\). We have defined u; the rest is constructed by faking the NIZK proofs: \(\mathcal {S}\) generates , defines \(g'\leftarrow g^s\), \(h'\leftarrow h_2^s\), generates , computes \(\alpha \leftarrow u^\beta /g^\gamma \) and \(\alpha '\leftarrow (h')^\beta /(g')^\gamma \), and adds \(((g',u,h',\alpha ,\alpha '),\beta )\) to \(\mathcal {T}_1\) and \(((u,\alpha ),g',\bot )\) to \(\tilde{\mathcal {T}}_1\). This computation may fail if the added rows are already present in the tables, but this happens with only negligible probability because all arguments contain fresh randomness.

A query from \(\mathcal {A}\) to the \(\mathcal {D} ec \)-oracle with argument \(c^*=(u^*,h^{\prime *},\alpha ^*,\alpha ^{\prime *},\gamma ^*)\) is handled by \(\mathcal {S}\) as follows. First check the proofs, similarly to \(\textsf{NPS}.\mathcal{D}\mathcal{C}_\textrm{C}\). Return \(\bot \), if they fail. Otherwise look up the row \(((u^*,\alpha ^*),g',t)\) in \(\tilde{\mathcal {T}}_1\) and return \((h^{\prime *})^t\). This row has to exist, because the proof-checks look it up. The value t may be missing, but in this case \(c^*\) had to be the challenge ciphertext.

A query from \(\mathcal {A}\) to the \(\mathcal{D}\mathcal{C}_\textrm{C}\)-oracle with the same argument \(c^*\) is handled by \(\mathcal {S}\) as follows. Check the proofs; return \(\bot \) if they fail. Prepare the query to the server, faking the proof of knowledge \(\pi '\) of \(\textsf{sk}_1\). Whenever \(\mathcal {A}\) invokes \(\mathcal{D}\mathcal{C}_\textrm{C}\) for the second round, \(\mathcal {S}\) ignores this query: the server is not expected to get any answer from the client’s second round.

Throughout this construction, all values that \(\mathcal {A}\) sees are distributed identically to the experiment IND-CCA-S\({}^\mathcal {A}\) for \(\textsf{NPS}\). In particular, the responses from the random oracles are uniform and mutually independent. Finally, \(\mathcal {A}\) gives its guess \(b^*\), which \(\mathcal {S}\) outputs. The advantage of \(\mathcal {S}\) is equal to the advantage of \(\mathcal {A}\).

The proof of IND-CCA against client is similar. When the \(\mathcal {A}\) generates the simulatable proof of knowledge of \(\textsf{sk}_1\) (as in \(\mathcal{D}\mathcal{C}_\textrm{C}\)) and invokes \(\tilde{H}_2(g,\textsf{pk}_1,u)\) for that purpose, \(\mathcal {S}\) chooses u as the value it wants to raise to power \(\textsf{sk}_1\). If \(\mathcal {A}\) then invokes the oracle \(\mathcal{D}\mathcal{C}_\textrm{S}\), the simulator \(\mathcal {S}\) can reply with \(w\leftarrow \textsf{pk}^r/u^{\textsf{sk}_1}\).   \(\square \)

Theorem 2

In ROM, if the DDH problem is hard in group \(\mathbb {G}\), then \(\textsf{NPS}\) provides CCA against offline guessing attacks by the client.

Proof

Similarly to the proof of Theorem 1, we assume the existence of an adversary \(\mathcal {A}\) that has advantage at least \(1/2+T/L+\nu \) for a non-negligible \(\nu \) in the experiment OG-CCA-C\({}^\mathcal {A}_{T,L}\) with the scheme \(\textsf{NPS}\), and construct the algorithm \(\mathcal {S}\) that solves the DDH problem in \(\mathbb {G}\). It again gets \((h_1,h_2,h_3)\) as the input, and again uses them as \(\textsf{pk}=h_1\), \(u=h_2\), \(k_b=h_3\).

The internal state of \(\mathcal {S}\) consists of the same tables as in the proof of Theorem 1. For some \(\textsf{h}\in \mathbb {G}\), we additionally define \(\mathcal {T}_2|_\textsf{h}\) as the subset of rows of \(\mathcal {T}_2\) of the form \(((\textsf{h},\alpha _1,c),v)\) (i.e. the first component to the argument of \(H_2\) was \(\textsf{h}\)). The simulator \(\mathcal {S}\) also maintains a set of integers \(\textbf{K}\), initialized to \(\{1,\ldots ,L\}\).

Simulator \(\mathcal {S}\) has to prepare the arguments to \(\mathcal {A}\). The challenge ciphertext \(c=(u,h',\alpha ,\alpha ',\gamma )\) is prepared identically to the proof of Theorem 1. The list of potential private key shares of the client is defined by generating and putting \( SK _1=[\textsf{sk}_1^{(1)},\ldots ,\textsf{sk}_1^{(L)}]\). Note that the inputs to \(\mathcal {A}\) are distributed identically to the experiment OG-CCA-C\({}^\mathcal {A}_{T,L}\) for \(\textsf{NPS}\). Also note that at this point, \(\mathcal {S}\) has not selected the “right” private key share. Define also \(\textsf{pk}_1^{(i)}\leftarrow g^{\textsf{sk}_1^{(i)}}\) for \(i\in \{1,\ldots ,L\}\).

A query from \(\mathcal {A}\) to either one of the hash functions or to the \(\mathcal {D} ec \)-oracle is handled identically to the proof of Theorem 1. Again, all responses to these queries are distributed identically to the actual experiment OG-CCA-C\({}^\mathcal {A}_{T,L}\).

The \(\textbf{t}\)-th query \((c_\textbf{t},\alpha _{1,\textbf{t}},\gamma _{1,\textbf{t}})\) to the \(\mathcal{D}\mathcal{C}_\textrm{S}\)-oracle is handled by \(\mathcal {S}\) as follows. First, verify the proofs in \(c_\textbf{t}=(u_\textbf{t},h'_\textbf{t},\alpha _\textbf{t},\alpha '_\textbf{t},\gamma _\textbf{t})\), corresponding to the assertions in \(\textsf{NPS}.\mathcal{D}\mathcal{C}_\textrm{S}\). Return \(\bot \), if these verifications fail.

The simulator continues with the response for \(\mathcal{D}\mathcal{C}_\textrm{S}\)-oracle as follows. It finds the index \(i\in \{1,\ldots ,L\}\), such that the row \(((\textsf{pk}_1^{(i)},\alpha _{1,\textbf{t}},\gamma _{1,\textbf{t}}),\beta _{1,\textbf{t}})\) is in the table \(\mathcal {T}_2\) for some \(\beta _{1,\textbf{t}}\), and \(g^{\gamma _{1,\textbf{t}}}=\alpha _{1,\textbf{t}}\cdot (\textsf{pk}_1^{(i)})^{\beta _{1,\textbf{t}}}\). If there is no such row, then let \(i=\bot \). The probability of having more than one such row in \(\mathcal {T}_2\) is negligible. Indeed, if i and \(i'\) would both be such indices, then \((\textsf{pk}_1^{(i)})^{\beta _{1,\textbf{t}}}=(\textsf{pk}_1^{(i')})^{\beta '_{1,\textbf{t}}}\). The values \(\beta _{1,\textbf{t}}\) and \(\beta '_{1,\textbf{t}}\) are random, and generated independently from \(\textsf{pk}_1^{(i)}\) and \(\textsf{pk}_1^{(i')}\), hence this equality can hold only with negligible probability.

If \(i\not \in \textbf{K}\), then \(\mathcal {S}\) returns \(\bot \) to \(\mathcal {A}\). If \(i\in \textbf{K}\), then \(\mathcal {S}\) has to decide whether the “right” private key is \(\textsf{sk}_1^{(i)}\). For this purpose, \(\mathcal {S}\) tosses a biased coin, with the result “heads” having the probability \(1/|\textbf{K}|\). If the result is “heads”, then this means that the “right” private key was indeed \(\textsf{sk}_1^{(i)}\). In this case, \(\mathcal {S}\) gives up the simulation, outputting \(\bot \). Otherwise, \(\mathcal {S}\) sets \(\textbf{K}\leftarrow \textbf{K}\backslash \{i\}\) and returns \(\bot \) to \(\mathcal {A}\).

Again, we have that as long as \(\mathcal {A}\) has not managed to find the “right” private key, all values in the simulation are distributed identically to the experiment OG-CCA-C\({}^\mathcal {A}_{T,L}\) for \(\textsf{NPS}\). The probability of finding the “right” private key is upper-bounded by T/L, hence \(\mathcal {S}\) still has at least the non-negligible advantage \(\nu \) in solving the DDH problem in \(\mathbb {G}\).    \(\square \)

5 Fit for Our Main Use-Case

In our main use-case, the client is a smartphone, receiving and storing encrypted messages (e.g. credentials), and decrypting them for short uses. The smartphone communicates with the helper server over mobile internet, through a secure channel. An attacker in this system may have the following goals: (A) learn the plaintext corresponding to a ciphertext, or (B) make the phone accept wrong plaintext. Against this attacker we deploy \(\textsf{NPS}\), including the clone detection. The latter may be continuous.

We consider the following attacks that an attacker may perform: (1) convince the phone to start decryption protocol with a particular ciphertext; (2) learn phone’s encrypted memory; (3) learn phone’s unencrypted memory; (4) learn server’s keyshare; (5) take passive control over server; (6) take active control over server; (7) masquerade as phone to the server; (8) masquerade as server to the phone.

Let the boolean variable x indicate whether the clone detection is done continuously. Let \(y_i\) (\(i\in \{1,\ldots ,8\}\)) be a boolean variable indicating whether adversary has successfully performed the attack (i); note that \(y_3\Rightarrow y_2\), \(y_6\Rightarrow y_5\), and \(y_5\Rightarrow y_4\). Let the boolean variables \(z_\textrm{X}\) for \(\textrm{X}\in \{\textrm{A},\textrm{B}\}\) indicate that the adversary achieves his goal \(\textrm{X}\). Let also \(\tilde{z}_\textrm{X}\) denote that the goal is achieved only for a short time (until the continuously running clone detection mechanism discovers something); obviously \(z_\textrm{X}\Rightarrow \tilde{z}_\textrm{X}\). The following implications hold:

$$\begin{aligned}{}[y_2\wedge y_4]\vee [((y_2\wedge y_8) \vee y_3)\wedge y_7\wedge \lnot x]&\Rightarrow z_\textrm{A}&((y_2\wedge y_8) \vee y_3)\wedge y_7&\Rightarrow \tilde{z}_\textrm{A} \end{aligned}$$

Also, if some \(z_\textrm{X}\) or \(\tilde{z}_\textrm{X}\) is true, then this must follow from some of the implications. We see that \(z_\textrm{B}\) never holds, because Definition 4 forbids it. Server’s keyshare and phone’s encrypted keyshare are sufficient for decryption. So is the knowledge of phone’s unencrypted keyshare, if the attacker can masquerade the phone and the clone detection does not stop the attack. Interestingly, \(y_2\wedge y_8\Rightarrow y_3\), because the information sent in phone’s first message may enable the offline guessing attack against the PIN. We consider all these vulnerabilities acceptable.

We see that our scheme adds significant overhead to “plain” IND-CPA secure ElGamal. We also see that the overheads are wholly acceptable for our main intended use-case. We have implemented \(\textsf{NPS}\) encryption and decryption in Python on top of the PyCryptodome cryptographic library, using the elliptic curve group P-256 as \(\mathbb {G}\); the running times are 6 ms for \(\mathcal {E} nc \), 135 ms for \(\mathcal{D}\mathcal{C}_\textrm{C}\), and 107 ms for \(\mathcal{D}\mathcal{C}_\textrm{S}\) running on a laptop with an Intel® Core™ i5-10210U CPU and 16GB RAM. The size of a key encapsulation is 6 kilobytes, the messages sent from the client to the server and back: 6.7KB and 5.5KB, respectively.