OpenPGP Email Forwarding via Diverted Elliptic Curve Diffie-Hellman Key Exchanges

Abstract

An offline OpenPGP user might want to forward part or all of their email messages to third parties. Given that messages are encrypted, this requires transforming them into ciphertexts decryptable by the intended forwarded parties, while maintaining confidentiality and authentication. It is shown in recent lines of work that this can be achieved by means of proxy re-encryption schemes, however, while encrypted email forwarding is the most mentioned application of proxy re-encryption, it has not been implemented in the OpenPGP context, to the best of our knowledge. In this paper, we adapt the seminal technique introduced by Blaze, Bleumer, and Strauss in EUROCRYPT’98, allowing a Mail Transfer Agent to transform and forward OpenPGP messages without access to decryption keys or plaintexts. We also provide implementation details and a security analysis.

6 Simulation-Based Proof

Using the simulation techniques from [9, 13], we present a security analysis of the forwarding protocol. This proof addresses the security against semi-honest adversaries, i.e., parties that correctly follow the protocol and sample from the correct distributions, but use all available information to steal secrets. Also, a set of semi-honest adversaries can collude.

The idea of simulation-based proofs is to emulate any set of colluded participants by a random simulator residing in an ideal world where a trusted party exists and the protocol is secure by definition. The rationale behind this proof is that if it was possible to extract secrets from the views of colluded parties, then it would be trivial to distinguish them from the simulator (just select the view that allows extracting secrets). Conversely, if one cannot distinguish between the views, colluded parties cannot extract secrets. Therefore, the objective is to show that the set of elements held by the semi-honest parties (their view of the protocol) are indistinguishable from the elements held by the simulator.

1.1 6.1 Security Definitions

Ideal Functionalities A functionality is a process that maps tuples of inputs to tuples of outputs of a protocol $\Pi$, one for each party involved. More precisely, for a fixed set $P = \{P_1, \dots , P_k\}$ of k parties participating in the protocol, functionalities are k-ary functions $\mathcal F :(\{0,1\}^*)^k\rightarrow (\{0,1\}^*)^k$ mapping inputs to outputs of $\Pi$. We write $\mathcal F =(f_1,\dots ,f_k)$ where each $f_i$ is a k-ary function that outputs a string. In addition, if $\mathcal F$ computes the desired outcome by means of a trusted party in an ideal world that can communicate over perfectly secure channels with all participants, we say that $\mathcal F$ is an ideal functionality.

Views Given an execution of a protocol $\Pi$ on inputs $\mathcal X=(x_1,\dots , x_k)$, the view of party $P_i$ consists in all elements accessible to $P_i$ throughout the protocol:

$$\text{ view}_{P_i}(\mathcal X) = (x_i, r_i, m_1^i,\dots , m_j^i),$$

where $x_i$ is $P_i$’s input, $r_i$ is the content of its internal random tape used to sample elements, and $m_j^i$ is the jth message it received. Given a set of colluded parties, their joint view is defined as the tuple consisting in the concatenation of their views. Also, let $\text{ output}_{P_i}(\mathcal {X})$ be the elements held by party $P_i$ identified as the output of the protocol (note that the inputs or outputs may be empty for some parties).

Simulators Let $\Pi$ be a protocol with inputs $\mathcal {X}=(x_1,\dots ,x_k)$. A simulator is a PPT algorithm that, given an input $x_i$ corresponding to a party of the protocol, produces a tuple $\text{ sim}_{i}(x_i)$ similar to the view of this party. A joint simulator takes a set of inputs and produces a tuple similar to the concatenation of the corresponding parties’ views.

Simulation-Based Proof Following [13], our notion of security is based on emulating ideal functionalities defined by the forwarding protocol. This means that, given a protocol $\Pi$ with inputs $\mathcal {X}$, an ideal functionality $\mathcal {F}$ computing the output of $\Pi (\mathcal {X})$, and a set of semi-honest colluded parties, we construct a simulator that takes the inputs of these parties and produces a random joint view. We then show that these views along with the output of the protocol (i.e., the real world) and the simulator along with the ideal functionality result of these parties (i.e., the ideal world) are computationally indistinguishable. For instance, when simulating party i, we show that

$$\big (\text{ view}_{P_i}(\mathcal {X}), \text{ output}_{P_i}(\mathcal {X})\big )\simeq \big (\text{ sim}_i(x_i),f_i(\mathcal {X})\big )$$

and similarly for joint views of colluded parties, achieving the proof.

