Updatable Public-Key Encryption, Revisited

Abstract

We revisit Updatable Public-Key Encryption (UPKE), which was introduced as a practical mechanism for building forward-secure cryptographic protocols. We begin by observing that all UPKE notions to date are neither syntactically flexible nor secure enough for the most important multi-party protocols motivating UPKE. We provide an intuitive taxonomy of UPKE properties – some partially or completely overlooked in the past – along with an overview of known (explicit and implicit) UPKE constructions. We then introduce a formal UPKE definition capturing all intuitive properties needed for multi-party protocols.

Next, we provide a practical pairing-based construction for which we provide concrete bounds under a standard assumption in the random oracle and the algebraic group model. The efficiency profile of the scheme compares very favorably with existing UPKE constructions (despite the added flexibility and stronger security). For example, when used to improve the forward security of the Messaging Layer Security protocol [RFC9420], our new UPKE construction requires less than $1.5\%$ of the bandwidth of the next-most efficient UPKE construction satisfying the strongest UPKE notion considered so far.

1 Introduction

Spurred on by the seemingly never-ending procession of data breaches, 0-day exploits and system compromises, it is becoming ever more important in to design protocols with the ability to automatically limit the blast radii of key and state compromises. Among other techniques, this has lead to interest in primitives designed to provide cheap but effective forward security, namely the property that security holds despite possible future compromises.

A naïve (though not ineffective) approach to providing forward security for, say, public-key encryption (PKE) is for the owner of a key pair $(\textit{pk}, \textit{sk})$ to periodically sample a fresh and independent key pair $(\textit{pk}', \textit{sk}')$ that replaces its old keys. While this does provide forward security – old ciphertexts encrypted to $\textit{pk}$ remain secure even if the adversary learns $\textit{sk}'$ – it comes with a serious drawback from the protocol perspective. After each key rotation the receiver must first inform prospective senders of the new public key before new messages can be sent privately to the receiver again.¹ Besides increasing communication complexity, the biggest issue with this is that it forces potentially onerous coordination requirements on protocol participants.

Avoiding this cost motivated the study of Puncturable Public-Key Encryption [GM15] (PPKE) as a stand-alone primitive. PPKE provides essentially the same security as the naïve approach but without further coordination between parties beyond the initial public key distribution. After that, any number of senders may independently send any number of ciphertexts to the receiver which can be delivered in any order (or not at all). Despite the lack of coordination between parties, PPKE guarantees that at any point, leaking the receiver’s secret key reveals nothing about messages in ciphertexts it had already received and decrypted.

Clearly a powerful tool for building forward-secure protocols, PPKE lies at the heart of recent forward-secure 0-round trip key agreement protocols [GHJL17]. But minimizing round and communication complexity for forward-secure key agreement underpins other classes of cryptographic protocols. Notably, these include 2-party ratcheting [JS18, PR18, JMM19, DV19, CCD+20], the multi-party analogue: continuous group key agreement (CGKA) [ACDT20, AAN+22, ACJM20] and secure group and 2-party messaging [ACDT21]. In this work, we are especially interested in CGKA and secure group messaging (SGM) applications of forward-secure encryption primitives as these demand new, and hitherto seemingly overlooked, properties of the underlying primitive.

Updatable Public Key Encryption. Unfortunately, despite its wide-ranging practical applications, to date, PPKE constructions are not practically efficient for many real-world use cases, in particular in the ratcheting and messaging settings. This has given rise to a new class of “off-brand” forward-secure encryption schemes in the messaging literature called Updatable Public-Key Encryption (UPKE). They aim for a happy middle ground between forward secrecy with minimal interaction and truly practical efficiency.

Intuitively, UPKE is public-key encryption where senders can also generate update tokens. Applying a token $\textit{up}$ to a public key $\textit{pk}$ produces an updated public key $pk \rightarrow _\textit{up}pk'$. Similarly, applying $\textit{up}$ to the secret key $\textit{sk}$ of $\textit{pk}$ yields the secret key $\textit{sk}\rightarrow _\textit{up}\textit{sk}'$ corresponding to $\textit{pk}'$. The essential promise of UPKE is that ciphertexts encrypted to $\textit{pk}$ remain secure even when an adversary learns $\textit{pk}$, the token $\textit{up}$ and the updated secret key $\textit{sk}'$. Thus, a protocol in which parties update receivers’ key pairs whenever encrypting to them can achieve relatively strong forward secrecy properties. Indeed, no secret key is ever used more than once by a party and is immediately deleted (and replaced) upon first use.

However, there is a caveat to this. While using UPKE this way doesn’t require as much coordination between parties as the naïve approach, it does require more than PPKE. To ensure a receiver has the correct secret key available, a sender must encrypt to the most recent version of the receiver’s public key. In other words, senders must see each others’ $\textit{up}$ tokens (or at least the most recently updated public key) before they can send. Otherwise, two senders may concurrently produce update tokens $\textit{up}_0$ and $\textit{up}_1$ for one public key $\textit{pk}$ giving rise to two sibling key pairs $(\textit{pk}_0, \textit{sk}_0)$ and $(\textit{pk}_1, \textit{sk}_1)$. We refer to this as a “fork”. When a fork occurs, a receiver will typically only derive one of the forked secret keys $\textit{sk}_b$ since it must then immediately delete $\textit{sk}$ to ensure forward security. Thus, when it later receives $\textit{up}_{1-b}$, it can no longer produce $\textit{sk}_{1-b}$ meaning it can’t decrypt anything sent to $\textit{pk}_{1-b}$ (or any of its descendent keys). A similar restriction is that the receiver must decrypt ciphertexts in the same order they were sent (even when sent by different senders).

Still, compared to the naïve technique this represents a qualitative reduction in coordination since the receiver can essentially stay silent after initial public key distribution. Crucially, this makes asynchronous communication (as understood in asynchronous (group) messaging) possible, because senders need not wait for a receiver to announce new public keys before they can encrypt new messages to them. Thus, UPKE provides to secure messaging protocol designers the benefits of strong forward secrecy without forcing them to compromise on the ability of parties to privately message each other despite receivers potentially being off-line for extended periods of time.

Unfortunately, no UPKE scheme to date is sufficiently flexible, nor has all of the requisite security properties for natural use in CGKA and SGM applications which UPKE was partly designed for. Indeed, the initial academic work [ACDT20] in this area introduced rTreeKEM, a CGKA protocol which provides strong forward security by using UPKE in place of the PKE. The goal was to provide a more secure CGKA upon which to re-base the IETF’s Messaging Layer Security (MLS) protocol, an open SGM standard specified in RFC9420 [BBR+23]. However, rTreeKEM (and the resulting SGM based on rTreeKEM [ACDT21]) were only analyzed in a restricted model, which lead to relatively lightweight demands being placed on the underlying UPKE (both in terms of functionality and security).

Since then, however, the much more realistic “insider security” paradigm [AJM22] has established itself as a standard in the CGKA and SGM literature [HKP+21, AHKM22, AMT23]. Unlike the security models of [ACDT20, ACDT21], which assume authenticated channels, insider security only uses an insecure network. More challengingly maybe, insider security also provides meaningful security guarantees to parties joining “fake” groups; that is, sessions created arbitrarily by the adversary. These additions mean that insider security better captures the practical security concerns for SGM and CGKA. However, they also mean that to date, all UPKE schemes lack either the flexibility or security necessary for a CGKA (or SGM) application like rTreeKEM to be insider-secure.

Fake-Group Security. One such missing security property of existing UPKE notions is the (intuitive) property we call “joiner” security. When UPKE is used in higher-level CGKA/SGM protocols as a forward-secure replacement for PKE (as in rTreeKEM, for example), the joiner security of the UPKE scheme plays a central role in ensuring that the resulting CGKA/SGM protocol provides the “fake group” security aspect of insider security.

In more detail, CGKA and SGM protocols allow for dynamic groups (i.e. groups with evolving membership). Thus, a party P might receive an invitation to join an existing group mid-session. To join the group, P also receives the group state including the signature verification keys for each group member (authenticated by some trusted PKI). Fake-group security (for SGM) considers the case when the invitation (and accompanying group state) were produced maliciously by the adversary (who may also corrupt parties). It mandates that if P validates the invitation and state (as specified by the protocol) and subsequently proceeds with the execution to a point where no corrupt signing keys are left in the group’s state, then the session should return to a secure state. For example, P’s messages to the group should remain hidden from the adversary. Notably, this should be the case even though the group state could still includes (U)PKE keys obtained by P from the adversary.

Fake-Group Security in MLS. To date, the only protocol we are aware of that achieves fake-group security is MLS. It does so by including signatures in the public group state, which give P a way to identify which PKE keys in the state were (supposedly) generated by which party and to whom the party sent the decryption keys as part of the protocol execution. Whenever a party is removed from the group, so too are any keys they either (supposedly) generated or were sent. In the insider corruption model, leaking a party’s signing key also leaks all other secret keys it knows. Thus, if at some point only secure verification keys remain in the group state, we can conclude that all remaining public keys were generated by and sent to uncorrupted parties. As a result, under those conditions, MLS can provide P with meaningful security guarantees for the session.

UPKE Breaks MLS’s Fake-Group Security Mechanism. When [ACDT20] proposed replacing PKE with UPKE to improve MLS’s forward security, the authors left as an open problem how to adapt MLS’s mechanism for fake-group security accordingly (at least without growing the group state in the number of updates to UPKE keys). This was one of the primary barriers to adopting UPKE in MLS.

Indeed, in general, the state of a group mid-session would include UPKE keys $\textit{pk}$ that are (nominally) the result of updates to some prior original key $\textit{pk}_0$. So, to guarantee that $\textit{pk}$ is still secure, a new member must validate that (i) $\textit{pk}_0$ was generated by an honest party, and (ii) that $\textit{pk}$ is the result of honestly using the update algorithm starting from $\textit{pk}_0$.

One approach to providing (ii) could be to include in the group state all update tokens $\textit{up}$ leading from $\textit{pk}_0$ to $\textit{pk}$ along with proofs that they were generated by the update algorithm. But this results in a state size and computational cost of joining that grow linearly in the number of updates between $\textit{pk}_0$ and $\textit{pk}$, which is prohibitive in practice. (MLS sessions can be expected to last for years and have, say, $n = 50,000$ group members; so some of the 2n public keys in an MLS state could have been updated n/2 times by the time a new member joins.) It is also not an adequate solution to have receivers (i.e., members who can compute the updated $\textit{sk}$, which could be as few as a single party) sign the updated $\textit{pk}$ to attest to its correctness, as it conflicts with the asynchronous nature of MLS.²

This motivates the joiner security property of UPKE identified in this work. It provides a joiner P with a concise tag for validating that some UPKE public key pk is the result of an (unknown) sequence of honest updates to a given “origin” UPKE public key $pk_0$. Thus, if an uncorrupted honest party attests to having generated $pk_0$ via a signature (just as with the PKE keys in MLS) then we can again conclude, in the insider security model, that pk must be secure.

Our Proposal: UPKE Allowing for Fake-Group Security. These issues show that there seems to be no easy way to efficiently adapt MLS’s fake-group security mechanism to UPKE. So instead, we ask the UPKE scheme to directly provide a comparable public key validation mechanism for new members (and a matching security guarantee). A joiner-secure UPKE scheme thus includes an algorithm $\textsf {Verify}_\textsf{jt}$ with 3 inputs: (i) a UPKE public key $\textit{pk}$ to be validated, (ii) an original public key $\textit{pk}_0$ and (iii) a “joiner tag” $\textit{jt}$. The tag must be constant-size, in particular, independent of how many updates might have lead to from $\textit{pk}_0$ to $\textit{pk}$.