1.2 6.2 Forwarding Ideal Functionality

Consider parties Alice, Bob, T (the proxy), and Charlie (the forwarded party). As before, let $\chi$ be the distribution of $\mathbb {Z}$ that samples private keys uniformly from a subset of $\mathbb {Z}$, according to the security requirements of E (for instance, in Curve25519 [7], private keys are random samples of the form $2^{254}+8m$ for some $m<2^{252}$). Assume Alice sends a message $(P_B, c)$ to Bob, and Bob’s public key is $Q_B=d_BG$.

A basic forwarding ideal functionality could be given by

$$\big ((P_B,c), (Q_B, k_{BC}, d_C), \cdot , \cdot \big ) \mapsto \big (\cdot , \cdot , \cdot , (P_C,c)\big )$$

such that $d_CP_C = d_BP_B$. This works since Charles receives $d_C$ at some point in the protocol, and can decrypt c given $S=d_CP_C$. However, note that this functionality does not take into account multiple forwarded parties, nor the fact that those parties can also submit messages to Bob (as in Sect. 2.3). Recall also that, for each forwarded party $F_i\in F$, we note by $k_i:= k_{BF_i}$ the proxy factor held by T and $d_i:= d_{F_i}$ the secret scalar held by $F_i$.

Definition 1

Consider parties Alice, Bob, T (the proxy), and $F=\{F_1,\dots , F_m\}$ (the forwarded parties). Let

$$ \mathcal {X}:= (\mathcal {X}_A, \mathcal {X}_B,\mathcal {X}_T, \mathcal X_{F_1},\dots , \mathcal X_{F_m}) $$

be the input of the protocol where

$$\begin{aligned} \begin{array}{lll} \mathcal {X}_A := P_B, c &{} \text {Alice's message,} \\ \mathcal {X}_B := Q_B, (k_i, d_i)_{i=1}^m&{} \text {Bob's public key, proxy}\\ &{} \text {factors, and secret shares,} \\ \mathcal {X}_T := \cdot &{} \\ \mathcal {X}_{F_1} := (X_{1j})_{j=1}^{n_1} &{} F_1\text { sends }n_1\text { messages to Bob as in 2.3,} \\ \; \vdots &{} \\ \mathcal {X}_{F_m} := (X_{mj})_{j=1}^{n_m} &{} F_m \text{ sends } n_m \text{ messages } \text{ to } \text{ Bob } \text{ as } \text{ in } \text{2.3. } \\ \end{array} \end{aligned}$$

The forwarding functionality is $\mathcal F = (\mathcal {F}_A, \mathcal {F}_B,\mathcal {F}_T,\mathcal {F}_{F_1},\dots , \mathcal {F}_{F_m})$ where

$$ \begin{array}{ll} \mathcal {F}_A : \mathcal {X} \mapsto \cdot \\ \mathcal {F}_B : \mathcal {X} \mapsto c, d_B, P_B, ((X_{ij})_{j=1}^{n_i})_{i=1}^m \\ \mathcal {F}_T : \mathcal {X} \mapsto \cdot \\ \mathcal {F}_{F_1} : \mathcal {X} \mapsto c, d_1, P_1, ((k_1X_{ij})_{j=1}^{n_i})_{i=1}^m \\ \; \vdots \\ \mathcal {F}_{F_m} : \mathcal {X} \mapsto c, d_m, P_m, ((k_mX_{ij})_{j=1}^{n_i})_{i=1}^m \end{array} $$

such that $d_1P_1 = d_2P_2 = \dots = d_mP_m = d_BP_B$.

Note that for every message $X_{ij}$ sent as in Sect. 2.3, forwarded parties also receive an encryption $c_{ij}$ of some message. Without loss of generality, we omit these encryptions from the ideal functionality, since these are trivial to simulate and provide no information to attackers (as they are simply transmitted unchanged throughout the protocol).

More precisely, following Sect. 2.3, forwarded parties pick any message $\tilde{m}$ and a secret key $\tilde{d}\leftarrow \chi$, set $\tilde{S} = \tilde{d} Q_B$ where $Q_B$ is Bob’s public key, and let $X_{ij} = \tilde{d} G$, $c_{ij} = \text{ Enc}_{\tilde{S}}(m)$. Instead, without loss of generality, we let forwarded parties freely choose $X_{ij}$ as an input to the protocol.

1.3 6.3 Security Against Colluded, Eavesdropper Semi-honest Parties

Simulating the Semi-honest Proxy According to the protocol described in Sect. 2.2, we have the following view of the proxy throughout the protocol:

$$\text{ view}_{T}(\mathcal X) = \big (\cdot , c, P_B, k_1, \dots , k_m, (X_{ij})_{ij}\big )$$

where each $k_i$ was provided by Bob (for the sake of notation, $(X_{ij})_{ij}$ consists in all points chosen by forwarded parties, in Definition 1). Indeed, for each i, Bob sampled $d_i\leftarrow \chi , k_i := d_B/d_i\!\!\mod n$, and sent $k_i$ to the proxy. Now, consider the simulator that samples $y \leftarrow \chi$, $x_i \leftarrow \chi$, and $z_i\leftarrow \chi$ for $i=1,\dots ,m$, a tuple of random points $(\tilde{X}_{ij})_{ij}$ and sets

$$\text{ sim}_{T}(\mathcal X_T) := \big (\cdot , c, yG, x_1z_1^{-1},\dots , x_mz_m^{-1}, (\tilde{X}_{ij})_{ij}\big ).$$

Recall that (i) there is no input or output for T in this protocol, and also (ii) all other parties behave honestly in this case (in particular, $X_{ij}$ are uniformly random points of the curve). Given these facts, it is straightforward to see that view$_T(\mathcal X)$ and sim$_T(\mathcal {X}_T)$ are computationally indistinguishable.

Simulating Forwarded Parties As described in Sect. 2.3, each forwarded party $F_i$ computes the session secret $S=d_iP_i$ from the output, and also has a stream of pairs of the form $(X_{ij},k_iX_{ij})\in E^2$ for chosen $X_{ij}$ (this is the result of sending messages encrypted to Bob and parsing the forwarded ciphertexts).

$$(\text{ view}_{F_i}(\mathcal X),\text{ output}_{F_i}(\mathcal X)) = \big ((X_{ij})_{j=1}^{n_i};c, d_i,P_i,(k_iX_{ij})_{j=1}^{n_i}\big )$$

. Note that, since there are no intermediate values computed by forwarded parties, a simulator that can access the input and output of a forwarded party can simulate it trivially. In this case, we have simply

$$\big (\text{ sim}_{F_i}(\mathcal {X}_{F_i}), \mathcal {F}_i(\mathcal {X})\big )\equiv \big (\text{ view}_{F_i}(\mathcal {X}),\text{ output}_{F_i}(\mathcal {X})\big ).$$

Naturally, the joint view of colluded forwarded parties is also trivially simulated by the joint simulators.

Simulating Colluded, Eavesdropper Forwarded Parties Additionally, let us assume further that this party eavesdropped the share $P_B=d_AG$ from the communication between Alice and the proxy, and recall that they also have the public key $Q_B=d_BG$. Such party has the following view and output:

$$(\text{ view}_{F_i}(\mathcal X),\text{ output}_{F_i}(\mathcal X)) = \big ((X_{ij})_{j=1}^{n_i};d_AG, d_BG; c,d_i,P_i,(k_iX_{ij})_{j=1}^{n_i}\big )$$

. Consider the simulator that samples $x,y\leftarrow \chi$ and sets

$$\big (\text{ sim}_{F_i}(\mathcal X_{F_i}),\mathcal {F}_i(\mathcal X)\big ) = \big ((X_{ij})_{j=1}^{n_i};xG, yG;c, d_i,P_i,(k_iX_{ij})_{j=1}^{n_i}\big ).$$

The only distinct elements are $d_AG, d_BG$ and xG, yG. Note that, since $d_iP_i=d_Ad_BG$, a DH triplet $(d_AG,d_BG,d_Ad_BG)$ can be composed in the view. The simulator, on the other hand, can compose the tuple $(xG, yG, d_Ad_BG)$. However, since $d_Ad_BG$ is uniformly random, this tuple is indistinguishable from a proper DH triplet (xG, yG, xyG) by the ECDH assumption. It follows that the view and the simulator are computationally indistinguishable. It is straightforward to extend the simulator and address the case where multiple semi-honest forwarded parties collude: The joint view and output will only have more independent ECDL samples of the form $(X, k_iX)$ and parties can compose the same ECDH triplet (also, note that the additional samples $d_i, P_i$ of the form are also accessible by the simulator, and the same argument holds).

Putting all these cases together, it follows that the protocol securely computes $\mathcal F$ in the presence of semi-honest, colluded adversaries.