The UPKE security game chooses the initial $\textit{pk}_0$ honestly at the start of the game (reflecting that in the application we only expect security from $\textit{pk}$ if an honest party attested to having generated $\textit{pk}_0$, e.g. via a signature). Then, the UPKE adversary may update $\textit{pk}_0$ with honest (i.e., generated by the challenger) or potentially malicious tokens $\textit{up}$. The adversary wins if it can come up with $\textit{pk}^*$ and $\textit{jt}^*$ which pass $\textsf {Verify}_\textsf{jt}$ and for which it can break privacy (IND-CCA) of a ciphertext $c^*$ encrypted to $\textit{pk}^*$. However, the adversary loses if it corrupts a secret key created before requesting $c^*$.

This restriction excludes trivial attacks in which $\textit{pk}^*$ is an updated version of a corrupted key. On the other hand, the restriction is not tight in the sense that it also excludes corruptions that do not lead to trivial attacks. We believe that our joiner security is a good compromise for the following reasons. First, defining UPKE security that only excludes trivial attacks would require UPKE schemes with additional functionality, which seems to require inefficient constructions.³ Second, our joiner security is sufficient to prove that MLS with UPKE achieves the same fake-group security as today’s MLS with PKE. In fact, the above can be proven even using UPKE joiner security with no corruptions at all. This means that our joiner security notion with corruption could enable an even stronger flavor of fake-group security for MLS with UPKE. Indeed, in the full version we give an example of an MLS execution where MLS with UPKE satisfying our stronger joiner security is secure, but would not be so if its UPKE only satisfied a notion disallowing corruptions. Such a stronger notion for MLS has not been defined yet, and we leave this as an interesting open problem.

UPKE Taxonomy. Hiding beneath the term “UPKE” and the high-level intuition above, we actually find a series of concrete schemes in the literature (e.g. [JMM19, ACJM20, EJKM22, HLP22, DKW21, AMT23, AW23, HPS23]) that differ in their syntax, security properties and even the purposes they serve in the applications they were conceived for. To better interpret the results in our work, it is instructive to categorize these differences.

Long vs. Short Syntax: The most obvious differences between UPKE schemes are their various syntaxes. UPKE was first introduced in [JMM19] using an (asymmetric) long syntax also used in [AAN+22, EJKM22]. Here, “long syntax” means that key updates are generated and applied using stand-alone algorithms. In contrast, in this work (as in [ACDT20, ACJM20, ACDT21]) we use a short syntax, where keys are updated as a side-effect of encryption and decryption, thereby obviating the need for explicit update algorithms. We opted for the simpler syntax as it suffices for the dynamic group protocol applications we focus on and converting to long syntax is trivial.

Further, [EJKM22] defines two variants of a long syntax. “Asymmetric” long syntax means an update $\textit{up}= (\textit{pu}, \textit{su})$ includes a public component $\textit{pu}$ for updating public keys and a private component $\textit{su}$ for updating corresponding secret keys. “Symmetric” long syntax uses a single value to update both public and private keys. The notions in [DKW21, HLP22, AW23, HPS23] can be viewed as having a symmetric long syntax where the random coins used by the public key update algorithm are also the update token used for the private key.

CPA vs. CCA: The first UPKE applications needed only CPA-style UPKE as they either included additional mechanisms reducing the role of UPKE in their protocol [JMM19, AAN+22] or their application was analyzed in a model that disables all attacks that might leverage honest parties as decryption oracles. (For example, the use of ideal authenticated channels in [ACDT20] trivially prevents the adversary from injecting ciphertexts to honest parties.) However, subsequently, the stronger and more realistic “insider security” model [AJM22] has become the standard in the field [HKP+21, AHKM22, AMT23]. This motivated the need for CCA-style UPKE. Indeed, all subsequent UPKE constructions (including in this work) are now regularly proven secure with CCA-style security games.

Forking Security: Almost all UPKE applications in the group setting involve multiple parties using the same UPKE secret key. An adversary that, say, controls the network can easily cause such parties to have diverging views of a protocol session’s transcript. This can result in forked UPKE keys (i.e., the initial key is updated using different sequences of updates). Thus, for such settings UPKE schemes must provide security in the face of forks. To date, we know of no (explicitly defined) UPKE scheme with this property, including those in [JMM19, EJKM22, HLP22, AW23, DKW21, HPS23] making them, a priori, insufficient for such applications.⁴

Notable exceptions are the schemes of [ACJM20, AMT23] that are (implicitly) based on hierarchical identity-based encryption (HIBE). Unfortunately, owing to their use of unbounded-depth HIBE, these are decidedly impractical for real-world applications leaving the state of UPKE for the group setting unsatisfactory.

Decryption Oracles for Old Keys: Even assuming there are no forks, in a setting with multiple parties using the same UPKE secret key, one has to account for parties not seeing some of the updates (yet) and hence holding old versions of the secret key. Accordingly, UPKE security notions should account for the attacker trying to inject ciphertexts to such parties. More precisely, assume we want to prove that an SGM scheme using UPKE is secure against adversaries who can inject ciphertexts but can not create forks. Even this weaker notion requires a UPKE security notion where, even after receiving the challenge ciphertext, the adversary can use the decryption oracle for any old secret key. However, this is not covered by any CCA-style UPKE definition we know of, in particular, not for [AW23, DKW21, HLP22, HPS23] (Table 1).

Table 1. Comparison of security properties of different UPKE schemes. The last two columns indicates whether they are practically efficient and in which model they are proven secure. AGM stands for the algebraic group model [FKL18].

Agnostic Updates: The applications of UPKE considered in [JS18, PR18, JMM19, AAN+22] require update tokens to be generated without knowing the public key to which they will ultimately be applied which we refer to as “agnostic” updates. Consequently, the UPKE schemes in those works are agnostic (as is the one in [EJKM22] and the implicit ones in [ACJM20, AMT23], although this is not necessary for the applications in those works). Conversely, the constructions of [AW23, DKW21, HLP22, HPS23] create updates for a target key.

Protocol Usage: While UPKE is usually used as a tool for achieving forward security in an application, the work of [AAN+22] applies updates to a possibly leaked secret key to refresh it to a new secure secret key. In other words, their protocol also relies on UPKE updates to ensure post-compromise security (PCS).⁵ Thus, unlike any other use for UPKE we are aware of, [AAN+22] needs the additional intuitive property that secret keys of updated public keys have high (computational) entropy given the old secret key and updated public key. Fortunately, to the best of our knowledge, most UPKE schemes already have this property with the exception of the HIBE-based implicit schemes in [JS18, PR18, ACJM20, AMT23]. For the purpose of this work we focus on using UPKE for forward secrecy, so we leave such an entropy requirement for future work.

Publicly Verifiable Updates: In multi-party protocols like MLS and rTreeKEM, a common feature is that more than one user might encrypt messages to a particular public key. Suppose we use UPKE in this setting and a party $P_1$ updates a public key $\textit{pk}$ to $\textit{pk}'$. It is important that everyone in the group is convinced that $\textit{pk}'$ was generated via an honest update. Otherwise, a corrupt group member $P_1$ (called an insider) might generate a key pair $(\textit{pk}^*, \textit{sk}^*)$ using KeyGen and then convince someone that $\textit{pk}^*$ is the updated key. Clearly this would make all future ciphertext sent to the “updated key” $\textit{pk}^*$ insecure.

For group members that know $\textit{sk}$, avoiding this is usually not too difficult. For example, $P_1$ could encrypt to $\textit{pk}$ the coins used to produce the update [ACDT20]. However, revealing those coins to members who do not know $\textit{sk}$ would be problematic since UPKE security notions only ensure forward secrecy for updated keys if the coins used to update $\textit{sk}$ to $\textit{sk}'$ are kept secret.

So, to prevent an insider from tricking parties that don’t know $\textit{sk}$ into accepting arbitrary new public keys, the UPKE scheme should provide a method to publicly verify that $\textit{pk}'$ was produced from $\textit{pk}$ via the update algorithm. To achieve this, the verification procedure can also take as input a validation tag provided by $P_1$ as part of the message it sends to the group to announce the update. Intuitively, UPKE security should guarantee that if $\textit{pk}$ is secure and the pair $(\textit{pk}, \textit{pk}')$ passes validation (with some tag), then $\textit{pk}'$ is also secure. Accordingly, the UPKE constructions [HLP22, DKW21, HPS23] include a special $\textsf {VerifyUpdate}$ algorithm. For the implicit HIBE-based schemes of [ACJM20, AMT23], update verification is quite trivial and the step is left implicit.

To summarize, no UPKE scheme to date is known to satisfy the (CCA and) forking security properties needed to use UPKE in a CGKA protocol like rTreeKEM [ACDT20] and meet the standard insider security for CGKA. (See the full version for a toy scheme that satisfies the UPKE security notion of [DKW21, HLP22, HPS23], yet leads to a trivial insider security attack when used in place of PKE in MLS as proposed in [ACDT20]. The attack leverages the lack of forking security in those UPKE notions.)

Our Contributions

New Model. In this work, we study CCA-secure Updatable Key Encapsulation Mechanisms (UKEM); the KEM analogue of UPKE. Note that building UPKE from a UKEM is straightforward (for both the long and short syntax) e.g. using a standard KEM/DEM construction of CCA-secure PKE from a CCA-secure KEM and a CCA-secure authenticated encryption scheme, as done for example in Hybrid Public Key Encryption (HPKE) [BBLW22].

We present a new UKEM syntax and security definition designed to meet the needs of dynamic group protocols such as MLS and rTreeKEM of [ACDT20]. In particular, it captures CCA-type confidentiality with forks and joiner security. Our notion for UKEM can be easily extended to model UPKE security.

The new syntax does not require agnostic updates as this is not needed for these applications. It is based on the short UPKE syntax augmented with two public key validation algorithms. The first, $\textsf {Verify}_\textsf{jt}$, lets new members joining a group validate the public keys they download as part of the group’s state. It takes as input a public key $\textit{pk}_0$, a public key $\textit{pk}_i$ being validated and a joiner tag $\textit{jt}_i$. The joiner tag is generated along with $\textit{pk}_i$. In particular, the tag $\textit{jt}_0$ is generated alongside $\textit{pk}_0$ by KeyGen and for $i> 0$, the tag $\textit{jt}_i$ is generated by Encaps when encrypting to and updating $\textit{pk}_{i-1}$, given only $\textit{pk}_{i-1}$ and $\textit{jt}_{i-1}$.

Joiner tags can be used to provide new-member security in protocols like MLS and rTreeKEM as follows. In addition to each UPKE public key $\textit{pk}_i$, the group state contains the associated tag $\textit{jt}_i$, as well as the original key $\textit{pk}_0$ signed by the group member who generated it.⁶ Whenever a group member encrypts to $\textit{pk}_{i-1}$, they replace $\textit{pk}_{i-1}$ and $\textit{jt}_{i-1}$ by $\textit{pk}_{i}$ and $\textit{jt}_{i}$. Note that this can be done by all members, including new ones who did not see $\textit{pk}_1,\dots ,\textit{pk}_{i-2}$. Further, new members can verify the signature on $\textit{pk}_0$ and verify $\textit{jt}_i$, which convinces them, respectively, that $\textit{pk}_0$ was honestly generated and then updated to get $\textit{pk}_i$.

The second algorithm, $\textsf {Verify}_\textsf{mt}$ plays the same role as $\textsf {VerifyUpdate}$ in the syntax of [HLP22, DKW21, HPS23]. It allows existing group members that do not know the secret keys to validate an updated public key. It takes as input the previous public key $\textit{pk}_{i-1}$, the updated public key $\textit{pk}_i$ and a member tag $\textit{mt}_i$, also produced as part of the output when encapsulating to $\textit{pk}_{i-1}$.

One may wonder why $\textsf {Verify}_\textsf{mt}$ is needed and why members cannot verify $\textsf {Verify}_\textsf{jt}$ instead. Indeed, there may exist schemes for which this is the case. However, constructing $\textsf {Verify}_\textsf{mt}$ is much easier. Intuitively, this is because the creator of $\textit{mt}_i$ can use the actual “witness” (i.e., secret randomness) for updating $\textit{pk}_{i-1}$ to $\textit{pk}_i$. On the other hand, $\textit{jt}_i$ must be generated without knowledge of the witnesses of the updates from $\textit{pk}_0$ up to $\textit{pk}_{i-1}$. As a result, our efficient construction achieves better security for $\textsf {Verify}_\textsf{mt}$. On the other hand, joiners cannot profit from this additional security.

Our Construction. We provide a practically efficient construction of UKEM satisfying our model based on pairing-friendly elliptic curves. We prove it secure in the combination of the random oracle model (ROM) and the algebraic group model (AGM) [FKL18] (see below) under the co-discrete-log assumption, which in the AGM directly implies the co-CDH assumption [BLS01].⁷

Our starting point is the ElGamal-based KEM of DHIES [ABR98]. Public keys are of the form $u=g^x\in \mathbb {G}$ in a group $\mathbb {G}$ of prime order p with secret key $x\in {\mathbb Z_p}$. To encapsulate a symmetric key K, one chooses , computes the ciphertext $v:=g^r$ and sets $K:=H(u,u^r)$, where H is treated as a random oracle.

To update a public key u in our scheme, we choose a random , which defines a new key $u':=u\cdot g^d$. The associated member tag $\textit{mt}$ is a proof of knowledge of d. Intuitively, this proof guarantees that if u was “secure” then so is $u'$. Indeed, suppose an adversary could update a random key $u=g^x$ to $u'=g^y$ for which it knows the secret key y while also proving knowledge of d such that $u'=u \cdot g^d$. Then by extracting d from the PoK we can use the adversary to compute the discrete log $x = y-d$ for a random u. For our scheme, this intuition about the one-wayness of u and $u'$ also extends to CCA-security. To allow receivers to update their secret keys accordingly, d is encrypted under u. Decrypters can thus recover d and update secret key x to $x':=x+d$ for $u'$.

In fact, in our construction, d is actually derived via a random oracle (like the encapsulated key $K$). This achieves three goals. First, it allows us to deal with adaptive corruptions, a problem resulting from forks (see below). Second, unlike in [JMM19, ACDT20] we can use the KEM ciphertext directly to transmit d, which saves on encrypting d explicitly. Third, using encryption would require key-dependent message security.

Our UKEM member security notion requires CCA-security for any public key whose member tag is valid. The notion is strong in that it allows the adversary to adaptively corrupt any secret key $\textit{sk}$ as long as $\textit{sk}$ does not let the adversary learn the challenge secret key in a trivial way. We achieve this leveraging the random oracle and by devising a careful guessing strategy: the security reduction guesses the first key $u^*$ on the path of key updates leading from an initial honestly generated public key $u_0$ to the challenge public key for which (i) the adversary breaks an encryption (which, as in DHIES, corresponds to solving CDH) or (ii) it breaks an encryption of any key the adversary derived from $\textit{pk}^*$. Note that the reduction does not know this path and so it simply guesses a key.

Despite allowing adaptive corruption, our reduction achieves a security loss of only the number of ciphertexts (and thus new keys) the adversaries asks for. For this to work, we need to assume that the proofs of knowledge of d (i.e., $\textit{mt}$) are simulation-sound, that is, even after the adversary has seen simulated proofs (which the reduction creates when embedding its CDH challenge as a key), we can extract from an adversarial proof $\textit{mt}$. This lets us “translate” a CDH solution for a key the adversary derived from the embedded key $u^*$ to a solution for $u^*$.

Aiming for efficiency, we instantiate these proofs of knowledge of logarithms with Schnorr proofs, which consist of one element from $\mathbb {G}$ and one from ${\mathbb Z_p}$. These proofs were shown simulation-sound in the ROM and the algebraic group model [FPS20, FO22], which provides “straight-line extractability”. That is, extraction of the witness does not require rewinding the adversary (as in the security proof in the ROM), which means we can extract from several proofs without risking an explosion of the running time due to interleaved rewinds for several proofs.

Joiner Security. A trivial construction of a joiner tag $\textit{jt}$ would be to include all $\textit{mt}$ proofs and intermediary public keys on the path from $u_0$ to $u'$, which guarantee knowledge of $d_1,\dots ,d_k$ s.t. $u'=u_0\cdot g^d$ for ${d=d_1+\cdots +d_k}$. However, this is inefficient and our goal is constant-size joiner tags. Since the updater does not know the value d, we need a way to “aggregate” the proofs $\textit{mt}_i$ guaranteeing honest hops from $u_{i-1}$ to $u_{i}$ into a single short proof $\textit{jt}$ guaranteeing honest hops from $u_0$ all the way to $u'$. An inherent problem with aggregatable proofs is that aggregation introduces malleability, which conflicts with our requirement that $\textit{mt}$ should be simulation-sound. Thus, we cannot hope that an instantiation of $\textit{jt}$ can also play the role of $\textit{mt}$.

A very simple proof of knowledge of a logarithm is to assume that there exists a second generator h of $\mathbb {G}$ of which no one knows the discrete log. To prove knowledge of the logarithm of $v=g^d$, one sets $\pi :=h^d$. The knowledge-of-exponent assumption [Dam92] states that $\pi$ can only be computed if one knows d; formally, for any algorithm outputting $(g^d,h^d)$, there exists an extractor that outputs d. These proofs can be aggregated: given a proof $\pi =h^d$ for $u=g^x$ w.r.t. $u_0=g^{x_0}$, that is $d=x-x_0$, a proof for $u':=u\cdot g^d$ is computed as $\pi ':=\pi \cdot h^d$.

The problem is how to verify whether $\pi$ was correctly computed. This is why we embed our scheme in a bilinear group. That is, we assume a second group $\hat{\mathbb {G}}$ and a bilinear map ${\text {e}}:\mathbb {G}\times \hat{\mathbb {G}}\rightarrow \mathbb {G}_T$ for some target group $\mathbb {G}_T$.⁸ We can now set the basis h for the proofs as a generator of $\hat{\mathbb {G}}$ and use the pairing to verify a proof $\pi \in \hat{\mathbb {G}}$ for $v\in \mathbb {G}$ by checking whether ${\text {e}}(v,h)={\text {e}}(g,\pi )$.

We prove joiner security directly in the algebraic group model. This model implies states that after having received elements $h,\pi _1,\dots ,\pi _k\in \hat{\mathbb {G}}$, whenever the adversary returns some $\pi \in \hat{\mathbb {G}}$, it must have computed $\pi$ as a linear combination (“algebraically”) of all the $\hat{\mathbb {G}}$ elements it has received. In particular, the AGM assumes that the adversary outputs $\alpha _0,\dots ,\alpha _k\in {\mathbb Z_p}$ such that $\pi =h^{\alpha _0} \cdot \pi _1^{\alpha _1}\cdots \pi _k^{\alpha _k}$. In our security proof, h and the proofs $\pi _1,\dots ,\pi _k$ computed by the reduction will be all $\hat{\mathbb {G}}$ elements given to the adversary. As the reduction knows the discrete logarithms of the $\pi _i$’s, it can compute the logarithm of $\pi$ from $\alpha _0,\dots ,\alpha _k$.

Table 2. Comparison of object sizes in {kilo, mega}-bytes of recent UPKE schemes. By $\phi$ we denote the bit-length of a NIZK that the update was generated correctly. A similar NIZK is needed to make the CPA scheme [DKW21] CCA-secure, while the CRS for the NIZK is included in public keys. In all UPKE applications considered in this work (e.g. rTreeKEM and MLS) ciphertexts are always sent together with a public key, an update $\textit{up}$, joiner tag $\textit{jt}$ and member tag $\textit{mt}$.

Weaker Assumption for Member Security. It turns out that the proofs $\pi$ for joiner security also allow us to prove member security of our construction under weaker assumptions. In particular, we only require a notion of simulation-soundness for $\textit{mt}$ where extraction is done after all simulations. Recall that a co-CDH instance consists of $u = g^x$, $v = g^r\in \mathbb {G}$ and $\hat{u} = h^x\in \hat{\mathbb {G}}$ and the goal is to compute $w=g^{xr}$. In the security proof of DHIES, the reduction embeds u as the public key and v as the ciphertext and searches for w among the random oracle queries made by the adversary. Using co-CDH (rather than CDH) the reduction can efficiently find $w=g^{xr}$ the pairing ${\text {e}}$, by checking if ${\text {e}}(v, \hat{u}) {\mathop {=}\limits ^{{}_?}}{\text {e}}(w,h)$.

Our reduction for UKEM embeds u as some (honestly updated) public key and v as some ciphertext it hopes the adversary breaks. However, v may not be created for u but for some $u'=u\cdot g^{d'}$ derived from u by the adversary, who needs to provide proofs $\textit{mt}$ and $\textit{jt}$ for $u'$. The reduction thus searches the random oracle queries for a value $w'=g^{(x+d')r}$. It could do so by extracting $d'$ from the proof of knowledge $\textit{mt}$. However, using $\pi = h^{d'}$, it can directly check ${\text {e}}(v, \hat{u}\cdot \pi ) {\mathop {=}\limits ^{{}_?}}{\text {e}}(w',h)$ without extracting anything at all. Extraction of the value $d'$ is then only needed when a CDH solution is found (and the reduction stops): computing $w:= w'/v^{d'} = g^{(x+d')r}/g^{rd'}$ yields the co-CDH solution $g^{xr}$.

Efficiency of Our Scheme. We describe the efficiency profile of our scheme when instantiated with the BLS12-381 curve [SKSW22, Bow], which is a concrete 128-bit-secure instance of a BLS curve [BLS04]. It is equipped with an asymmetric pairing from source groups $\mathbb {G}\times \hat{\mathbb {G}}$ to target group $\mathbb {G}_T$. Elements of $\mathbb {G}$ and $\hat{\mathbb {G}}$ are of size 48 B and 96 B respectively. As a NIZK we use a Schnorr proof of knowledge of the discrete log of elements in $\mathbb {G}$, which results in proofs of length 96 B. Based on this, in our scheme, public keys are 48 B, ciphertexts are 48 B and both joiner and member tags are 96 B. As seen in Table 2 this represents a very significant improvement over all CCA-secure UPKE (and UKEM) schemes to date (despite the new scheme satisfying a considerably stronger security notion).

For example, using UPKE in rTreeKEM to achieve insider security involves sending multiple tuples of the form $(\textit{pk}, \textit{ctxt}, t)$ where t is either an update token $\textit{up}$ or a joiner and member tag pair $(\textit{jt}, \textit{mt})$, depending on which UPKE syntax is used and $\textit{ctxt}$ is a ciphertext under the previous key. The tuples of the new UPKE construction in this work are $<1.5\%$ the size of those of [HLP22]. For other CCA-secure schemes with publicly verifiable updates, the tuples are orders of magnitude larger still (despite none of these schemes providing forking or joiner security like the new construction).

We note that in our scheme, neither key generation, encapsulation nor decapsulation use pairing operations. One pairing is computed during each of the public key validation algorithms (which is run by parties holding the secret key before decapsulation as well).

Further Results. In the full version, we discuss extensions of our security model and efficiency improvements of the construction. We also dive into details of the impact of using variants of UPKE, including ours and less secure ones from the literature, on the security of MLS.

2 Preliminaries

Bilinear Groups. Our scheme will be defined over a bilinear group with an asymmetric pairing, that is, a tuple $(p,\mathbb {G},\hat{\mathbb {G}},\mathbb {G}_T,g,h,{\text {e}})$, where $\mathbb {G}$ and $\hat{\mathbb {G}}$ are groups of prime order p generated by g and h, respectively, and ${\text {e}}:\mathbb {G}\times \hat{\mathbb {G}}\rightarrow \mathbb {G}_T$ is a non-degenerate (i.e., ${\text {e}}(g,h)$ generates $\mathbb {G}_T$) bilinear map (i.e., for all $a,b\in \mathbb {Z}_p$: ${\text {e}}(g^a,h^b)={\text {e}}(g,h)^{ab}$).

The security of our scheme relies on the hardness of the co-discrete-logarithm problem in bilinear groups, defined as follows. We also state co-CDH [BLS01].

Definition 1 (co-DL)

Let $\mathcal {G}=(p,\mathbb {G},\hat{\mathbb {G}},\mathbb {G}_T,g,h,{\text {e}})$ be a bilinear group. The advantage of an adversary $\mathcal A$ in solving the co-DL problem over $\mathcal {G}$ is defined as

Definition 2 (co-CDH)

Let $\mathcal {G}=(p,\mathbb {G},\hat{\mathbb {G}},\mathbb {G}_T,g,h,{\text {e}})$ be a bilinear group. The advantage of an adversary $\mathcal A$ in solving the co-CDH problem over $\mathcal {G}$ is defined as

For any $u=g^x$, $v=g^r$, we denote a CDH solution $w=g^{xr}$ by $w={\text {DH}}(u,v)$.

The Algebraic Group Model. We analyze our scheme in the algebraic group model (AGM) [FKL18], which assumes that an adversary is algebraic, meaning that it computes any group element it outputs as a linear combination of the group elements it was given. More precisely, if the adversary, given input $g:=u_0,u_1,\dots ,u_k\in \mathbb {G}$, outputs a group element $v\in \mathbb {G}$, then it must have computed v as $v=u_0^{\alpha _0}\cdots u_k^{\alpha _k}$ for some $\alpha _0,\dots ,\alpha _k$. Formally, the AGM assumes that such coefficients $\alpha _i$, i.e., the “representation” of v are output by the adversary. The following is implicit in [FKL18]; we include a proof in the full version.

Lemma 1

In the algebraic group model, co-DL tightly implies co-CDH. In particular, for any algebraic adversary $\mathcal A$ against co-CDH in $\mathcal G$, there exists $\mathcal B$ against co-DL in $\mathcal G$ with approximately the same running time as $\mathcal A$ s.t. $\textsf{Adv}^{\mathsf{co-DL}}_{\mathcal {G}}(\mathcal B) \ge \textsf{Adv}^{\mathsf{co-CDH}}_{\mathcal {G}}(\mathcal A)$.

Simulation-Extractable Zero-Knowledge Proofs. Our UKEM scheme uses a proof system $\textsf {PoL}$ (“proof of logarithm”) for statements of the form $\theta :=(u,u')$ proving knowledge of a witness d s.t. $u'/u=g^d$. Formally, $\textsf {PoL}$ may use a random oracle H and comprises the following algorithms: $\tau \leftarrow \textsf {PoL.Prove}_{H}((u, u'), d)$ outputs a proof $\tau$ and $0/1\leftarrow \textsf {PoL.Verify}_{H}((u,u'), \tau )$ verifies $\tau$.

We require two security notions: Zero-knowledge (in the random oracle model) means that the reduction, which can program the random oracle H, can create proofs $\tau _i$ for statements $\theta _i$ without knowing a witness, using an algorithm $\textsf {PoL.Simulate}_{H}$. The programmed random oracle and simulated proofs are, together, indistinguishable from a fresh random oracle and proofs computed honestly via $\textsf {PoL.Prove}_{H}$ using a witness. We denote by $\epsilon ^\text {sim}_{\textsf {PoL},n}$ the simulation error of $\textsf {PoL}$ when simulating at most n proofs.

Strong Simulation Extractability (sSE) is an adaptation of strong simulation soundness [Sah99] to proofs of knowledge [DP92]. It is defined via the following game: an adversary $\mathcal A$ has access to random oracle H and an oracle that, on input a statement $\theta _i$ of $\mathcal A$’s choice, returns a simulated proof $\tau _i$ (and programs H as needed). Eventually, $\mathcal A$ returns a statement/proof pair $(\theta ^*,\tau ^*)\notin \{(\theta _i,\tau _i)\}_i$. If $\tau ^*$ is a valid proof for $\theta ^*$ (using the final programmed version of H) then a witness for $\theta ^*$ can be extracted from $\mathcal A$. (The notion is strong since after querying a simulated proof for a statement, a different proof for the same statement must be extractable.) We require a multi-extraction version of sSE, in which, after having queried simulated proofs, the adversary returns several valid pairs $(\theta ^*_i,\tau ^*_i)$ with $\{(\theta ^*_i,\tau ^*_i)\}_i\cap \{(\theta _i,\tau _i)\}_i=\emptyset$ and one can extract witnesses for all statements $\theta ^*_i$. We denote by $\epsilon _{\textsf {PoL},n}^\text {ext}(\mathcal A)$ the advantage of the adversary $\mathcal A$ in breaking simulation extractability of $\textsf {PoL}$ when returning at most n proofs.

Schnorr Signatures. (Key-prefixed) Schnorr signatures are defined over a group $\mathbb {G}$ of order p and a hash function $H:\{0,1\}^*\rightarrow {\mathbb Z_p}$, modeled as a random oracle. Using signing key $x\in {\mathbb Z_p}$, a signature on a message $m\in \{0,1\}^*$ is computed by sampling and returning

$$ (v:=g^r,s:= (r+cx) \bmod p) \quad \text {with} \quad c:=H(v,g^x,m). $$

A signature (v, s) is valid for message m under public key $u=g^x$ iff $g^s = v\cdot u^c$ with $c=H(v,u,m)$.

In the combination of the random oracle model and the algebraic group model, [FO22] show that Schnorr signatures are sSE zero-knowledge proofs of knowledge of the logarithm of the public key. That is, they are proofs of knowledge (of the witness) for the NP-relation $\{((u,m),x)\,|\,u=g^x, m\in \{0,1\}^*\}$.

Proofs for statements $(u_i,m_i)$ can be simulated by programming the random oracle (as done in the original security proof for Schnorr [PS00]). Suppose an algebraic adversary $\mathcal A$ receives simulated proofs $(v_i, s_i)$ for statements $(u_i, m_i)$ of its choosing and then outputs a valid statement/proof pair $((u^*, m^*), (v^*, s^*)) \notin \{((u_i, m_i), (v_i, s_i))\}$. Then, [FO22] showed that from the representations for the group elements $u_1,u_2,\dots ,u^*$ and $v^*$, which $\mathcal A$ outputted during the game, one can efficiently compute a witness for the statement $(u^*, m^*)$ with overwhelming probability.⁹ In particular, extraction is straight-line and we can extract witnesses for multiple proofs produced during a single execution of an adversary. Thus, Schnorr signatures are multi-extraction sSE proofs in the ROM and AGM, which we formally prove in the full version.

The proof system $\textsf {PoL}$ for member tags is defined as taking input a statement $(u,u')$ and a witness $d=\log (u'/u)$ and returning a Schnorr signature under key $u'/u$ on the message $(u,u')$. Then, sSE guarantees that after receiving simulated proofs for pairs $(u_i,u'_i)$, if the adversary returns a new valid statement/proof pair $((u_*,u'_*),(v_*,s_*))$, we can extract d such that $u'_*/u_* = g^d$.

3 Updatable Key Encapsulation (UKEM)

3.1 Functionality

Intuitively, a UKEM scheme is a key encapsulation mechanism with the following modifications. First, on input a public key $\textit{pk}_i$, the $\textsf {Encaps}$ algorithm outputs – in addition to the key $K$ and the ciphertext c – the updated public key $\textit{pk}_{i+1}$. Accordingly, on input $\textit{sk}_i$, the $\textsf {Decaps}$ algorithm outputs – in addition to $K$ – the updated secret key $\textit{sk}_{i+1}$. This is analogous to any UKEM/UPKE with short syntax from the literature.

Second, $\textsf {Encaps}$ also outputs a “member tag” $\textit{mt}_{i+1}$ which can be used by entities holding $\textit{pk}_i$ to validate $\textit{pk}_{i+1}$. In particular, running $\textsf {Verify}_\textsf{mt}(\textit{pk}_i, \textit{pk}_{i+1}, \textit{mt}_{i+1})$, such entities can verify that if $\textit{pk}_i$ is “honest” then $\textit{pk}_{i+1}$ is so, too. In MLS (more precisely, rTreeKEM [ACDT20]), $\textsf {Verify}_\textsf{mt}$ is run by members (not joiners) who do not know $\textit{sk}_i$ but know and have validated $\textit{pk}_i$.

Third, $\textsf {Encaps}$ also generates a “joiner tag” $\textit{jt}_{i+1}$ which can be used by entities holding $\textit{pk}_0$ to validate $\textit{pk}_{i+1}$: running $\textsf {Verify}_\textsf{jt}(\textit{pk}_0, \textit{pk}_{i+1}, \textit{jt}_{i+1})$, such entities can verify that if $\textit{pk}_0$ is “honest” then $\textit{pk}_{i+1}$ is so, too. In MLS, $\textsf {Verify}_\textsf{jt}$ is run by joiners after checking that $\textit{pk}_0$ was signed by the member who generated it using $\textsf {KeyGen}$. Moreover, $\textsf {Encaps}$ takes the last joiner tag $\textit{jt}_i$ as input.

$\textsf {Decaps}$ takes additional input $\textit{pk}_{i+1}$ and should output $\bot$ if it does not “match” $\textit{sk}_{i+1}$. In MLS, members who do know $\textit{sk}_i$ can thus reject “incorrect” (e.g. adversarially chosen) $\textit{pk}_{i+1}$.

Formally, a UKEM scheme consists of the following algorithms:

• Key Generation. $\textsf {KeyGen}(\kappa ) \rightarrow (\textit{pk}_0, \textit{sk}_0, \textit{jt}_0)$, on input the security parameter, outputs a key pair $(\textit{pk}_0, \textit{sk}_0)$ and the first joiner tag $\textit{jt}_0$.

• Encapsulation. $\textsf {Encaps}(\textit{pk}_i, \textit{jt}_i) \rightarrow (K, c, \textit{pk}_{i+1}, \textit{mt}_{i+1}, \textit{jt}_{i+1})$ takes as input the current public key and joiner tag and returns an encapsulated key $K$, a ciphertext c, an updated public key $\textit{pk}_{i+1}$, a new member tag $\textit{mt}_{i+1}$ and an updated joiner tag $\textit{jt}_{i+1}$.

• Verification of member tags. $\textsf {Verify}_\textsf{mt}(\textit{pk}_i, \textit{pk}_{i+1}, \textit{mt}_{i+1})\rightarrow 0/1$ verifies the update from $\textit{pk}_i$ to $\textit{pk}_{i+1}$ using the tag $\textit{mt}_{i+1}$.

• Verification of joiner tags. $\textsf {Verify}_\textsf{jt}(\textit{pk}_0, \textit{pk}_{i+1}, \textit{jt}_{i+1})\rightarrow 0/1$ verifies the update from $\textit{pk}_0$ to $\textit{pk}_{i+1}$ using the tag $\textit{jt}_{i+1}$.

• Decapsulation. $\textsf {Decaps}(\textit{sk}_i, c, \textit{pk}_{i+1})\rightarrow (K, \textit{sk}_{i+1}) / \bot$ outputs the decapsulated key $K$ and the updated secret key $\textit{sk}_{i+1}$, but only if $\textit{pk}_{i+1}$ matches $\textit{sk}_{i+1}$.

Using UKEM Schemes. Importantly, $\textsf {Decaps}$ does not validate any tags. Therefore, applications using a UKEM scheme should always run $\textsf {Verify}_\textsf{mt}$ and $\textsf {Verify}_\textsf{jt}$ before $\textsf {Decaps}$. This is reflected in our security notion.

3.2 Security

The $\textsf {IND-CCA}$ security of UKEM schemes is formalized by the experiment in Fig. 1.

Fig. 1.

The experiment formalizing UKEM $\textsf {IND-CCA}$ security. By default, all variables are initialized to $\bot$. We use ${\textbf {req}}\ \textit{condition}$ to denote that if condition is false, then the current function, and any function calling it, stops and returns $\bot$.

Intuitively, during the experiment, a tree is created where each node is identified by an integer i and has a public key $\textit{pk}_i$ and a joiner tag $\textit{jt}_i$. The root is identified by $i=0$. Each non-root node has a parent $\textit{par}_i$ and a member tag $\textit{mt}_i$. Further, some nodes have a secret key $\textit{sk}_i$. If a node has a secret key, we call it full, and otherwise we call it a half node.

The root node $i=0$ is created by the challenger at the beginning of the experiment. Its public key $\textit{pk}_0$, secret key $\textit{sk}_0$ and joiner tag $\textit{jt}_0$ are generated using $\textsf {KeyGen}$ (the root is thus a full node). All other nodes j are created by updating existing nodes in one of three ways:

• 1. When the adversary $\mathcal A$ calls the oracle Enc(i), the challenger creates a child j of i by running $\textsf {Encaps}$. If i is a full node, j is also a full node with secret key generated by running $\textsf {Decaps}$.

• 2. A child of i with a possibly “adversarial” public key may be created when $\mathcal A$ calls the oracle Dec$(i, c, \textit{pk}', \textit{mt}', \textit{jt}')$. In such case, the challenger verifies $\textit{mt}'$ and $\textit{jt}'$ and, if the check passes, creates the node j using these values. If i is a full node and $\textsf {Decaps}(\textit{sk}_i, c, \textit{pk}')$ outputs $(K,\textit{sk}_j)$ (and not $\bot$), then j is also a full node with secret key $\textit{sk}_j$; in that case, $\mathcal A$ also receives $K$, which reflects CCA-security. Otherwise, j is a half node. Observe that j is a half node if $\mathcal A$ provides correct (publicly verifiable) tags but c inconsistent with $\textit{pk}'$ (which is not publicly verifiable).

• 3. A node can be created during a challenge call. We address such calls next. There are two challenge oracles: member challenge MChal and joiner challenge JChal. Without loss of generality, $\mathcal A$ can only call one of them, and only once.

Member Security. Consider the case that $\mathcal A$ calls MChal, which means that the notion implies security for group members when used in a secure messaging application. On query MChal$(i^*)$, the challenger creates a child $j^*$ of $i^*$ just like during an Enc query creating a “real” key $K^{(1)}$. $\mathcal A$ gets either $K^{(1)}$ or a random and independent key $K^{(0)}$ and has to decide which is the case. It also receives the resulting tags, public key and the ciphertext $c^*$. To disable trivial wins, on inputs i and c the Dec oracle returns $\bot$ if $\textit{pk}_{i}= \textit{pk}_{i^*}$ and $c = c^*$.

Furthermore, our notion implies forward secrecy by giving $\mathcal A$ access to an oracle Rev, which reveals secret keys (of full nodes). In particular, $\mathcal A$ can ask for the secret key of any node outside the challenge set of $i^*$, which consists of three parts. First, the base of the challenge set, which is the path from the root 0 to $i^*$. Clearly, revealing the secret key for any such node would allow $\mathcal A$ to trivially win by computing the secret key of $i^*$ by running $\textsf {Decaps}$ sequentially on the ciphertexts between the corrupted and the challenged node, and then decapsulating $c^*$. This base is extended to extd-base, which also includes duplicates, i.e., any nodes that have the same public key and tags as a node in base.¹⁰

Finally, the challenge set contains branches, which are nodes reachable from extd-base via nodes created by Dec queries. This is where our notion does not formalize optimal security: there exist UKEM schemes, notably the ones based on HIBE that achieve security even when $\mathcal A$ can corrupt keys on branches. However, we are not aware of any efficient schemes that achieve this. Observe that the secret keys of nodes on branches are generated by updating a secret key on the challenge path (or a duplicate node) with updates generated by $\mathcal A$. Therefore, for optimal security we would need a mechanism that does not allow $\mathcal A$ to undo its updates, which resembles PPKE.

We note that $\mathcal A$ is allowed to ask for the secret key for $j^*$ created by MChal, which corresponds to the fact that in typical UPKE security notions [DKW21, HPS23, HLP22, AW23] the challenge oracle returns the updated secret key. However, $\mathcal A$ can also obtain many other keys, e.g., any node created by Enc and not on the challenge path (and all their children).

Joiner Security. Next, consider the case that $\mathcal A$ calls JChal, formalizing a notion that implies security for joiners when used in a secure messaging application. On query JChal$(\textit{pk}',\textit{jt}')$, the challenger verifies $\textit{jt}'$ for $\textit{pk}'$ w.r.t. the (honest) $\textit{pk}_0$ and, if the check passes, runs $\textsf {Encaps}$ on $\textit{pk}'$ to generate the “real” key $K^{(1)}$. As for member security, $\mathcal A$ is also given the resulting ciphertext, public key and tags. $\mathcal A$’s goal is to distinguish $K^{(1)}$ from a random and independent $K^{(0)}$. To disable trivial wins, on inputs i and c the Dec oracle returns $\bot$ if $\textit{pk}_{i}= \textit{pk}'$ and $c = c^*$.

Reveal queries are more restricted for joiner security than for member security. In particular, the challenge set base now contains all nodes generated before the call to JChal was made (which is thus a superset of the set base in the MChal setting). Analogously to member security, $\mathcal A$ is not allowed to corrupt keys for nodes in the set base, any duplicates of such nodes and branches (i.e., nodes derived from these via Dec queries).

The above restriction cannot be relaxed without enabling “trivial” attacks against any correct scheme (with our syntax). To illustrate this, consider the following adversary $\mathcal A$. By calling Enc(0) twice, $\mathcal A$ generates two children of node 0 with keys $\textit{pk}_1$, $\textit{pk}_2$ and tags $\textit{jt}_1$, $\textit{jt}_2$. Then by running $\textsf {Encaps}(\textit{pk}_1, \textit{jt}_1)$ (possibly repeating this to create a longer path), $\mathcal A$ computes a new pair $(\textit{pk}',\textit{jt}')$ on its own and submits it to its JChal oracle. If $\mathcal A$ was allowed to query Rev(1), it could then, by running $\textsf {Decaps}$ (possibly consecutively), compute the secret key for $\textit{pk}'$.

In general, $\textit{pk}'$ may have been derived via $\textsf {Encaps}$ from any $\textit{pk}_i$ that $\mathcal A$ saw before generating $\textit{pk}'$. Our restriction thus disallows Rev(i) for all such $\textit{pk}_i$, including $\textit{pk}_0$, $\textit{pk}_1$ and $\textit{pk}_2$ in the above example, even though corrupting $\textit{pk}_2$ would not lead to an attack. However, the challenger cannot identify keys that can be revealed, as the UKEM syntax does not allow to decide, given the challenger’s information, whether $\textit{pk}'$ could not have been derived from them.

Remark 1

One could consider relaxing the above restriction on reveal queries for a UPKE with modified syntax, e.g. with an additional algorithm that decides, given $\textit{pk}'$, $\textit{jt}'$, $\textit{pk}_i$ and $\textit{sk}_i$ (and any other information the challenger has), whether $\textit{pk}_i$ is an ancestor of $\textit{pk}'$. However, implementing such an algorithm seems to require inefficient techniques, such as storing all ancestor public keys in $\textit{jt}'$.

Remark 2

One could imagine achieving stronger joiner security by having JChal$(\textit{pk}',\textit{jt}')$ create an (incomplete) node $i'$ with $\textit{pk}_{i'}=\textit{pk}'$ and $\textit{jt}_{i'}=\textit{jt}'$ and allowing the adversary $\mathcal A$ to create a (detached) tree rooted at $i'$. (Note that, by the arguments in Remark 1, we cannot define a parent of $i'$.) However, the resulting notion would be equivalent to our notion. Since $i'$ has no parent, its sub-tree contains only half-nodes without secret keys. So no oracle call related to such nodes uses any secrets unknown to $\mathcal A$ (which are the secret keys of full nodes and the bit b.) Thus, $\mathcal A$ could emulate such oracle calls itself.

Definition 3 (UKEM Security)

[UKEM Security] Let $\text {Exp}^{{ \textsf {IND-CCA}}}(\mathcal A)$ be as defined in Fig. 1. The advantage of an adversary $\mathcal A$ against the $\textsf {IND-CCA}$ security of a UKEM scheme is defined as

$$\begin{aligned} \textsf{Adv}^{\mathsf{IND-CCA}}(\mathcal A) {:}{=}2\Pr \big [\text {Exp}^{{ \textsf {IND-CCA}}}(\mathcal A)=1\big ]-1. \end{aligned}$$

4 Construction

The basis of our construction is the KEM part of DHIES [ABR98], which is basically “hashed ElGamal” for a hash function (modeled as a random oracle) $H:\{0,1\}^*\rightarrow \mathcal K$, the symmetric key space. We use groups $\mathbb {G}$ and $\hat{\mathbb {G}}$ of order p with a pairing ${\text {e}}$ from $\mathbb {G}\times \hat{\mathbb {G}}$ and define the KEM in $\mathbb {G}$: Public keys are of the form $u=g^x\in \mathbb {G}$ and symmetric keys K are encapsulated by choosing , defining the ciphertext as $v := {g}^r$ and deriving $K:=H(u,u^r)$. Using the secret key x, keys are decapsulated from v as $K:=H(g^x,v^x)$.

We extend this to derive updated public keys as follows: using a second random oracle $H_1$, we define $d:=H_1( u,u^r)$ and set the new public key as $u':=u\cdot g^d$. Decapsulation now takes as additional argument the updated key $u'$, derives $d:=H_1( g^x, v^x)$, updates the secret key to $x':= x+d$ and checks if $u'=g^{x'}$. To guarantee that $u'$ was derived correctly (and not chosen freshly with a known secret key), we add a proof of knowledge (PoK) $\tau$ of d, that is, a PoK of the discrete log of $u'/u$. (For our security notion allowing adaptive corruption, $\tau$ needs to be simulation-sound.) This $\tau$ corresponds to $\textit{mt}$ in the UKEM model.

The tag $\textit{jt}$ given to joiners will be a PoK of $D':=x'-x_0$, with $x_0$ the secret key of the root key $u_0$ and $x'$ the secret key of the updated key $u'$. This guarantees that $u'$ is linked to the root key $u_0$. A straightforward solution would be to define $\textit{jt}_j:=(u_1,\textit{mt}_1,\dots ,u_{j-1},\textit{mt}_{j-1},\textit{mt}_j)$To avoid a growth in size depending on the number of updates, we would require a direct proof of knowledge of $D'=x'-x_0$, but the updater will not know $D'$. Our solution is to use “aggregatable” proofs, that is, given a PoK of $D=x-x_0$ corresponding to key u, and deriving $u'$ from u using d, one should be able to derive a PoK of $D':=D+d$.

We use the second pairing source group $\hat{\mathbb {G}}$, generated by h, to instantiate these aggregatable proofs. A proof $\pi$ proving knowledge of the logarithm of an element $u=g^x\in \mathbb {G}$ is defined as $\pi :=h^x\in \hat{\mathbb {G}}$. Using the pairing, a proof can be verified by checking ${\text {e}}(u,h)={\text {e}}(g,\pi )$. Making “knowledge-of-exponent”-type assumptions (in our security proof we will directly rely on the algebraic group model), we get that from any algorithm that returns u and $\pi$ satisfying the above equation, one can extract $x = \log _g u = \log _h \pi$, meaning $\pi$ is a proof of knowledge.

Using these proofs for $\textit{jt}$ allows the updater to transform a proof $\pi$ for u into a proof $\pi ':=\pi \cdot h^d$ for $u'=u\cdot g^d$. A proof $\pi '$ for $u'$ w.r.t. $u_0$ is verified by checking ${\text {e}}(u' / u_0, {h}) = {\text {e}}({g}, \pi ')$. Our UKEM scheme is formally defined in Fig. 2.

5 Security of the Construction

Security of our construction is expressed by the following theorem.

Theorem 1

If $\textsf {PoL}$ is a strongly simulation-extractable proof system and co-CDH holds for $\mathcal {G}$, and assuming adversary $\mathcal A$ is algebraic, then the UKEM construction from Fig. 2 is $\textsf {IND-CCA}$ secure in the ROM. More precisely, for any adversary $\mathcal A$, there exist reductions $\mathcal B$ and $\mathcal B'$ such that

$$\begin{aligned} \textsf{Adv}^{\mathsf{IND-CCA}}(\mathcal A) \le (n_e+2)\big (\epsilon ^\text {sim}_{\textsf {PoL},n_e+1} +\epsilon ^\text {ext}_{\textsf {PoL},n_d}(\mathcal B')+ \textsf{Adv}^{\mathsf{co-CDH}}_{\mathcal {G}}(\mathcal{B})\big ), \end{aligned}$$

where $n_e$ ($n_d$, resp.) are upper bounds on the number of Enc (Dec, resp.) queries made by $\mathcal A$, and $\epsilon ^\text {sim}_{\textsf {PoL},n}$ ($\epsilon ^\text {ext}_{\textsf {PoL},n_d}(\cdot )$, resp.) are the probabilities that simulation of n proofs (extraction from $n_d$ proofs, resp.) fails for PoL.

Fig. 2.

The UKEM construction. Here $H_1$, $H_2$ and $H_3$ are hash functions modeled as random oracles, $\mathcal {G}=(p,\mathbb {G},\hat{\mathbb {G}},\mathbb {G}_T,g,h,{\text {e}})$ is a bilinear group, and $\textsf {PoL}$ is a proof of knowledge system for discrete logarithm statements in $\mathbb {G}$, which might use $H_3$.

Together with Lemma 1, Theorem 1 implies that the security of our construction can be reduced to co-DL. Moreover, using the fact that Schnorr proofs, against algebraic adversaries, are strongly simulation-(multi-)extractable (as we show in the full version) with simulation error $\epsilon ^\text {sim}_{n}:={n}/(p-n_h-n)$ and (multi-)extraction error $\epsilon ^\text {ext}_{n}=n/p$, yields the following:

Corollary 1

Let $\mathcal {G}$ be an asymmetric bilinear group. If $\textsf {PoL}$ is instantiated using Schnorr (cf. Sect. 2) and co-DL holds for $\mathcal {G}$, then the UKEM construction from Fig. 2 is $\textsf {IND-CCA}$ secure in the ROM and the AGM. More precisely, for any algebraic adversary $\mathcal A$, there exist a reduction $\mathcal B$ such that

$$\begin{aligned} \textsf{Adv}^{\mathsf{IND-CCA}}(\mathcal A) \le (n_e+2)\Big (\frac{n_e+1}{p-n_h-n_e- 1} +\frac{n_d}{p} + \textsf{Adv}^{\mathsf{co-DL}}_{\mathcal {G}}(\mathcal B) \Big ) , \end{aligned}$$

where $n_e$, $n_d$ and $n_h$ are upper bounds on the number of, respectively, Enc, Dec and RO queries made by $\mathcal A$.

Proof of Theorem 1. We split the security notion $\textsf {IND-CCA}$ into two: $\textsf {CCA-M}$, in which the JChal oracle is disabled, and $\textsf {CCA-J}$, in which the MChal oracle is disabled. The advantages $\textsf{Adv}^{\mathsf{CCA-M}}$ and $\textsf{Adv}^{\mathsf{CCA-J}}$ are defined accordingly. In Lemmas 2 and 3 we then bound these advantages. Theorem 1 then follows by summing them and letting $\mathcal B$ and $\mathcal B'$ be those adversaries from Lemma 2 or Lemma 3 that have the greater advantage.

5.1 Member Security

We start with the following lemma, which formalizing member security, ${ \textsf {CCA-M}}$, of our UKEM scheme. For space reasons, we defer the full proof to the full version.

Lemma 2

If $\textsf {PoL}$ is a strongly simulation-extractable proof system and co-CDH holds for $\mathcal {G}$, then the UKEM construction from Fig. 2 is $\textsf {CCA-M}$-secure in the ROM. More precisely, for any adversary $\mathcal A$, there exist reductions $\mathcal B$ and $\mathcal B'$ such that

$$\begin{aligned} \textsf{Adv}^{\mathsf{CCA-M}}(\mathcal A) \le (n_e+1)\big (\epsilon ^\text {sim}_{\textsf {PoL},n_e+1} +\epsilon ^\text {ext}_{\textsf {PoL},n_d}(\mathcal B')+ \textsf{Adv}^{\mathsf{co-CDH}}_{\mathcal {G}}(\mathcal B)\big ), \end{aligned}$$

where $n_e$ and $n_d$ are upper bounds on the number of $\mathcal A$’s Enc and Dec queries, resp.

Proof Intuition. Let $\mathcal A$ be any adversary against the $\textsf {CCA-M}$ security of our UKEM scheme. We will construct a reduction $\mathcal B$ against the co-CDH problem, i.e., given $u^*$, $\hat{u}^*$ and $v^*$, $\mathcal B$ must compute $w^*={\text {DH}}(u^*,v^*)$.

We start by adapting the proof idea for the security of the KEM of DHIES in the ROM. $\mathcal B$ embeds $u^*$ as some $u_j$ generated by the challenger, that is, either as $u_0$ or some $u_j$ returned by an Enc(i) query, hoping that $\mathcal A$ calls MChal(j). If this happens, $\mathcal B$ embeds $v^*$ as the ciphertext returned by the oracle. Now as long as $\mathcal A$ never queries $(u^*, w^*)$ to the RO $H_2$ with $w^*={\text {DH}}(u^*,v^*)$, the challenge key $K^{(b)}$ is independently random in both the real and the ideal game, and so no information on b is revealed. On the other hand, querying $(u^*, w^*)$ means $\mathcal A$ solved CDH; moreover, $\mathcal B$ can test this by checking if ${\text {e}}(w^*,h) = {\text {e}}(v^*,\hat{u}^*)$.

Embedding $u^*$. Consider embedding $u^*=g^x$ as $u_{i^*}$ during a query Enc$(p^*)$ (with $p^*$ the parent of $i^*$), which returns ciphertext $v_{i^*}$. Recall that $\textsf {Encaps}$ would compute $d_{i^*} = H_1(u_{p^*},w_{i^*})$ with $w_{i^*}:={\text {DH}}(u_{p^*}, v_{i^*})$ and define $u_{i^*}:=u_{p^*}\cdot g^{d_{i^*}}$ and $\pi _{i^*}:=\pi _{p^*}\cdot h^{d_{i^*}}$ $=h^{x_{i^*}-x_0}$. So when setting $u_{i^*}:=u^*$, the reduction $\mathcal B$ does not know $d_{i^*} = \log (u^*/u_{p^*})$. It thus generates the proof $\tau _{i^*}$ using the simulator guaranteed by zero knowledge of $\textsf {PoL}$. To compute $\pi _{i^*}$, it uses $\hat{u}^*=h^x$ from its co-CDH challenge and sets $\pi _{i^*}:=\hat{u}^*/h^{x_0}$ (and $\pi _{i^*} := h^0$ if $j=0$).

While $\mathcal B$ can simulate the proofs, not knowing $d_{i^*}$, it cannot consistently answer if $\mathcal A$ queries $H_1$ on $(u_{p^*},w_{i^*})$. On the other hand, as long as this query has not been made, the simulation is consistent. Now, to make this query, $\mathcal A$ would have to solve CDH w.r.t. $u_{p^*}$ and $v_{i^*}$. But if $\mathcal A$ ever does so, then $\mathcal B$ should have guessed differently and embedded $u^*$ as $u_{p^*}$ and $v^*$ as $v_{i^*}$ (assuming for the moment there are no Dec queries). $\mathcal B$’s guessing strategy will therefore be to guess the index ${i^*}$ of the first key $u_{i^*}$ generated during a query Enc$(p^*)$ on the path to the challenge for which $\mathcal A$ will solve CDH via an RO query. (Note that $\mathcal B$ does not know the path; it simply guesses the index of an Enc query.)

For now we only considered the case that $\mathcal A$ makes the query MChal$({j^*})$ or Enc$({j^*})$ assuming $u_{j^*}$ was itself created during an Enc query; but $u_{j^*}$ might have been created during a Dec query. That is, the attacked key (i.e., the one for which $\mathcal A$ solves CDH) has been generated by the adversary. Security now relies on the fact that ultimately the attacked key was derived (possibly via many Dec queries) from an honest key, say $u_{i^*}$ (which might be $u_0$).

Since $\mathcal A$ must provide proofs $\tau _i$ for the hops from $u_{i^*}$ to $u_{j^*}$ (where $\tau _i$ proves knowledge of $d_i=x_i-x_{\textit{par}_i}$), $\mathcal B$ can extract the values $d_i$ and sum them to $d_{i^*\rightarrow j^*}:=x_{j^*} - x_{i^*}$, which it can use to “translate” CDH solutions for $u_{j^*}$ to $u_{i^*}$. Thus, it can embed $u^*$ as $u_{i^*}$ and embed $v^*$ as the ciphertext the adversary breaks. A solution $w={\text {DH}}(u_{j^*},v^*)$ then yields a solution $w/(v^*)^{d_{i^*\rightarrow j^*}} = g^{x_{j^*}r}/g^{r(x_{j^*}-x_{i^*})} = {\text {DH}}(u^*,v^*)$.

Our strategy is thus to guess the following index $i^*$: if the first attacked key is $u_{j^*}$, then $i^*$ is the closest ancestor of ${j^*}$ with a public key generated by the challenger. That is, at the latest $i^*={j^*}$ (if ${j^*}$ is generated during an Enc query), and at the earliest $i^*=0$.

Answering Rev Queries. Say $\mathcal B$ embeds $u^*$ as $u_{i^*}$ and consider a query Enc$(i^*)$, which creates a new key $u_j$. If node j turns out not to lie on the challenge path, then $\mathcal A$ is allowed to query Rev(j). However, if $\mathcal B$ ran $\textsf {Encaps}$ to answer the query, setting $u_j:=u^*\cdot g^{d_j}$ with $d_j:=H_1( u_{i^*}, {\text {DH}}(u_{i^*},v_j))$, then it would not know $x_j=\log u_j$ to answer the Rev query.

But recall that $\mathcal B$ hopes that $\mathcal A$ attacks key $u_{i^*}$! Every time Enc or MChal is queried on $i^*$, the reduction thus embeds $v^*$ from its co-CDH challenge into the ciphertext. In particular, using random self-reducibility, $\mathcal B$ chooses a uniform $s_j$ and defines the new ciphertext as $v_j {:}{=}v^* \cdot {g}^{s_j}$. If $\mathcal A$ ever queries $H_1( u_{i^*},w_j)$ for $w_j{:}{=}{\text {DH}}(u_{i^*},v_j)$, the game stops and $\mathcal B$ returns $w^*{:}{=}w_j / (u^*)^{s_j}= g^{x^*(r+s_j)}/g^{x^*s_j} = {\text {DH}}(u^*,v^*)$. On the other hand, as long as no such query is made, $d_j$ is not defined, and thus $\mathcal B$ can simply sample $x_j$, set $u_j:=g^{x_j}$ (which implicitly defines $d_j$) and simulate the proofs $\tau _j$ and $\pi _j$. This way, $\mathcal B$ can then answer the query Rev(j).

The case Enc(i) for an index i whose path from $i^*$ consists of only Dec queries is dealt with similarly: $\mathcal B$ embeds $v^*\cdot {g}^{s_j}$ as $v_j$ and samples $x_j$ freshly. As long as $\mathcal A$ does not query $H_1( u_i,w_j)$ with $w_j={\text {DH}}(u_{i},v_j)$, the simulation is perfect. If the adversary makes that query, it can be translated back to a solution ${\text {DH}}(u^*,v_j)$, and thus to ${\text {DH}}(u^*,v^*)$, by extracting $d_{i^*\rightarrow i}=x_i-x^*$ from the $\tau$-proofs provided by the adversary when making the Dec queries linking $u_{i^*}$ to $u_i$: we have $w^*:= w_j\cdot (u^*)^{-s_j}\cdot v_j^{-d_{i^*\rightarrow i}} = g^{(x^*+d_{i^*\rightarrow i})(r+s_j)}g^{-x^*s_j}g^{-(r+s_j)d_{i^*\rightarrow i}} = {\text {DH}}(u^*,v^*)$.

Extracting from Adversarial Proofs. Simulation-extractability of $\tau$-proofs only lets us extract from proofs computed by the adversary (and not ones created by the simulator). So what happens if the adversary “copies” proofs simulated by the challenger?

In particular, consider the situation where we embedded our challenge key $u^*$ as $u_{i^*}$ and the adversary attacked one of its Dec-descendants $u_{j^*}$. If none of the key/proof pairs $(u_i,\tau _i)$ on the path from ${i^*}$ to ${j^*}$ appear elsewhere in the tree, then the statement/proof pairs are different from those of the simulated proofs, and we can extract their witnesses. On the other hand, assume that on this path, there is a pair $(u_{k^*},\tau _{k^*})$ which appears elsewhere as $(u_{k'},\tau _{k'})$ in the tree. If (and only if) $k'$ was created in a query Enc$(i')$ and $i'$ is a Dec-descendant of $i^*$, then $\tau _{k'}$ was simulated, and thus we cannot extract from $\tau _{k'} = \tau _{k^*}$. (Note that since for every $u_k$ there is a unique valid $\pi _{k}$, we have $(u_{k^*},\tau _{k^*},\pi _{k^*})=(u_{k'},\tau _{k'},\pi _{k'})$.)

However, this just means that we should have guessed differently: assume $k^*$ is the last “copied” node on the path from ${i^*}$ to ${j^*}$. If we had embedded our challenge key $u^*$ as $u_{k^*}$ (when we created it as $u_{k'}$ when answering an Enc query) then we could now solve CDH: since, by assumption, no nodes between $u_{k^*}$ and $u_{j^*}$ are copied, we can extract from their $\tau$-proofs and thus compute $d_{k^*\rightarrow j^*}=x_{j^*}-x_{k^*}$, which lets us shift a CDH solution for $u_{j^*}$ to one for $u_{k^*}$. Note that we would not be able to answer Rev for $k'$ and its Dec-descendants, but such queries are disallowed (as they are part of chall-set, cf. Fig. 1).

Our actual guess strategy is therefore: let $u_{j^*}$ be the first key the adversary attacks during the game; then what is the index of the Enc query that creates the node $(u_{k^*},\tau _{k^*})$ so that when starting from $u_{j^*}$ and moving up Dec-edges, $(u_{k^*},\tau _{k^*})$ is the first key/proof pair created by the challenger during an Enc query (at latest, this is $u_0$).

Answering Dec Queries. We address answering decryption queries Dec(i) for nodes whose secret key is not known to the reduction. These are all nodes whose public key $u^*$ is the embedded co-CDH instance, or any Dec-descendant of such nodes. Here, we again follow the ideas for proving CCA-security of DHIES, namely to inspect the random-oracle table. We moreover use the fact that CDH solutions can be checked via the pairing using the associated proof $\pi _i$: given a ciphertext $v_j$ for key $u_i=g^{x_i}$, we have $K_j = H_2(u_i,w_j)$ with $w_j:={\text {DH}}(u_i,v_j)$ and the latter can be efficiently checked: setting $\hat{u}_i := \pi _i\cdot h^{x_0} = h^{x_i}$ (where $h^{x_0}:=\hat{u}^*$ if $i^*=0$), check if ${\text {e}}(w_j,h){\mathop {=}\limits ^{{}_?}}{\text {e}}(v_j,\hat{u}_i)$.

So to decrypt ciphertext $v_j$ for key $u_i$ we do the following: if there has been a query $(u_i,{\text {DH}}(u_i,v_j))$ to $H_2$, then we return the same key again; if there has not been such a query, we sample a fresh key $K_j$ and (implicitly) program the random oracle: store an entry $(u_i,v_j,\bot ,K_j)$, meaning that $(u_i,{\text {DH}}(u_i,v_j))$ gets mapped to $K_j$. To detail how the Dec queries are answered, we first address programming of the random oracles.

Programming the Random Oracles. Answering Enc, Dec and MChal queries results in defining the entries of the random oracle tables for $H_1$ and $H_2$. The inputs are of the form (u, w), on which $H_1$ outputs d and $H_2$ which outputs K. For certain queries, these entries are partial, since the reduction does not know all inputs/outputs, i.e., the RO is programmed implicitly. The reduction thus stores RO entries of the form $(u,\hat{u},v,w, u', d, K)$, some of whose components can be $\bot$. For $u=g^x$, the (non-$\bot$) values are: $\hat{u}=h^x$, $w=v^x={\text {DH}}(u,v)$, $u'=u\cdot g^d$ and d and K are the outputs of, respectively, $H_1$ and $H_2$, on input (u, w). Note that $\hat{u}$, w and $u'$ are determined by the other values. During Enc and MChal queries, implicit programming happens at the following positions:

• 1. When embedding the key $u^*$ as $u_{i^*}$ for $i^*\ne 0$, letting $p^*:=\textit{par}_{i^*}$, the reduction implicitly defines the oracles at $(u_{p^*},v_{i^*}^{x_{p^*}})$ (where $x_{p^*}$ was chosen by the reduction); $H_1$ is set to $d_{i^*}:=\log (u_{i^*}/u_{p^*})$ (unknown to the reduction) and $H_2$ is set to $K_{i^*}$ (chosen by the reduction). When answering this query, the reduction thus stores the following entry (where $\hat{u}_{p^*} := h^{x_{p^*}}$):

  $$(u_{p^*},\hat{u}_{p^*},v_{i^*},\bot ,{ u_{i^*},}\bot ,K_{i^*}) $$

• 2. For any call of Enc or MChal at position i with $u_i=u^*$ or i being a Dec-descendant of a node with public key $u^*$, the reduction creates $v_j$ (embedding $v^*$ from its co-CDH instance) and $u_j$ ($:= g^{x_j}$ for fresh j) and defines $H_1$ and $H_2$ at position $(u_i,{\text {DH}}(u_i,v_j))$, which is unknown to the reduction. While the reduction chooses the value $K_j$ at this position for $H_2$ (for the MChal query, $K_j$ corresponds to “$K^{(1)}$”), it will not know the value $d_j=\log (u_j/u_i)$ for $H_1$. The reduction thus stores $(u_i,\hat{u}_i,v_j,\bot ,{ u_j,}\bot ,K_j),$ where, as above, $\hat{u}_i = \hat{u}^*$ if $i^*=0$ and $\hat{u}_i := \pi _i\cdot h^{x_0} = h^{x_i}$ otherwise.

For every random-oracle query (u, w) the adversary makes, the reduction checks if $(u,w)=(u_i,{\text {DH}}(u_i,v_j))$ holds when $i=i^*$, or $i=\textit{par}_{i^*}$ or i is a Dec-descendant of $i^*$. It does this by checking $u{\mathop {=}\limits ^{{}_?}}u_i$ and ${\text {e}}(w,h){\mathop {=}\limits ^{{}_?}}{\text {e}}(v_j,\hat{u}_i)$. (Note that such queries to $H_1$ cannot be answered, since the reduction does not know $d_j=\log (u_j/u_i)$.)

If this is the case for $i=\textit{par}_{i^*}$, the reduction stops, since the guess $i^*$ was wrong, as $\textit{par}_{i^*}$ would have been the right guess. If it happens for $i^*$ or any of its Dec-descendants, the reduction stops and returns the co-CDH solution (computed as described above). Otherwise, fresh values d and K are sampled and a new entry $(u,\bot ,\bot ,w,u\cdot g^d,d,K)$ is created. We say that in this case the RO was explicitly programmed.

Details of Answering Dec Queries. Let us consider a query Dec$(i', v', u', \tau ', \pi ')$. If $\tau '$ and $\pi '$ are valid, a new (for now: half-)node is created. If $i'$ is a full node, the oracle would do the following: run $\textsf {Decaps}$ on $\textit{sk}_{i'}$, that is, compute $d':=H_1(u_{i'},{\text {DH}}(u_{i'},v'))$; check if $u'=u_{i'}\cdot g^{d'}$; if so, return $K:=H_2(u_{i'},{\text {DH}}(u_{i'},v'))$ and declare the new node a full node; else return $\bot$.

If $i'$ is a half-node, then the reduction can simulate the Dec oracle perfectly, as the latter uses only public values. Moreover, if $i' \notin \textit{chall-set}$, then the reduction knows $\textit{sk}_{i'}$ and can thus simulate the oracle perfectly as well. For $i'\in \textit{chall-set}$ and $i'$ being a full node, the reduction uses its extended RO table as follows:

• (i) If there is an entry $(u_{i'}, *, v', \bot , u'', d, K)$ for some $u''$, d (where possibly $d=\bot$) and K, then the RO was already implicitly programmed at $(u_{i'},{\text {DH}}(u_{i'},v'))$ (either during and Enc or MChal query as described above, or during a Dec query as described below). The reduction checks if $u'=u''$ (as $\textsf {Decaps}$ does) and if so, it declares the new node a full node and returns K; else, it declares the new node a half node and returns $\bot$.

• (ii) Else if there is an entry $(u_{i'},\bot , \bot , w, u'', d, K)$ for some $u''$ and $w={\text {DH}}(u_{i'},v')$, which can be checked using $\hat{u}_{i'}=\pi _{i'}\cdot h^{x_0}$, then the RO was already explicitly programmed at $(u_{i'},{\text {DH}}(u_{i'},v'))$. As above, the reduction checks if $u'=u''$ (as $\textsf {Decaps}$ does); if so, it declares the new node a full node and returns K; else, it declares the new node a half node and returns $\bot$.

• (iii) If none of the above apply, then sample d and K, create new entry $(u_{i'},\hat{u}_{i'},v',\bot ,u_{i'}\cdot g^d,d,K)$ and proceed as in $\textsf {Decaps}$. (Note that, with overwhelming probability, this will return $\bot$, since d will be inconsistent with $u_{i'}$ and $u'$.)

Finally, note that the only RO query that would reveal the challenge bit b is querying $H_2$ on $(u_{i_c},{\text {DH}}(u_{i_c},v_{j_c}))$, where $i_c$ is the value queried to MChal and $j_c$ the current value of j at that point. “Explicit” queries are dealt with by our guessing strategy: if the guess $i^*$ was correct then such a query is used to solve co-CDH. On the other hand, “implicit” queries via the Dec oracle cannot occur, since this would correspond to $\text {Dec}(i', v', u', \tau ', \pi ')$ with $u'=u_{i_c}$ and $v'=v_{i_c}$, which is forbidden (as trivial wins).

5.2 Joiner Security

We next state the following lemma, which formalizes the joiner security, ${ \textsf {CCA-J}}$, of our UKEM scheme. The full proof is deferred to the full version.

Lemma 3

Let $\mathcal {G}$ be an asymmetric bilinear group. If $\textsf {PoL}$ is a simulation-extractable proof system, co-CDH holds for $\mathcal {G}$ and adversary $\mathcal A$ is algebraic in $\hat{\mathbb {G}}$, the UKEM construction from Fig. 2 is $\textsf {CCA-J}$ secure in ROM. More precisely, for any algebraic adversary $\mathcal A$, there exist reductions $\mathcal B$ and $\mathcal B'$ such that

$$\begin{aligned} \textsf{Adv}^{\mathsf{CCA-J}}(\mathcal A) \le \epsilon ^\text {sim}_{\textsf {PoL},n_e} +\ \epsilon ^\text {ext}_{\textsf {PoL},n_d}(\mathcal B') + \textsf{Adv}^{\mathsf{co-CDH}}_{\mathcal {G}}(\mathcal B), \end{aligned}$$

where $n_e$ and $n_d$ are upper bounds on the number of $\mathcal A$’s Enc and Dec queries, resp.

Proof Intuition. We build upon the proof of Lemma 2 (member security). The only difference is that instead of MChal, the adversary $\mathcal A$ now calls JChal$(u', \pi ')$. Accordingly, instead of embedding $v^*$ in the ciphertext returned by the MChal oracle, the reduction $\mathcal B$ against co-CDH now embeds $v^*$ in the ciphertext $v'$ returned by JChal; specifically, using random self-reducibility, it sets $v' := v^* \cdot g^{s'}$ for a random $s'$. The security of $v'$ encrypted to $u'$ hinges on the link between $u'$ and the honest $u_0$ via the associated proof $\pi '$. More precisely, unless $\mathcal A$ queries $H_2$ on $w' := {\text {DH}}(u',v')$, both the “random” key $K^{(0)}$ and the “real” key $K^{(1)} = H_2(u',w')$ are random and independent, so $\mathcal A$’s advantage is 0. On the other hand, if $\mathcal A$ makes such an RO query, $\mathcal B$ can compute the co-CDH solution by extracting from the proof $\pi '$ as follows.

Extracting from the $\pi '$ Proof. Since $\mathcal A$ is algebraic, when it calls JChal$(u', \pi ')$, $\mathcal B$ can extract the representation of $\pi '$ as a linear combination of all $\hat{\mathbb {G}}$ elements given to $\mathcal A$ so far, which are (precisely) the $\pi _j$ proofs returned by the Enc oracle. $\mathcal B$ knows the logarithm of each such $\pi _j$ because it emulates the Enc oracle by running $\textsf {Encaps}$ honestly. Thus, $\mathcal B$ can use the representation of $\pi '$ and the known logarithms to compute the logarithm $d'$ of $\pi '$. Since $\pi '$ is valid, $d'$ is equal to the logarithm of $u' / u_0 = u' / u^*$. Thus $\mathcal B$ can use $d'$ and $s'$ chosen when embedding $v'$ as $v' = v^* \cdot g^{s'}$ to translate $w'={\text {DH}}(u',v') = {\text {DH}}(u^*\cdot g^{d'},v^*\cdot g^{s'})$ from $\mathcal A$’s RO query to the solution $w^*={\text {DH}}(u^*,v^*)$ analogously to the reduction for member security: $w^* = w' \cdot (u^*)^{-s'}\cdot (v')^{-d'}$.

Answering Rev Queries. If, after the JChal call, $\mathcal A$ makes a query Enc(i) creating a node j, then it is allowed to query Rev(j). $\mathcal B$ deals with such queries the same way as the reduction for member security: It samples the secret key $x_j$ itself. This implies that $\mathcal B$ cannot answer a query $(u_i,{\text {DH}}(u_i,v_j))$ to $H_1$, which should return $d_j=\log (g^{x_j}/u_i)$. But again, such a query would allow $\mathcal B$ to solve its co-CDH instance, had it embedded $v^*$ in $v_j$.

In more detail, recall that Rev queries are allowed for nodes outside of chall-set which is the dec-closure of all nodes (and their duplicates) created before the JChal call. If after the JChal query $\mathcal A$ queries Enc(i) for some $i \in \textit{chall-set}$, $\mathcal B$ samples $x_j$ itself and returns $v_j = v^* \cdot g^{s_j}$ for a random $s_j$ together with simulated proofs $\pi _j$ and $\tau _j$. If $\mathcal A$ later “breaks” $v_j$ by making an RO query $(u_i,w_j)$ with $w_j={\text {DH}}(u_i,v_j)$ then $\mathcal B$ translates $w_j$ to the co-CDH solution ${\text {DH}}(u^*,v^*)$: it does so by collecting and summing all d values on the path from node 0 to node i: for any Dec edge, $\mathcal B$ extracts d from the $\tau$ proof provided by $\mathcal A$; for any Enc edge, $\mathcal B$ generated d itself, as all Enc edges in chall-set were created before JChal and hence by running $\textsf {Encaps}$. Knowing $d_{0\rightarrow i}$ s.t. $u_i = u_0 \cdot g^{d_{0\rightarrow i}} = u^* \cdot g^{d_{0\rightarrow i}}$ and $s_j$ s.t. $v_j = v^*\cdot g^{s_j}$, the reduction can compute ${\text {DH}}(u^*,v^*) = {\text {DH}}(u_i,v_j)\cdot (u^*)^{-s_j} \cdot v_j^{-d_{0\rightarrow i}}$.

Observe that for the above “simulated” edges, $\mathcal B$ does not know the logarithm of the simulated $\pi _j$. This does not affect extraction from the proof $\pi '$ above, since extraction is done when JChal is called, thus before any proofs are simulated.

Extracting from Adversarial $\tau$ Proofs. Say $\mathcal A$ breaks some $v_j$ embedded in the response to Enc(i) as described above. Simulation-extractability allows $\mathcal B$ to extract from $\tau$-proofs for Dec edges as long as these were not simulated. However, $\mathcal A$ could copy a node with a simulated proof via a Dec query. Therefore, we need to modify $\mathcal B$’s strategy, similarly to the proof of member security.

Consider the following example : $\mathcal A$ starts by calling JChal and then queries Enc(0) creating node 1, at which point $\mathcal B$ picks $x_1$ and sets $u_1 = g^{x_1}$ as described above. Now $\mathcal A$ forwards the outputs of the above Enc query to Dec(0), creating node 2 with $(u_2,\tau _2) = (u_1,\tau _1)$. Finally, $\mathcal A$ queries Enc(2), which creates node 3. Since node 2 is in chall-set, $\mathcal B$, following the above strategy, would choose a fresh key $x_3$ for $u_3:=g^{x_3}$. However, if $\mathcal A$ queries $(u_2, {\text {DH}}(u_2,v_3))$ to $H_1$, then $\mathcal B$ would not be able to answer, since it does not know $d_3:= x_3-x_2$; moreover, the value ${\text {DH}}(u_2,v_3)$ is of no use, as $\mathcal B$ can compute it itself as $v_3^{x_2}=v_3^{x_1}$. $\mathcal B$ should thus just have computed $u_3$ honestly as $u_3 = u_2\cdot g^{d_3}$. It could then still answer Rev(3), as required, since it knows $x_3=x_1+d_3$.

$\mathcal B$’s strategy is thus the following: $u^*$ is embedded as $u_0$, and before the JChal query, every Enc query is answered by running $\textsf {Encaps}$ (and thus $\mathcal B$ does not know the resulting secret key). After the JChal query, every query Enc(i) creating node j must be answered in a way so $\mathcal B$ knows the resulting secret key $x_j$. We distinguish two cases: (1) $\mathcal B$ knows $x_i$, or $x_k$ for any Dec-“ancestor” k of i: then $\mathcal B$, knowing $x_i$, runs $\textsf {Encaps}$, and will thus know $x_j$. (2) Else $\mathcal B$ sets the resulting key as $u_j:=g^{x_j}$ and $v_j:=v^*\cdot g^{s_j}$ for fresh $x_j$, $s_j$, and simulates the proofs.

Note that for every $i\notin \textit{chall-set}$, $\mathcal B$ either knows $x_i$, or it can compute it by running $\textsf {Decaps}$ between the node k for which it knows $x_k$ and i in order to derive $x_i$. Therefore, $\mathcal B$ can answer all Rev queries for such i.

Moreover, when $\mathcal A$ makes an unanswerable RO query, $\mathcal B$ can use it to break co-CDH. Any such query is of the form $(u_i,w_j={\text {DH}}(u_i,v_j))$ where j is a node created in mode (2) above (for which $\mathcal B$ does not know $d_j$). $\mathcal B$ extracts all d values from the proofs $\tau$ on the path from the root to node i. This must succeed as long as none of the proofs was simulated, which we show next.

Towards a contradiction, assume that for some k on that path, $\tau _k$ for the statement $(u_{\textit{par}_{k}},u_{k})$ was simulated. $\mathcal B$ must have simulated the proof when, after the JChal call, $\mathcal A$ called Enc$(\textit{par}_{k'})$, creating node $k'$ with $u_{k'}=u_k$. However, this means that $\mathcal B$ chose $x_{k'}$ itself, and thus i has a Dec-ancestor with a known secret key, meaning that node j was not created in mode (2), which is a contradiction.

Since $\mathcal B$ can extract all values d and thus compute $d_{0\rightarrow i}$ with $u_i=u^*\cdot g^{d_{0\rightarrow i}}$, and since $v_j=v^*\cdot g^{s_j}$, it can translate ${\text {DH}}(u_i,v_j)$ to ${\text {DH}}(u^*,v^*)$, as done above.