©IACR 2020. This article is a minor revision of the version presented at Asiacrypt 2020 and published bySpringer-Verlag. This is the full version, and available as entry 2020/148 in the IACR eprint archive.

Determining the Core Primitive for OptimallySecure Ratcheting

Fatih Balli1, Paul Rösler2, Serge Vaudenay1

1 LASEC, École polytechnique fédérale de Lausanne{firstname.lastname}@epfl.ch

2 Chair for Network and Data Security, Ruhr University Bochumpaul.roesler@rub.de

Abstract. After ratcheting attracted attention mostly due to practi-cal real-world protocols, recently a line of work studied ratcheting asa primitive from a theoretic point of view. Literature in this line, pur-suing the strongest security of ratcheting one can hope for, utilized forconstructions strong, yet inefficient key-updatable primitives – based onhierarchical identity based encryption (HIBE). As none of these worksformally justified utilizing these building blocks, we answer the yet openquestion under which conditions their use is actually necessary.

We revisit these strong notions of ratcheted key exchange (RKE),and propose a more realistic (and slightly stronger) security definition. Inthis security definition, both the exposure of the communicating parties’local states and the adversary’s ability to attack the executions’ random-ness are considered. While these two attacks were partially considered inprevious work, we are the first to unify them cleanly in a natural gamebased notion.

Our definitions are based on the systematic RKE notion by Poetter-ing and Rösler (CRYPTO 2018). Due to slight (but meaningful) changesto regard attacks against randomness, we are ultimately able to showthat, in order to fulfill strong security for RKE, public key cryptographywith (independently) updatable key pairs is a necessary building block.Surprisingly, this implication already holds for the simplest RKE vari-ant (which was previously instantiated with only standard public keycryptography).

Hence, (1) we model optimally secure RKE under randomness ma-nipulation to cover realistic attacks, (2) we (provably) extract the coreprimitive that is necessary to realize strongly secure RKE, and (3) ourresults indicate under which conditions this primitive is necessary forstrongly secure ratcheting and which relaxations in security allow forconstructions that only rely on standard public key cryptography.

1 Introduction

The term “ratcheting” as well as the underlying concept of continuously updat-ing session secrets for secure long-term communication settings originates fromreal-world messaging protocols [16,18,5,21,17]. In these protocols, first forward-secrecy [18,5,21] and later security after state exposures [17] (also known as

future secrecy, backward secrecy, or post-compromise security) were aimed to beachieved as the exposure of the devices’ local states was considered a practicalthreat. The main motivation behind this consideration is the typical lifetimeof sessions in messaging apps. As messaging apps are nowadays usually run onsmartphones, the lifetime of messaging sessions is proportional to the ownershipduration of a smartphone (typically several years). Due to the long lifetime ofsessions and the mobile use of smartphones, scenarios, in which the local storage– containing the messaging apps’ secret state – can be exposed to an attacker,are extended in comparison to use cases of other cryptographic protocols.

Practical Relevance of Randomness ManipulationIn addition to exposures of locally stored state secrets, randomness for generat-ing (new) secrets is often considered vulnerable. This is motivated by numerousattacks in practice against randomness sources (e.g., [11]), randomness genera-tors (e.g., [23,7]), or exposures of random coins (e.g., [22]). Most theoretic ap-proaches try to model this threat by allowing an adversary to reveal attackedrandom coins of a protocol execution (as it was also conducted in related workon ratcheting). This, however, assumes that the attacked protocol honestly anduniformly samples its random coins (either from a high-entropy source or usinga random oracle) and that these coins are only afterwards leaked to the attacker.In contrast, practically relevant attacks against bad randomness generators orlow-entropy sources (e.g., [11,23,7]) change the distribution from which randomcoins are sampled. Consequently, this threat is only covered by a security model ifconsidered adversaries are also allowed to influence the execution’s (distributionof) random coins. Thus, it is important to consider randomness manipulation(instead of reveal), if attacks against randomness are regarded practically rele-vant.

The overall goal of ratcheting protocols is to reduce the effect of any suchnon-permanent and/or non-fatal attack to a minimum. For example, an ongoingcommunication under a non-fatal attack should become secure as soon as theadversary ends this attack or countermeasures become effective. Examples forcountermeasures are replacing bad randomness generators via software updates,eliminating state exposing viruses, etc. Motivated by this, most widely usedmessaging apps are equipped with mechanisms to regularly update the localsecrets such that only a short time frame of communication is compromisedif an adversary was successful due to obtaining local secrets and/or attackingrandom coins.

Real-World ProtocolsThe most prominent and most widely deployed real-world ratcheting protocol isthe Signal protocol (used by the Signal Messenger, WhatsApp, Facebook Mes-senger, Skype, and others). The analysis of this protocol in a multi-stage keyagreement model1 [8] was the first theoretic treatment of ratcheting in the lit-erature. Cohn-Gordon et al. [8], however, focus on grasping the precise security

1 Please note our distinction between key agreement and ratcheted key exchange proto-cols. The former is run by parties to obtain a symmetric key for a subsequent session

2

that Signal offers rather than generically defining ratcheting as an independentprimitive. While the security provided by Signal is sufficient in most real-worldscenarios, we focus in this work on the theoretic analysis of the (optimally se-cure) primitive ratcheting with respect to its instantiability by smaller buildingblocks.Generic Treatment of Ratcheting as a PrimitiveIn the following we shortly introduce and review previous modeling approachesfor strongly secure ratcheting. We thereby abstractly highlight modeling choicesthat crucially affect the constructions, secure according to these models respec-tively. Specifically, we indicate why some models can be instantiated with onlypublic key cryptography (PKC) – bypassing our implication result – and otherscannot. In Table 1 we summarize this overview.

gen$K

pk

pk

skad adup up

pk skad adup up

pk skc

k kenc$ dec

init$

sA sB

cad adk k

snd$ rcv

sA sB

cad adk k

snd$ rcv

sA sB

cad adk k

snd$ rcv

Fig. 1: Conceptual depiction of kuKEM∗ (on the left) and unidirectional RKE (on theright). ‘$’ in the upper index of an algorithm name denotes that the algorithm runsprobabilistically and ad is associated data.

The initial generic work that considers ratcheted key exchange (RKE) as aprimitive and defines its syntax, correctness, and security (in a yet impracticalvariant) is by Bellare et al. [4]. Abstractly, their concept of ratcheted key ex-change, depicted in the right part of Figure 1, consist of an initialization thatprovides two session participants A and B with a state that can then be used bythem to repeatedly compute new keys in this session (e.g., for use in higher levelprotocols). In their restricted communication model, A is allowed to computenew keys with her state and accordingly send ciphertexts to B who can thencompute (the same) keys with his state. During these key computations, A’s andB’s states are updated respectively (to minimize the effect of state exposures).As B can only comprehend key computations from A (on receipt of a cipher-text) but cannot actively initiate the computation of new keys, this variant was

protocol. The latter is the session protocol that might utilize the initial key and thatcontinuously outputs symmetric keys in the session independent of long-term keys.

3

later called unidirectional RKE [20]. Beyond this restriction of the communica-tion model, the security definition by Bellare et al. only allows the adversaryto expose A’s temporary local state secrets, while B’s state cannot be exposed(which in turn requires no forward-secrecy with respect to state updates by B).Following Bellare et al., Poettering and Rösler [20,19]2 propose a revised secu-rity definition of unidirectional RKE (URKE: allowing also the exposure of B’sstate) and extend the communication model to define syntax, correctness, andsecurity of sesquidirectional RKE (SRKE: additionally allows B to only sendspecial update ciphertexts to A that do not trigger a new key computation buthelp him to recover from state exposures) and bidirectional RKE (BRKE: de-fines A and B to participate equivalently in the communication). With a similarinstantiation as Poettering and Rösler, Jaeger and Stepanovs [13] define securityfor bidirectional channels under state exposures and randomness reveal.

All of the above mentioned works define security optimally with respect totheir syntax definition and the adversary’s access to the primitive execution(modeled via oracles in the security game). This is reached by declaring secretsinsecure iff the adversary conducted an unpreventable/trivial attack againstthem (i.e., a successful attack that no instantiation can prevent). Consequently,fixing syntax and oracle definitions, no stronger security definitions exist.

Relaxed Security NotionsSubsequent to these strongly secure ratcheting notions, multiple weaker formaldefinitions for ratcheting were proposed that consider special properties suchas strong explicit authentication [10], out of order receipt of ciphertexts [2], orprimarily target on allowing efficient instantiations [15,6].

While these works are syntactically similar, we shortly sketch their differentrelaxations regarding security – making their security notions sub-optimal. Du-rak and Vaudenay [10] and Caforio et al. [6] forbid the adversary to performimpersonation attacks against the communication between A and B during theestablishment of a secure key. Thus, they do not require recovery from stateexposures – which are a part of impersonation attacks – in all possible cases,which we denote as “partial recovery” (see Table 1). Furthermore, both worksneglect bad randomness as an attack vector. In the security experiments by Jostet al. [15] and Alwen et al. [2] constructions can delay the recovery from attackslonger than necessary (Jost et al. therefore temporarily forbid the exposure of thelocal state). Additionally, they do not require the participants’ states to becomeincompatible (immediately) on active attacks against the communication.

Instantiations of RatchetingInterestingly, both mentioned unidirectional RKE instantiations that were de-fined to depict optimal security [4,20] as well as bidirectional real-world exam-

2 We explicitly cite the extended version [19] for results that are not captured in theCRYPTO 2018 proceedings [20].

1 ‘Unnecessary’ refers to restrictions beyond those that are immediately implied byoptimal security definitions (that only restrict the adversary with respect to unpre-ventable/trivial attacks).

4

(a) Interaction (b) State Exposure (c) Bad Randomness (d) RecoveryC+ [8] ↔ Always allowed Reveal DelayedB+ [4] → Only allowed for A Reveal ImmediatePR [20] → Always allowed Not considered Immediate

7→ Always allowed Not considered Immediate↔ Always allowed Not considered Immediate

JS [13] ↔ Always allowed Reveal ImmediateDV [10] ↔ Always allowed Not considered PartialJMM [15] → Partially restricted Reveal (Immediate)

7→ Partially restricted Reveal (Immediate)↔ Partially restricted Reveal (Immediate)

ACD [2] ↔ Always allowed Manipulation DelayedCDV [6] ↔ Always allowed Not considered DelayedThis work → Always allowed Manipulation Immediate

Table 1: Differences in security notions of ratcheting regarding (a) uni- (→), sesqui-(7→), and bidirectional (↔) interaction between A and B, (b) when the adversary isallowed to expose A’s and B’s state (or when this is unnecessarily restricted), (c) theadversary’s ability to reveal or manipulate algorithm invocations’ random coins, and(d) how soon and how complete recovery from these two attacks into a secure stateis required of secure constructions (or if unnecessary delays or exceptions for recoveryare permitted).1 Recovery from attacks required by Jost et al. [15] is immediate in sofar as their restrictions of state exposures introduce delays implicitly. Gray markedcells indicate the reason (i.e., relaxations in security) why respective instantiations canrely on standard PKC only (circumventing our implication result). Rows without graymarked cells have no construction based on pure PKC.

ples such as the Signal protocol (analyzed in [8]), and instantiations of the abovenamed relaxed security notions [10,15,2,6] only rely on standard PKC (cf. rowsin Table 1 with gray cells).

In contrast, both mentioned optimally secure bidirectional ratcheting vari-ants (i.e., sesquidirectional and bidirectional RKE [20], and bidirectional stronglysecure channel [13]) are based on a strong cryptographic building block, calledkey-updatable public key encryption, which can be built from hierarchical iden-tity based encryption (HIBE). Intuitively, key-updatable public key encryptionis standard public key encryption that additionally allows to update public keyand secret key independently with respect to some associated data (a conceptualdepiction of this is on the left side of Figure 1). Thereby an updated secret keycannot be used to decrypt ciphertexts that were encrypted to previous (or dif-ferent) versions of this secret key (where versions are defined over the associateddata used for updates).

We emphasize a significant difference between key-updatable public key en-cryption and HkuPke (introduced by Jost et al. [15] and recently used by Alwenet al. [3,1]): in HkuPke key updates rely on interactive communication betweenholders of public key and secret key, and associated data for key updates is notfully adversary-controlled. These two differences make it a strictly weaker prim-itive, insufficient for optimal security of RKE (on which we further elaborate inSection 3).

5

Necessity for Strong Building BlocksNatural questions that arise from this line of work are, whether and under whichconditions such strong (HIBE-like) building blocks are not only sufficient butalso necessary to instantiate the strong security of (bidirectional) RKE. In or-der to answer these questions, we build key-updatable public key cryptographyfrom ratcheted key exchange. Consequently we affirm the necessity and provide(sufficient) conditions for relying on these strong building blocks. We there-fore minimally adjust the syntax of key-updatable key encapsulation mechanism(kuKEM) [20] and consider the manipulation of algorithm invocations’ randomcoins in our security definitions of kuKEM and RKE.2

Bad randomness

HIB-KEMOW-ID-CCA

kuKEM∗KUOWR

KEMIND-1-CCA

kuKEMKUOW

URKEKINDR

URKEKIND

SRKEKIND BRKEKIND

BRKEKINDR

Xx Yyiff (x-secure X⇒ y-secure Y)

[20]

ROM

ROM

ROM

[20][20]

[20]

Fig. 2: The contributions of this paper (bold arrows) and their connection to previouswork (thin arrows) involving RKE (uni-, sesqui-, and bidirectional) and KEM (stan-dard, hierarchical-identity-based, and key-updatable) primitives. ROM indicates thatthe proof holds in the random oracle model. kuKEM∗KUOWR ⇒ROM SRKEKIND is notformally proven in this paper, but we point out that the proof of kuKEMKUOW ⇒ROMSRKEKIND from [20] can be rewound. Gray dashed connections indicate trivial impli-cations (due to strictly weaker syntax or security definitions).

While, despite these changes of syntax and security towards prior definitions,we prove that RKE can still be built from kuKEM, we also prove that kuKEMcan be built from RKE (see Figure 2). As a result we show that:– kuKEM∗ (with one-way security under manipulation of randomness)3⇒ROM

Unidirectional RKE (with key indistinguishability under manipulation ofrandomness),

– Unidirectional RKE (with key indistinguishability under manipulation ofrandomness)⇒ kuKEM∗ (with one-way security under manipulation of ran-domness).

2 Recall that randomness manipulation was not considered in a security definition thataimed for optimal security in the literature of ratcheting yet (cf. Table 1).

3 The asterisk at kuKEM∗ indicates the minimal adjustment to the kuKEM syntaxdefinition from [20]. For the kuKEM∗ we consider one-way security as it suffices toachieve strong security for RKE. It is obvious that the same results hold for keyindistinguishability.

6

Given the security notions established in honest randomness setting and theirconnections to each other, one would also expect– Group RKE ⇒ Bidirectional RKE ⇒ Sesquidirectional RKE ⇒ Unidirec-

tional RKE

to follow. Hence, our results indicate that stronger RKE variants also likelyrequire building blocks as hard as kuKEM∗. Furthermore, due to our results,it becomes clear that: One-way security under manipulation of randomness ofkuKEM∗ ⇒ROM Key indistinguishability of sesquidirectional RKE. Interest-ingly, these results induce that (when considering strong security) ratcheted keyexchange requires these strong (HIBE-like) building blocks not only for bidi-rectional communication settings, but already for the unidirectional case. Bothmentioned previous unidirectional RKE schemes can bypass our implication be-cause they forbid exposures of B’s state [4] or assume secure randomness [20](see Table 1). We describe attacks against each of both constructions in our secu-rity definition in Appendix C. Since the mentioned relaxed security definitionsof ratcheting [8,10,15,2,6] restrict the adversary more than necessary in expos-ing states, solving (potentially valid) embedded game challenges, manipulatingthe communication between the session participants, or attacking invocations’random coins (and thus violate either of our security definition’s conditions),it remains feasible to instantiate them with standard public key primitives aswell (see Table 1). Although our analysis was partially motivated by the use ofkuKEM in [20,13], we do not ultimately answer whether these particular con-structions necessarily relied on it. Rather we provide a clean set of conditionsunder which RKE and kuKEM clearly imply each other as we do not considerthe justification of previous constructions but a clear relation for future workimportant.

Thus, we show that sufficient conditions for necessarily relying on kuKEMas a building block of RKE are: (a) unrestricted exposure of both parties’ localstates, (b) consideration of attacks against algorithm invocations’ random coins,and (c) required immediate recovery from these two attacks into a secure stateby the security definition (i.e., the adversary is only restricted with respect tounpreventable/trivial attacks).4

ContributionsThe contributions of our work can be summarized as follows:– We are the first who systematically define optimal security of key-updatable

KEM and unidirectional RKE under randomness manipulation (in sections 3and 4) and thereby consider this practical threat in addition to state expo-sures in an instantiation-independent notion of RKE. Thereby we substan-tially enhance the respective models by Poettering and Rösler [20].

4 Note that there may exist further sets of sufficient conditions for relying on kuKEMssince, for example, sesqui- and bidirectional RKE by Poettering and Rösler [20,19] vi-olate condition (b) but base on kuKEMs as well. We refer the reader to Appendix B.2in [19] for a detailed explanation of why their scheme presumably also must rely ona kuKEM. We leave the identification of further sets of conditions as future work.

7

– In Section 5, we construct unidirectional RKE generically from a kuKEM∗to show that the latter suffices as a building block for the former undermanipulation of randomness.

– To show that kuKEM∗ is not only sufficient but also necessary to build unidi-rectional RKE (under randomness manipulation), we provide a constructionof kuKEM∗ from a generic unidirectional RKE scheme in Section 6.

With our results we distill the core building block of strongly secure ratchetedkey exchange down to its syntax and security definition. This allows furtherresearch to be directed towards instantiating kuKEM∗ schemes that are morefamiliar and easier in terms of security requirements, rather than attempting toconstruct seemingly more complex RKE primitives.5 Simultaneously, our resultsindicate the cryptographic hardness of ratcheted key exchange and thereby helpto systematize and comprehend the security definitions and different dimensionsof ratcheting in the literature. As a consequence, our results contribute to afact-based trade-off between security and efficiency for RKE by providing re-quirements for relying on heavy building blocks and thereby revealing respectivebypasses.

2 Preliminaries

2.1 Notation

By x← y we define the assignment of the value of variable y to variable x andthus for a function X, x ← X(y) means that x is assigned with the evaluationoutput of X on input y. We define T, F as Boolean values for true and false. Theshortcut notion w ← x ? y : z means that ‘if x = T, then w ← y, otherwisew ← z’. For a probabilistic algorithm Y, x ←$ Y(y) denotes the probabilisticevaluation of Y on input y with output x and x ← Y(y; r) denotes the deter-ministic evaluation of Y on y with output x where the evaluation’s randomnessis fixed to r. For a set X , x ←$ X is the uniform random sampling of value xfrom X . We use the shortcut notion X ∪← Y to denote the union X ← X ∪ Y ofsets X and Y.

Symbol ‘ε’ denotes an empty string and symbol ‘⊥’ denotes an undefinedelement or an output that indicates rejections (thus it is not an element ofexplicitly defined sets).

By X ∗, we denote the set of all lists of arbitrary size whose elements belongto X . We abuse the notation of empty string ‘ε’ by writing L = ε for an empty5 For example, the bidirectional channel construction in the proceedings version of [13]is not secure according to the security definition (but a corrected version is publishedas [14]), in the acknowledgments of [19] it is mentioned that an early submittedversion of their construction was also flawed, and for an earlier version of [10] wedetected during our work (and informed the authors) that the construction wasinsecure under bad randomness such that the updated proceedings version (alsoavailable as [9]) disregards attacks against randomness entirely. Finally, we detectedand reported that the construction of HkuPke in [15] is not even correct.

8

list L. If an element x ∈ X is appended to list L then we denote this by L← L‖x(or simply L

q← x). Thus, ‘‖’ denotes a special concatenation symbol that isnot an element of any of the explicitly defined sets. We define relations prefix-or-equal � and strictly-prefix ≺ over two lists. For instance, for lists L,L0 =L‖x, L1 = L‖y where x, y ∈ X , x 6= y we have that L � L,L 6≺ L,L ≺ L0, L ≺L1, L0 6� L1, L1 6� L0 meaning that L is a prefix of L0 and L1 but neither ofL0, L1 is a prefix of the other. By X[·] we denote an associative array.

In our security experiments, that we denote with Game, we invoke adver-saries via instruction ‘Invoke’. These adversaries are denoted byA,B. Adversarieshave access to the security experiment’s interface, which is defined by oraclesthat are denoted by the term Oracle. Games are terminated via instructions‘Stop with x’ (meaning that x is returned by the game) or ‘Reward b’ (meaningthat the game terminates and returns 1 if b = T). In procedures that we denoteby Proc and in oracles, we use the shortcut notion ‘Require x’. Depending onthe procedure’s or oracle’s number of return values n, that means ‘If x = F, thenreturn ⊥n’.

2.2 Message Authentication Code

We define a message authentication code to be a set of algorithms M = (tag, vfyM)over a set of symmetric keys K, a message space M, and a tag space T . Thesyntax is defined as:K ×M→ tag→ TK ×M× T → vfyM → {T,⊥}

Please note that we define the tag algorithm explicitly deterministic.For correctness of a MAC we define that for all k ∈ K and all m ∈ M it is

required that vfyM(k,m, tag(k,m)) = T.We define a one-time multi-instance strong unforgeability notion SUF for

MAC security – that is equivalent with standard strong unforgeability – forwhich the formal security game is depicted in Appendix E Figure 14. That is,for a game in which an adversary can generate instances i (with independentuniformly random keys ki ←$ K) via an oracle Gen, the adversary can querya Tag oracle on a message m from message spaceM for each instance at mostonce to obtain the respective MAC tag. Additionally, the adversary can verifyMAC tags for specified messages and instances via oracle Vfy and obtain aninstance’s key by querying an Expose oracle for this instance. The adversarywins by providing a forgery (m, τ) for an instance i to the Vfy oracle if therewas no Tag(i,m) query before with output τ and if i’s key was not exposedvia oracle Expose. We define the advantage of winning the SUF game against aMAC scheme M as Advsuf

M (A) = Pr[SUFM(A)→ 1].

3 Sufficient Security for Key-Updatable KEM

A key-updatable key encapsulation mechanism (kuKEM) is a key encapsulationmechanism that provides update algorithms for public key and secret key with

9

respect to some associated data respectively. Prior to our work, this primitivewas used to instantiate sesquidirectional RKE. In order to allow for our equiva-lence result, we minimally adjust the original kuKEM notion by Poettering andRösler [20] and call it kuKEM∗. The small, yet crucial changes comprise allowedupdates of public and secret key during encapsulation and decapsulation (in oursyntax definition) as well as the adversary’s ability to manipulate utilized ran-domness of encapsulations (in our security definition). In Section 6 the rationalesbehind these changes are clarified. In order to provide a coherent definition, wenot only describe alterations towards previous work but define kuKEM∗ entirely(as we consider our changes to be a significant contribution and believe that thisstrengthens comprehensibility).

Syntax A kuKEM∗ is a set of algorithms K = (genK,up, enc,dec) with sets ofpublic keys PK and secret keys SK, a set of associated data AD for updatingthe keys, a set of ciphertexts C (with AD ∩ C = ∅), and a set of encapsulatedkeys K. Furthermore we define R as the set of random coins used during theencapsulation:

genK →$ PK × SKPK ×AD → up→ PKSK ×AD → up→ SKPK ×R → enc→ PK×K × C or PK → enc→$ PK ×K × CSK × C → dec→ (SK ×K) ∪ {(⊥,⊥)}

Please note that the encapsulation and decapsulation may modify the public keyand the secret key respectively – as a result, the kuKEM∗ is stateful (where thepublic key is a public state).6

Correctness The correctness for kuKEM∗ is (for simplicity) defined throughgame CORRK (see Figure 3), in which an adversary A can query encapsulation,decapsulation, and update oracles. The adversary (against correctness) wins ifdifferent keys are computed during decapsulation and the corresponding encap-sulation even though compatible key updates were conducted and ciphertextsfrom encapsulations were directly forwarded to the decapsulation oracle.

Definition 1 (kuKEM∗ correctness). A kuKEM∗ scheme K is correct if forevery A, the probability of winning game CORRK from Figure 3 is Pr[CORRK(A)→ 1] = 0.

Security Here we describe KUOWR security of kuKEM∗ as formally depictedin Figure 4. KUOWR defines one-way security of kuKEM∗ under randomnessmanipulation in a multi-instance/multi-challenge setting.6 As kuKEM∗ naturally provides no security for encapsulated keys if the adversarycan manipulate the randomness for genK already, we only consider the manipulationof random coins for enc.

10

Game CORRK(A)00 (pk, sk)←$ genK01 key[·]← ⊥02 trs ← ε; trr ← ε03 Invoke A04 Stop with 0

Oracle UpS(ad)05 Require ad ∈ AD06 pk ← up(pk, ad)07 trs q← ad08 Return

Oracle UpR(ad)09 Require ad ∈ AD10 sk ← up(sk, ad)11 trr q← ad12 Return

Oracle Enc()13 (pk, k, c)←$ enc(pk)14 trs q← c15 key[trs]← k16 Return (pk, c)

Oracle Dec(c)17 Require c ∈ C18 (sk, k)← dec(sk, c)19 trr q← c20 If trr � trs:21 Reward k 6= key[trr ]22 Return

Fig. 3: The correctness notion of kuKEM∗ captured through game CORR.

Intuitively, the KUOWR game requires that a secret key can only be usedfor decapsulation of a ciphertext if prior to this decapsulation all updates of thissecret key and all decapsulations with this secret key were consistent with theupdates of and encapsulations with the respective public key. This is reflectedby using the transcript (of public key updates and encapsulations or secret keyupdates and decapsulations) as a reference to encapsulated “challenge keys” andsecret keys.

In order to let the adversary play with the kuKEM∗’s algorithms, the gameprovides oracles Gen, UpS , UpR, Enc, and Dec. Thereby instances (i.e., key pairs)can be generated via oracle Gen and are referenced in the remaining oracles bya counter that refers to when the respective instance was generated.

For encapsulation via oracle Enc, the adversary can either choose the invoca-tion’s random coins by setting rc to some value that is not the empty string ε orlet the encapsulation be called on fresh randomness by setting rc = ε (line 16).In the former case, the adversary trivially knows the encapsulated key. Thus,only when called with fresh randomness, the encapsulated key is marked as achallenge key in array CK (line 20).

The variables CK, SK , and XP (the latter two are explained below) areindexed via the transcript of operations on the respective key pair part. Aspublic keys and secret keys can uniquely be referenced via the associated dataunder which they are updated and via ciphertexts that have been encapsulatedor decapsulated by them, the concatenation of these values (i.e., sent or receivedtranscripts trs, trr) are used as references to them in the KUOWR game.

On decapsulation of a key that is not marked as a challenge, the respectivekey is output to the adversary. Challenge keys are of course not provided to theadversary as thereby the challenge would be trivially solved (line 36).

Via oracle Expose, the adversary can obtain a secret key of specified instance ithat results from an operation referenced by transcript tr . As described above,the transcript, to which a secret key refers, is built from the associated data ofupdates to this secret key (via oracle UpR) and the ciphertexts of decapsulationswith this secret key (via oracle Dec) as these two operations may modify the

11

Game KUOWRK(A)00 n← 001 Invoke A02 Stop with 0

Oracle Gen03 n← n+ 104 (pkn, skn)←$ genK05 CKn[·]← ⊥; XPn ← ∅06 trsn ← ε; trrn ← ε07 SKn[·]← ⊥08 SKn[trrn]← skn

09 Return pkn

Oracle UpS(i, ad)10 Require 1 ≤ i ≤ n ∧ ad ∈ AD11 pki ← up(pki, ad)12 trsi

q← ad13 Return pki

Oracle Enc(i, rc)14 Require 1 ≤ i ≤ n15 · Require rc ∈ R ∪ {ε}16 · If rc = ε: mr ← F; rc ←$ R17 · Else: mr ← T18 · (pki, k, c)← enc(pki; rc)19 · trsi

q← c20 · If mr = F: CKi[trsi]← k21 · Return (pki, c)

Oracle Solve(i, tr , k)22 Require 1 ≤ i ≤ n23 Require tr /∈ XPi

24 Require CKi[tr ] 6= ⊥25 Reward k = CKi[tr ]26 Return

Oracle UpR(i, ad)27 Require 1 ≤ i ≤ n ∧ ad ∈ AD28 ski ← up(ski, ad)29 trr i

q← ad30 SK i[trr i]← ski

31 Return

Oracle Dec(i, c)32 Require 1 ≤ i ≤ n ∧ c ∈ C33 · (ski, k)← dec(ski, c)34 · trr i

q← c35 · SK i[trr i]← ski

36 · If CKi[trr i] 6= ⊥:37 · Return38 · Return k

Oracle Expose(i, tr)39 Require 1 ≤ i ≤ n40 · Require SK i[tr ] ∈ SK41 · XPi

∪← {tr∗ ∈ (AD ∪ C)∗ :tr ≺ tr∗}

42 Return SK i[tr ]

Fig. 4: Security experiment KUOWR, modeling one-way security of key-updatableKEM in a multi-instance/multi-challenge setting under randomness manipulation.Lines of code tagged with ‘·’ are (substantially) modified with respect to KUOW secu-rity in [19]. Line 41 is a shortcut notion that can be implemented efficiently. CK: chal-lenge keys, XP: exposed secret keys, trs, trr : transcripts.

secret key. As all operations, performed with an exposed secret key, can betraced by the adversary (i.e., updates and decapsulations; note that both aredeterministic), all secret keys that can be derived from an exposed secret keyare also marked exposed via array XP (line 41).

Finally, an adversary can solve a challenge via oracle Solve by providing aguess for the challenge key that was encapsulated for an instance i with theencapsulation that is referenced by transcript tr . Recall that the transcript,to which an encapsulation refers, is built from the associated data of updatesto the respective instance’s public key (via oracle UpS) and the ciphertextsof encapsulations with this instance’s public key (via oracle Enc) as these twooperations may modify the public key for encapsulation. If the secret key fordecapsulating the referenced challenge key is not marked exposed (line 23) and

12

the guess for the challenge key is correct (line 24), then game KUOWR stopswith ‘1’ (via ‘Reward’) meaning that the adversary wins.

Definition 2 (KUOWR Advantage). The advantage of an adversary A againsta kuKEM∗ scheme K in game KUOWR from Figure 4 is defined as Advkuowr

K (A) =Pr[KUOWRK(A)→ 1].

We chose to consider one-way security as opposed to key indistinguishabilityfor the kuKEM∗ as it suffices to show equivalence with key indistinguishabilityof RKE (in the ROM). It is evident that all proofs in this work also hold forkey indistinguishability of kuKEM∗ and one can generically derive key indistin-guishability for kuKEM∗ via the FO transform by Hofheinz et al. [12].

Differences compared to previous Security Definition In Figure 4 we denotechanges from KUOW security (cf., Figure 1 [19]) by adding ‘·’ at the begin-ning of lines. Below we elaborate on these differences.

The main difference in our definition of KUOWR security compared toKUOW security is that we allow the adversary to manipulate the execution’srandom coins. As we define encapsulation and decapsulation to (potentially) up-date the used public key or secret key, another conceptual difference is that weonly allow the adversary to encapsulate and decapsulate once under each publicand secret key. Thus, we assume that public and secret keys are overwritten onencapsulation and decapsulation respectively. In contrast to our security defini-tion, in the KUOW security game only the current secret key of an instance canbe exposed. Even though we assume the secret key to be replaced by its newerversions on updates or decapsulations, there might be, for example, backupsthat store older secret key versions. As a result we view the restriction of onlyallowing exposures of the current secret key artificial.7 An important notationalchoice is that we index the variables with transcripts trs, trr instead of integercounters. This notation reflects the idea that public key and secret key only staycompatible as long as they are used correspondingly and immediately divergeon different associated data or tampered ciphertexts.

We further highlight the fundamental difference towards HkuPke by Jost etal. [15]. Their notion of HkuPke does not allow (fully adversary-controlled) asso-ciated data on public and secret key updates and additionally requires (authen-ticated) interaction between the holders of the key parts thereby. Looking ahead,this makes this primitive insufficient for diverging the public key from the secretkey (in the states) of users A and B during an impersonation of A towards B in(U)RKE (especially under randomness manipulation). This is, however, requiredin an optimal security definition but explicitly excluded in the sub-optimal RKEnotion by Jost et al. [15]. Since the syntax of HkuPke is already inadequate to re-flect this security property, we cannot provide a separating attack. Nevertheless,we further expound this weakness in Appendix D.7 It is important to note that the equivalence between KUOWR security of kuKEM∗and KINDR security of URKE is independent of this definitional choice – if eitherboth definitions allow or both definitions forbid the exposure of also past secret keysor states respectively, equivalence can be shown.

13

Instantiation A kuKEM∗ scheme, secure in the KUOWR game, can be generi-cally constructed from an OW-CCA adaptively secure hierarchical identity basedkey encapsulation mechanism (HIB-KEM). The construction – the same asin [19] – is provided for completeness in Figure 5. The update of public keysis the concatenation of associated data (interpreted as identities in the HIB-KEM) and the update of secret keys is the delegation to lower level secret keysin the identity hierarchy. The reduction is immediate: After guessing for whichpublic key and after how many updates the challenge encapsulation that is solvedby the adversary is queried, the challenge from the OW-CCA game is embeddedinto the respective KUOWR challenge.

Proc genK00 (pk ID, sk ID)←$ genID01 id ← ε02 pk ← (pk ID, id)03 sk ← sk ID04 Return (pk, sk)

Proc enc(pk)05 (pk ID, id)← pk06 (c, k)←$ encID(pk ID, id)07 id q← c08 pk ← (pk ID, id)09 Return (pk, k, c)

Proc up(sk, ad)10 sk ← delID(sk, ad)11 Return sk

Proc up(pk, ad)12 (pk ID, id)← pk13 id q← ad14 pk ← (pk ID, id)15 Return pk

Proc dec(sk, c)16 k ← decID(sk, c)17 sk ← delID(sk, c)18 Return (sk, k)

Fig. 5: Generic construction of a kuKEM∗ from a hierarchical identity based KEMHK = (genID, delID, encID, decID) (slightly differing from construction in [19] Figure 2 byadding an internal key update in encapsulation and decapsulation respectively).

Sufficiency of KUOWR for SRKE Before proving equivalence between securityof key-updatable KEM and ratcheted key exchange, we shed a light on impli-cations due to the differences between our notion of kuKEM∗ and its KUOWRsecurity and the notion of kuKEM and its KUOW security in [19].

Remark 1. Even though the KUOWR game provides more power to the adver-sary in comparison to the KUOW game by allowing manipulation of randomcoins, exposures of past secret keys, and providing an explicit decapsulation or-acle (instead of an oracle that only allows for checks of ciphertext-key pairs; cf.,Figure 1 [19]), the game also restricts the adversary’s power by only allowingdecapsulations under the current secret key of an instance (as opposed to alsochecking ciphertext-key pairs for past secret keys of an instance as in the KUOWgame). One can exploit this and define protocols that are secure with respectto one game definition but allow for attacks in the other game. Consequently,neither of both security definitions implies the other one.

14

Despite the above described distinction between both security definitions,KUOWR security suffices to build sesquidirectional RKE according to the KINDdefinition in [20] – which was yet the weakest notion of security of RKE for whicha construction was built from a key-updatable public key primitive. The abilityto check ciphertext-key pairs under past versions of secret keys of an instanceis actually never used in the proof of Poettering and Rösler [19]. The only casein which this Check oracle is used in their proof is B’s receipt of a manipulatedciphertext from the adversary. Checking whether a ciphertext-key pair for thecurrent version of a secret key of an instance is valid, can of course be conductedby using the Dec oracle of our KUOWR notion. For full details on their proofwe refer the reader to Appendix C in [19].

Consequently, for the construction of KIND secure sesquidirectional RKE(according to [20] Figure 8) from Poettering and Rösler [20], the used kuKEMmust either be KUOW secure (see [20] Figure 1) or KUOWR secure (see Fig-ure 4), which is formally depicted in the following observation. Thus, even thoughthese notions are not equivalent, they both suffice for constructing KIND securesesquidirectional RKE.

Observation 1 The sesquidirectional RKE protocol R from [20] Figure 6 of-fers key indistinguishability according to [20] Figure 8 if function H is modeledas a random oracle, the kuKEM∗ provides KUOWR security according to Fig-ure 4, the one-time signature scheme provides SUF security according to [19]Figure 22, the MAC scheme M provides SUF security according to Figure 14,and the symmetric-key space of the kuKEM∗ is sufficiently large.

4 Unidirectional RKE under Randomness Manipulation

Unidirectional RKE (URKE) is the simplest variant of ratcheted key exchange.After a common initialization of a session between two parties A and B, itenables the continuous establishment of keys within this session. In this unidi-rectional setting, A can initiate the computation of keys repeatedly. With eachcomputation, a ciphertext is generated that is sent to B, who can then com-prehend the computation and output (the same) key. Restricting A and B tothis unidirectional communication setting, in which B cannot respond, allows tounderstand the basic principles of ratcheted key exchange. For the same reasonswe provided the whole definition of kuKEM∗ before (i.e., we see our changes as asignificant contribution and aim for a coherent depiction), we fully define URKEunder randomness manipulation below.

Syntax We recall that URKE is a set of algorithms UR = (init, snd, rcv) de-fined over sets of A’s and B’s states SA and SB respectively, a set of associateddata AD, a set of ciphertexts C, and a set of keys K established between Aand B. We extend the syntax of URKE by explicitly regarding the utilized ran-domness of the snd algorithm. Consequently we define R as the set of randomcoins rc ∈ R used in snd. To highlight that A only sends and B only receives

15

in URKE, we may add ‘A’ and ‘B’ as handles to the index of snd, and rcvrespectively.

init→$ SA × SB

SA ×AD ×R → snd→ SA ×K × C or SA ×AD → snd→$ SA ×K × CSB ×AD × C → rcv→ SB ×K ∪ {(⊥,⊥)}

Please note that de-randomizing (or explicitly considering the randomness of)the initialization of URKE is of little value since an adversary, when controllingthe random coins of init, obtains all information necessary to compute all keysbetween A and B.

Correctness Below we define correctness for URKE. Intuitively a URKE schemeis correct, if all keys produced with send operations of A can also be obtainedwith the resulting ciphertext by the respective receive operations of B.

Definition 3 (URKE Correctness). Let {adi ∈ AD}i≥1 be a sequence of as-sociated data. Let {sA,i}i≥0, {sB,i}i≥0 denote the sequences of A’s and B’s statesgenerated by applying snd(·, adi) and rcv(·, adi, ·) operations iteratively for i ≥ 1,that is,

(sA,i, ki, ci)←$ snd(sA,i−1, adi)(sB,i, k

′i)← rcv(sB,i−1, adi, ci).

We say URKE scheme UR = (init, snd, rcv) is correct if for all sA,0, sB,0 ←$ init,for all associated data sequences {adi}i≥1, and for all random coins used for sndcalls, the key sequences {ki}i≥1 and {k′i}i≥1 generated as above are equal.

Security For security, we provide the KINDR game for defining key indistinguish-ability under randomness manipulation of URKE in Figure 6. In this game, theadversary can let the session participants A and B send and receive ciphertextsvia SndA and RcvB oracle queries respectively to establish keys between them.By querying the Reveal or Challenge oracles, the adversary can obtain theseestablished keys or receive a challenge key (that is either the real establishedkey or a randomly sampled element from the key space) respectively. Finally,the adversary can expose A’s and B’s state as the output of a specified send orreceive operation respectively via oracles ExposeA or ExposeB.

When querying the SndA oracle, the adversary can specify the random coinsfor the invocation of the snd algorithm from the set R or indicate that it wantsthe random coins to be sampled uniformly at random by letting rc = ε. Byallowing the adversary to set the randomness for the invocations of the sndalgorithm and exposing past states (which was not permitted in the definitionof Poettering and Rösler [20]), new trivial attacks arise.

Below we review and explain the trivial attacks of the original URKE KINDgame, map them to our version, and then introduce new trivial attacks that arisedue to randomness manipulation.

A conceptual difference between our game definition and the games by Po-ettering and Rösler [20] is the way variables (especially arrays) are indexed.

16

Game KINDRbUR(A)

00 XPA ← ∅; MR ← ∅01 KN← ∅; CH← ∅02 trs ← ε; trr ← ε03 SA[·]← ⊥; SB [·]← ⊥04 key[·]← ⊥;05 (sA, sB)←$ init06 SA[trs]← sA; SB [trr ]← sB

07 b′ ←$ A08 · Require KN ∩ CH = ∅09 Stop with b′

Oracle SndA(ad, rc)10 Require ad ∈ AD ∧ rc ∈ R ∪ {ε}11 If rc = ε:12 (sA, k, c)←$ snd(sA, ad)13 Else:14 (sA, k, c)← snd(sA, ad; rc)15 ◦ MR ∪← {trs‖(ad, c)}16 ◦ If trs ∈ XPA:17 ◦ KN ∪← {trs‖(ad, c)}18 ◦ XPA

∪← {trs‖(ad, c)}19 trs q← (ad, c)20 key[trs]← k; SA[trs]← sA

21 Return c

Oracle Reveal(tr)22 Require key[tr ] ∈ K23 · KN ∪← {tr}24 Return key[tr ]

Oracle RcvB(ad, c)25 Require ad ∈ AD ∧ c ∈ C ∧ sB 6= ⊥26 · If trr‖(ad, c) 6� trs

∧LCP(trs, trr) ∈ XPA:27 · KN ∪← {trr‖(ad, c)}28 (sB , k)← rcv(sB , ad, c)29 If k = ⊥: Return ⊥30 trr q← (ad, c)31 key[trr ]← k; SB [trr ]← sB

32 Return

Oracle ExposeA(tr)33 Require SA[tr ] ∈ SA

34 · XPA∪← {tr}

35 ◦ trace ← {tr∗ ∈ T R∗ : ∀tr ′ ∈ T R∗(tr ≺ tr ′ � tr∗ =⇒ tr ′ ∈ MR)}

36 ◦KN ∪← trace; XPA∪← trace

37 Return SA[tr ]

Oracle ExposeB(tr)38 Require SB [tr ] ∈ SB

39 · KN ∪← {tr∗ ∈ T R∗ : tr ≺ tr∗}40 Return SB [tr ]

Oracle Challenge(tr)41 Require key[tr ] ∈ K42 · Require tr /∈ CH43 k ← b ? key[tr ] : $(K)44 · CH ∪← {tr}45 Return k

Fig. 6: Games KINDRb, b ∈ {0, 1}, for URKE scheme UR. Lines of code tagged witha ‘·’ denote mechanisms to prevent or detect trivial attacks without randomness manip-ulation; trivial attacks caused by randomness manipulation are detected and preventedby lines tagged with ‘◦ ’. We define LCP(X,Y ) to return the longest common prefixbetween X and Y , which are lists of atomic elements zi ∈ (AD × C). By longest com-mon prefix we mean the longest list Z = z0‖ . . . ‖zn for which Z � X ∧ Z � Y . Wefurther define T R = AD×C. Line 39 is a shortcut notion that can be implemented effi-ciently. XP: exposed states, MR: states and keys affected by manipulated randomness,KN: known keys, CH: challenge keys, trs, trr : transcripts.

While the KIND games of [20] make use of counters (of send and receive opera-tions) to index computed keys and adversarial events, we use the communicatedtranscripts, sent and received by A and B respectively, as indices. We therebyheavily exploit the fact that synchronicity (and divergence) of the communica-tion between A and B are defined over these transcripts, which results in a morecomprehensible (but equivalent) game notation. Please note that, due to ourindexing scheme, it suffices for our game definition to maintain a common key

17

array key[·] and common sets of known keys KN and challenged keys CH for Aand B (as opposed to arrays and sets for each party).8

The lines marked with ‘·’ in Figure 6 denote the handling of trivial attackswithout randomness manipulation (as in [20]). Lines marked with ‘◦’ introducemodifications that become necessary due the new trivial attacks based on ma-nipulation of randomness.

Trivial attacks without randomness manipulations are:(a) If the adversary reveals a key via oracle Reveal, then challenging this key

via oracle Challenge is trivial. In order to prevent reveal and challenge ofthe same key, sets KN and CH trace which keys have been revealed (line 23)and challenged (line 44). The adversary only wins, if the intersection of bothsets is empty (line 08). Additionally, a key must only be challenged once asotherwise bit b can be obtained trivially (line 42).Example: c← SndA(ε, ε); k ← Reveal((ε, c)); Return k = Challenge((ε, c))

(b) As keys, that are computed by both parties (because ciphertexts betweenthem have not been manipulated yet), are stored only once in array key(due to the indexing of arrays with transcripts instead of pure counters), theadversary cannot reveal these keys on one side of the communication (e.g., atA) and then challenge them on the other side (e.g., at B). Consequently, thistrivial attack (which was explicitly considered in [20]) is implicitly handledby our game definition.

(c) After exposing B’s state via oracle ExposeB, the adversary can comprehendall future computations of B. Consequently, all keys that can be received byB in the future are marked known (line 39).Example: sB ← ExposeB(ε); c ← SndA(ε, ε); RcvB(ε, c); (sB , k) ← rcv(sB , ε, c);Return k = Challenge((ε, c))

(d) Exposing B’s state, as long as the communication between A and B hasnot yet been manipulated by the adversary, allows the adversary also tocompute all future keys established by A (which is also implicitly handledby our indexing of arrays via transcripts).

(e) Exposing A’s state via oracle ExposeA allows the adversary to impersonateA towards B by using the exposed state to create and send own valid cipher-texts to B. As creating a forged ciphertext reveals the key that is computedby B on receipt, such keys are marked known (lines 26-27). The detection ofthis trivial attack works as follows: As soon as B receives a ciphertext thatwas not sent by A (i.e., B’s transcript together with the received ciphertextis not a prefix of A’s transcript) and A was exposed after A sent the lastciphertext that was also received by B (i.e., after the last common prefixLCP), the adversary is able to create this ciphertext validly on its own.9Example: sA ← ExposeA; (sA, k, c)← snd(sA, ε); RcvB(ε, c); Return k = Challenge((ε, c))

8 This is because a key, computed during the sending of A and the correspondingreceiving of B, only differs between A and B if the received transcript of B divergedfrom the sent transcript of A.

9 Please note that we need to detect this trivial attack this way (in contrast to thegame in [20]) because the adversary can forge ciphertexts to B without lettingthe communication between A and B actually diverge. It can do so by creating

18

Due to randomness manipulations, the adversary can additionally conductthe following attacks trivially:

(f) If the randomness for sending is set by the adversary (via SndA(ad, rc), rc 6=ε) and the state, used for this sending, is exposed (via ExposeA), then alsothe next state ofA, output by this send operation, will be known (and markedas exposed) as sending is thereby deterministically computed on inputs thatare known by the adversary (lines 16,18). Since the adversary can also retro-spectively expose A’s state, all computations that can be traced, due to con-tinuous manipulated randomness of subsequent SndA oracle queries (unifiedin set MR) after such an exposure, are also marked as exposed (lines 35-36).Example: rc ←$ R; c′ ← SndA(ε, rc); RcvB(ε, c′); sA ← ExposeA(ε); (sA, k

′, c′)←snd(sA, ε; rc); (sA, k, c)←$ snd(sA, ε); RcvB(ε, c); Return k = Challenge((ε, c′)‖(ε, c))

(g) Similarly, if the randomness for sending is set by the adversary and the statethat A uses during this send operation is exposed, then the key, computedduring sending, is known by the adversary since its computation is therebydeterministic (lines 16-17,35-36).Example: rc ←$ R; c← SndA(ε, rc); sA ← ExposeA(ε); (sA, k, c)← snd(sA, ε; rc);Return k = Challenge((ε, c))

Based on this game, we define the advantage of an adversary in breaking thesecurity of an URKE scheme as follows.

Definition 4 (KINDR Advantage). The advantage of an adversary A againsta URKE scheme UR in game KINDR from Figure 6 is defined as Advkindr

UR (A) =∣∣Pr[KINDR0UR(A) = 1] −Pr[KINDR1

UR(A) = 1]∣∣.

We say that an URKE scheme UR is secure if the advantage is negligible forall probabilistic polynomial time adversaries A.

Please note that KINDR security of URKE is strictly stronger than bothKIND security notions of URKE, defined by Bellare et al. [4] and Poetteringand Rösler [20] (which themselves are incomparable among each other).

5 kuKEM* to URKE

Since our ultimate goal is to show that existence of a kuKEM∗ primitive is anecessary and sufficient condition to construct a URKE primitive – albeit requir-ing the help of other common cryptographic primitives such as hash functions(modeled as random oracle) and message authentication codes –, we dedicatethis section to proving the latter of these implications.

an own valid ciphertext which it sends to B (via sA ← ExposeA(ε); rc ←$ R;(sA, k, c) ← snd(sA, ε; rc); RcvB(ε, c)) but then it lets A compute the same cipher-text (via SndA(ε, rc)). As a result, A and B are still in sync.

19

Construction of URKE from kuKEM∗ We give a generic way to construct aURKE scheme UR from a kuKEM∗ scheme K with the help of random oracle Hand MAC scheme M. This transformation K→ UR is fully depicted in Figure 7.Below we briefly describe the algorithms of URKE scheme UR = (init, snd, rcv).

During the state initiation algorithm init, a kuKEM∗ key pair (sk, pk) is gen-erated such that the encapsulation key pk is embedded into the sender state sA,and the decapsulation key sk into the receiver state sB . The remaining statevariables are exactly same for A and B. More specifically, two further keys aregenerated during initialization: the symmetric state key K and a MAC key k.m.Furthermore the sent or received transcript (initialized with an empty string ε)is stored in each state. For brevity, we assume that K, k.m, and the updatekey k.u (used during sending and receiving; see below) all belong to the samekey domain K that is sufficiently large.

Proc init00 (pk, sk)←$ genK01 K ←$ K; k.m ←$ K02 t← ε03 SA ← (pk,K, k.m, t)04 SB ← (sk,K, k.m, t)05 Return (SA, SB)

Proc snd(SA, ad)06 (pk,K, k.m, t)← SA

07 (pk, k, c)←$ enc(pk)08 τ ← tag(k.m, (ad, c))09 C ← (c, τ)10 t

q← (ad, c)11 (k.o,K, k.m, k.u)←

H(K, k, t)12 pk ← up(pk, k.u)13 SA ← (pk,K, k.m, t)14 Return (SA, k.o, C)

Proc rcv(SB , ad, C)15 (sk,K, k.m, t)← SB

16 (c, τ)← C17 Require vfyM(k.m, (ad, c), τ)18 (sk, k)← dec(sk, c)19 Require k 6= ⊥20 t

q← (ad, c)21 (k.o,K, k.m, k.u)←

H(K, k, t)22 sk ← up(sk, k.u)23 SB ← (sk,K, k.m, t)24 Return (SB , k.o)

Fig. 7: Construction of a URKE scheme from a kuKEM∗ scheme K =(genK,up, enc, dec), a message authentication code M = (tag, vfyM), and a randomoracle H. For simplicity we denote the key space of the MAC and the space of thesymmetric key K in sA with the same symbol K.

On sending, public key pk in A’s state is used by the encapsulation algo-rithm to generate key k and ciphertext c. Then, MAC key k.m, contained in thecurrent state of A, is used to issue a tag τ over the tuple of associated data adand encapsulation ciphertext c. The finally sent ciphertext, denoted by C, is aconcatenation of c and τ . The output key k.o, as well as the symmetric keysof the next state of A are obtained from the random oracle, on input of thesymmetric state key K, the freshly encapsulated key k, and the history of senttranscript t. Finally, a kuKEM∗ update is applied on pk under associated datathat is derived from the random oracle output (denoted by k.u). Please notethat the encapsulation algorithm is the only randomized operation inside snd.Hence the random coins of the latter are only used by the encapsulation.

On receiving, the operations are on par with the sending algorithm. Namely,the received ciphertext C is parsed as the encapsulation ciphertext c and the

20

MAC tag τ . The latter is verified with regards to the MAC key k.m, stored inthe state of B. After the key k is decapsulated, the same input to the randomoracle H is composed. The symmetric components of the next state and k.o arederived from the random oracle’s output. Finally, the secret key sk is updatedwith k.u, so that it is in-sync with the update of pk.

We remark that our construction in Figure 7 differs from the unidirectionalRKE scheme by Poettering and Rösler [20] only in the output of the randomoracle and in the subsequent use of the kuKEM∗’s update algorithm (insteadthey freshly generated a new KEM key pair from the random oracle output).These changes are, nevertheless, significant as their scheme is insecure when theadversary is able to (reveal or) manipulate the random coins for invocations ofthe snd algorithm. We give a detailed attack description against their scheme inour model in Appendix C.

Theorem 1. If kuKEM∗ scheme K is KUOWR secure according to Figure 4,MAC scheme M is SUF secure according to Figure 14, and H is a hash functionmodeled as random oracle, then URKE scheme UR from Figure 7 is KINDRsecure according to Figure 6 with

AdvkindrUR (A) ≤ Advkuowr

K (BK) + AdvsufM (BM) + qH · (qSndA + qRcvB)

|K|

where A is an adversary against KINDR security, BK is an adversary againstKUOWR security, BM is an adversary against SUF security, K is the key domainin the construction UR, qSndA, qRcvB, and qH are the number of SndA, RcvBand H queries respectively by A, and the running time of A is approximately therunning time of BK and BM.

Proof (Sketch, Theorem 1). We here give the sketch of the full proof that isin Appendix B. Our idea is to design a series of games Game 0-5, in whichdifferences between subsequent games are only syntactical and the advantage ofthe adversary A remains same. From this fifth game we are then ultimately ableto reduce either of the following cases, that are explained below, to one of thehardness assumptions.

Consider the following scenarios which lead to a win for the adversary A.Since the challenged keys are derived from the random oracle, we argue that, if Adoes not make a random oracle query H(K, k, t) for any of the challenged keys,then its advantage in guessing the challenge bit correctly remains negligible. Wedo not consider random oracle queries to keys that are trivially revealed to theadversary, as they do not lead to a win in the KINDR game (e.g., if the exposedstate of B helps the adversary to trivially query H). Therefore, we regard thefollowing three events in which A makes such special random oracle queries:

– The random oracle query H(K, k, t) belongs to one of the keys derived by thesender, in which fresh random coins, unknown to the adversary, are used forsending (and hence for encapsulation). In this case, we can give a reductionto the KUOWR game with respect to kuKEM∗ scheme K, in which the

21

reduction wins the KUOWR game by using the encapsulated key k as thesolution.

– The random oracle query H(K, k, t) belongs to one of the keys, derived fromthe sender where the used random coins are chosen by the adversary. Weknow that A did not expose the respectively used states of A or B as thisleads to a trivial win. Therefore, we can show that the symmetric statekeys K in these cases are independent from the view of A. This implies thatmaking such special H(K, k, t) query requires a collision in the key domain K,whose probability is bounded by qH · (qSndA + qRcvB)/|K|.

– The random oracle query H(K, k, t) belongs to one of the keys, derived by thereceiver B, who reaches to an out-of-sync status (if B is still in-sync with A,then one of the two cases above are relevant). Since each received ciphertextcontains a MAC tag, we can show that the first received ciphertext by Bthat is different from the sent ciphertext by A either corresponds to a trivialimpersonation or can be used to reduce this event to a forgery in the SUFgame with respect to MAC scheme M.

Therefore, by bounding the probability of these three cases, we can deduce theadversary’s advantage (which is negligible under the named assumptions). ut

6 URKE to kuKEM*

In order to show that public key encryption with independently updatable keypairs (in our case kuKEM∗) is a necessary building block for ratcheted keyexchange, we build the former from the latter. The major obstacle is that theupdates of public key and secret key of a kuKEM∗ are conducted independently– consequently no communication between holder of the public key and holder ofthe secret key can be assumed for updates. In contrast, all actions in ratchetedkey exchange are based on communication (i.e., sent or received ciphertexts).Another property that public key updates for kuKEM∗ must fulfill – in contrastto state updates in KIND secure unidirectional RKE as in [20] – is that theymust not leak any information on the according secret key during the updatecomputation. In the following we first explain these sketched issues (and theirorigin) in more detail, then describe how we solve it, and present a reduction ofKUOWR security to KINDR security of a generic URKE scheme.

Crucial Properties of kuKEM∗ Syntax and KUOWR security of kuKEM∗ (aswell as KUOW security of kuKEM) have several implications that we explainbelow. As described before, the syntax of kuKEM∗ does not allow interactionsbetween secret key holder and public key holder(s) to communicate informationfor the key parts’ updates (see Figure 1). This condition originates from theutilization of kuKEM as a building block for the instantiation of sesquidirectionalratcheted key exchange (SRKE) [20]. This extended RKE notion requires thetwo communication participants’ states to immediately become incompatibleas soon as one of the participants receives a ciphertext that was manipulatedby the adversary. Public key and secret key of the used kuKEM, as part of

22

the respective state, are therefore updated independently in order to cause animmediate divergence between these key pair parts.10

A second property that immediately follows from the first one is that, forall public keys that are updated equally, a compatible secret key can be used todecapsulate ciphertexts from all these public keys. As a public key update canalso be conducted by an adversary, the computation of this update itself mustnot reveal any information on encapsulated keys – especially not on a compatiblesecret key. We will further comment on this property when explaining that, eventhough KINDR security of URKE implies KUOWR security of kuKEM∗, one caninstantiate URKE KIND securely with standard key encapsulation mechanisms.In Appendix C, we describe why these prior instantiations of KIND secure URKEare insecure according to KINDR security.

When deriving the notion of kuKEM∗ and its KUOWR security, we takethese properties into account, as the goal of this work is not to find the minimalbuilding block for unidirectional RKE, but for RKE in general (e.g., also forsesquidirectional RKE).

Construction of kuKEM∗ from URKE The weaker KIND security of URKE (asin [20]) already allows that the sender’s state sA can always be exposed withoutaffecting the security of any established keys (as long as this exposed state isnot used to impersonate A towards B). Consequently, A’s pure state reveals noinformation on encapsulated keys nor on B’s secret key(s). KIND security ofURKE further implies that B’s state only reveals information on keys that havenot yet been computed by B (while earlier computed keys stay secure). One canimagine A’s state consequently as the public part of a (stateful) key pair andB’s state as the secret counterpart.

The two above mentioned crucial properties of KUOW(R) security are, how-ever, not implied by KIND security when using sA as the public key and sB asthe secret key of a kuKEM. Firstly, updating sB (as part of receiving a cipher-text) requires that the ciphertext, generated during sending of A (and updatingof sA), is known by B but the syntax of kuKEM does not allow an interac-tion between public key holder and secret key holder. This issue can be solvedby de-randomizing the snd algorithm. If A’s state as part of the public key isupdated via a de-randomized invocation of snd, the secret key holder can alsoobtain the ciphertext that A would produce for the same update (by invokingthe de-randomized/deterministic snd) and then update sB with this ciphertextvia rcv. A conceptional depiction of this is in Figure 8. Thereby the secret keyis defined to contain sA in addition to sB .

Secondly, in the URKE construction of Poettering and Rösler [20] A tem-porarily computes secrets of B that match A’s updated values during sending.As a result, normal KIND security allows that a de-randomized snd invocationreveals the secrets of B to an adversary if sA is known (see Appendix C fora detailed description of this attack). In order to solve this issue, the security10 A full description of the attack that is prevented by independent key updates is

in [20] Appendix A.2.

23

gen$Kinit$

pk = sA

up up

pk (sA, sB) = skc

sndR sndR rcv

up up

pk (sA, sB) = skc

sndR sndR rcv

enc$ dec

pk (sA, sB) = skc

sAsnd$ rcv

csndR′

sndR′ rcv

Fig. 8: Conceptual depiction of kuKEM∗ construction from generic URKE scheme.The symbol in the upper index of an algorithm name denotes the source of randomcoins (‘$’ indicates uniformly sampled). R is a fixed value. For clarity we omit ad inputsand k outputs (cf. Figure 1).

definition of URKE must ensure that future encapsulated keys’ security is notcompromised if snd is invoked under a known state sA and with random coinsthat are chosen by an adversary (i.e., KINDR security).

Our generic construction of a KUOWR secure kuKEM∗ from a generic KINDRsecure URKE scheme is depicted in Figure 9. As described before, the public keycontains state sA and the secret key contains both states (sA, sB) that are derivedfrom the init algorithm. In order to update the public key, the snd algorithmis invoked on state sA, with the update associated data, and fixed randomness.The output key and ciphertext are thereby ignored. Accordingly, the secret keyis updated by first invoking the snd algorithm on state sA with the same fixedrandomness and the update associated data. This time the respective ciphertextfrom A to B is not omitted but used as input to rcv algorithm with the sameassociated data under sB .

Encapsulation and decapsulation are conducted by invoking snd probabilisti-cally and rcv respectively. In order to separate updates from en-/decapsulation,a ‘0’ or ‘1’ is prepended to the associated data input of snd and rcv respectively.For bounding the probability of a ciphertext collision in the proof, a randomlysampled ‘collision key’ ck is attached to the associated data of the snd invocationin encapsulation. In order to accordingly add ck to the associated data of rcvas part of the decapsulation, ck is appended to the ciphertext. Since state sA,output by the snd algorithm during the encapsulation, is computed probabilisti-cally, it is also attached to the encapsulation ciphertext, so that (the other) sA,embedded in the secret key, can be kept compatible with the public key holder’s.To bind ck and sA to the ciphertext, both are integrity protected by a messageauthentication code (MAC) that takes one part of the key from the snd invoca-

24

tion as MAC key (only the remaining key bytes are output as the encapsulatedkuKEM∗ key). Additionally the whole ciphertext (i.e., URKE ciphertext, colli-sion key, state sA, and MAC tag) is used as associated data for an additional‘internal update’ of the public key and the secret key in encapsulation and de-capsulation respectively. This is done to escalate manipulations of collision key,state sA, or MAC tag (as part of the ciphertext) back into the URKE states sA

and sB (as part of public key and secret key). For full details on the rationalesbehind these two binding steps we refer the reader to the proof.

Proc genK00 (sA, sB)←$ init01 pk ← sA

02 sk ← (sA, sB)03 Return (pk, sk)

Proc up(pk, ad)04 (pk, , )← snd(pk, (0, ad); 0)05 Return pk

Proc enc(pk)06 ck ←$ K07 (pk, (k, k.m), c′)←$ snd(pk, (1, ck))08 τ ← tag(k.m, (ck, pk, c′))09 c← (ck, pk, c′, τ)10 (pk, , )← snd(pk, (2, c); 0)11 Return (pk, k, c)

Proc up(sk, ad)12 (sA, sB)← sk13 (sA, , c)← snd(sA, (0, ad); 0)14 (sB , )← rcv(sB , (0, ad), c)15 sk ← (sA, sB)16 Return sk

Proc dec(sk, c)17 (sA, sB)← sk18 (ck, pk, c′, τ)← c19 (sB , (k, k.m))← rcv(sB , (1, ck), c′)20 Require vfyM(k.m, (ck, pk, c′), τ)21 (sA, , c′′)← snd(pk, (2, c); 0)22 (sB , )← rcv(sB , (2, c), c′′)23 sk ← (sA, sB)24 Return (sk, k)

Fig. 9: Construction of a key-updatable KEM from a generic URKE scheme UR =(init, snd, rcv) and one-time message authentication code M = (tag, vfyM).

Interestingly, the public key holder can postpone the de-randomized snd in-vocation for public key updates until encapsulation and instead only rememberthe updates’ associated data without compromising security. However, the up-dates of the secret key must be performed immediately as otherwise an exposureof the current secret key reveals also information on its past versions. Therebythe computation of snd in the up algorithm must be conducted during the secretkey update without interaction between public key holder and secret key holder.Theorem 2. If URKE scheme UR is KINDR secure according to Figure 6, one-time MAC M is SUF secure according to Figure 14, and for all (k, k.m) ∈ KURit holds that k ∈ KK and k.m ∈ KM, then kuKEM∗ scheme K from Figure 9 isKUOWR secure according to Figure 4 with

AdvkuowrK (A) ≤ qGenqEnc ·

(Advkindr

UR (BUR) + AdvsufM (BM) + 1

|K|

)≤ qGenqEnc ·

(2 ·Advkindr

UR (BUR) + 1|K|

)

25

where A is an adversary against KUOWR security, BUR is an adversary againstKINDR security of UR, BM is an adversary against SUF security of M, qGenand qEnc are the number of Gen and Enc queries by A respectively, K is thespace from which ck is sampled, and the running time of A is approximately therunning time of BUR and BM.

In Appendix E we show how to construct an SUF secure one-time MACfrom a generic KINDR secure URKE scheme, which implies the second termin Theorem 2. We prove Theorem 2 below and provide a formal pseudo-codeversion of the simulation’s game hops in Figure 10.

Proof (Theorem 2).We conduct the proof in four game hops: In the first game hop we guess for

which instance the first valid Solve oracle query is provided by the adversary;in the second game hop, we guess for which Enc oracle query of the previouslyguessed instance the first valid Solve oracle query is provided; additionally thesimulation aborts in this game hop if the adversary crafts this first valid cipher-text and provides it to the Dec oracle before it is output by the Enc oracle; inthe third game hop, we replace the key, output by the first snd invocation inthis guessed Enc oracle query by a randomly sampled key (which is reduced toKINDR security of UR); in the final game hop, we abort on a MAC forgery,provided to the Dec oracle, that belongs to the ciphertext that is output by theguessed Enc oracle query (which is reduced to the SUF security of M).

Game 0 This game is equivalent to the original KUOWR game.Game 1 The simulation guesses for which instance nGen the first key k∗ is

provided to the Solve oracle such that the secret key for decapsulation is notmarked exposed (i.e., tr∗ /∈ XPnGen) and the provided key equals the indicatedchallenge key (i.e., k∗ = CKnGen [tr∗]). Therefore nGen is randomly sampled from[qGen], where qGen is the number of Gen oracle queries by the adversary. Thereduction aborts if nGen is not the instance for which the first valid Solve oraclequery is provided (see Figure 10 lines 47,50).

Consequently we have AdvG0 = qGen ·AdvG1 .Game 2 The simulation guesses in which of nGen’s Enc queries the challenge

is created, that is the first valid query to the Solve oracle by the adversary.Therefore nEnc is randomly sampled from [qEnc] and the simulation aborts ifeither the randomness for the nEnc’s Enc query is manipulated as thereby nochallenge would be created (lines 28,29), or the first valid query to the Solveoracle is for another challenge than the one created by nGen’s nEncth Enc query(lines 48,50), or a secret key that helps to trivially solve the challenge from nGen’snEncth Enc query is exposed (lines 29,81).

In addition, the simulation aborts if, before the nGen’s nEncth Enc query wasmade, Dec was queried on a ciphertext (with the same preceding transcript)that contains the same URKE ciphertext and ‘collision key’ ck as nGen’s nEncthEnc query (lines 28,29). As the probability of a collision in the URKE transcript(i.e., associated data and ciphertext of the first snd invocation of nGen’s nEncthEnc query were previously already provided to nGen’s nEncth Dec query under

26

the same preceding transcript) is bounded by a collision in the the key spaceK (as thereby ck as associated data must collide), we have AdvG1 = qEnc ·(

AdvG2 + 1|K|

).

Game 3 The simulation replaces the output (k, k.m) from the first sndinvocation of nGen’s nEncth Enc query by values randomly sampled.

An adversary that can distinguish between Game 2 and Game 3 can beturned into an adversary that breaks KINDR security of URKE scheme UR. Wedescribe the reduction below: The reduction obtains nGen’s public key in oracleGen via oracle ExposeA from the KINDR game. Invocations of snd in UpS tonGen are replaced by SndA and ExposeA queries. Invocations of snd in UpR tonGen are processed by the reduction itself and the subsequent rcv invocationsare replaced by RcvB queries. The state sB in queries to Expose for nGen isobtained via ExposeB queries to the KINDR game. For all queries to Enc ofnGen the snd invocations are replaced by SndA and ExposeA queries. kuKEM∗key and MAC key (k, k.m) for nGen’s Enc oracle queries are obtained via Reveal– except for nGen’s nEncth Enc query, in which these two keys are obtained fromthe Challenge oracle in the KINDR game. Invocations of rcv in the Dec oraclefor nGen are replaced by RcvB queries and Reveal queries (in case the respectivekey was not already computed in the Enc oracle). The snd invocation in oracleDec is directly computed by the reduction.

In order to show that manipulations of transcripts in the KUOWR gamemanipulate equivalently the transcripts in the KINDR game (such that the statesA in the public key diverges from state sB in the secret key iff the transcriptstrsnGen and trrnGen diverge), we define the translation array TR[·] that mapsthe transcript of nGen in the KUOWR game to the according transcripts in theKINDR game.

As Game 2 aborts if nGen’s nEncth Enc query entails no valid KINDRchallenge, or if the respective ciphertext was already crafted by the adversary(and provided to the Dec oracle), an adversary, distinguishing the real key pair(k, k.m) from the randomly sampled one, breaks KINDR security. Formally,the solution for nGen’s nEncth Enc query to the Solve oracle is compared withthe challenge key k from the KINDR Challenge oracle (which is obtained duringnGen’s nEncth Enc query): If the keys equal, the reduction terminates with b′ = 0(as thereby the KINDR game’s challenge entailed the real key), otherwise itterminates with b′ = 1.

Consequently we have AdvG2 ≤ AdvG3 + AdvkindrUR (BUR).

Game 4 The only way, the adversary can win in Game 3, is to keep secretkey and public key of nGen compatible (by updating them equivalently andforwarding all Enc queries to the Dec oracle) and then forwarding only the URKEciphertext c′ of nGen’s nEncth Enc query to the Dec oracle while manipulatingparts of the remaining challenge ciphertext. Thereby the Dec oracle outputs thecorrect challenge key such that the adversary trivially wins.11

11 Please note that after this manipulation, the states sA and sB in the public key andsecret key respectively diverge, but the key, output by the Dec oracle, still equalsthe challenge key. In case, the URKE ciphertext c′ from the challenge ciphertext

27

We therefore define Game 4 to let the simulation abort if a forgery of theMAC tag for the challenge ciphertext is provided to the Dec oracle. Distinguish-ing between Game 3 and Game 4 can hence be reduced to the SUF securityof the one-time MAC M. We describe the reduction below: Instead of samplingk.m randomly, the MAC tag for nGen’s nEncth Enc query is derived from theTag oracle of the SUF game. Since an abort requires that the URKE challengeciphertext c′ is indeed received in oracle Dec (and also the transcripts prior tothis ciphertext equal for trsnGen and trrnGen), the URKE key (containing k.m)equals. As a consequence, a crafted ciphertext (pk, c′, τ), provided to the Decoracle, is a forgery τ for message (pk, c′) in the SUF game.

Consequently we have AdvG3 ≤ AdvG4 + AdvsufM (BM).

As the challenge key from nGen’s nEncth Enc query is randomly sampled andcannot be derived from any other oracle, the advantage of winning in Game 4is AdvG4 = 0.

Summing up the advantages above, we have:

AdvkuowrK (A) ≤ qGenqEnc ·

(Advkindr

UR (BUR) + AdvsufM (BM) + 1

|K|

)≤ qGenqEnc ·

(2 ·Advkindr

UR (BUR) + 1|K|

)where the latter follows from an SUF secure one-time MAC construction from ageneric KINDR secure URKE scheme UR (which is described in Appendix E).

ut

7 Discussion

Our results clearly show that key-updatable key encapsulation is a necessarybuilding block for optimally secure ratcheted key exchange, if the security defi-nition of the latter regards manipulation of the algorithm invocations’ randomcoins. As unidirectional RKE can naturally be built from sesquidirectional RKE,which in turn can be built from bidirectional RKE (which can be derived fromoptimally secure group RKE), our results are expected to hold also for the ac-cording security definitions under these extended communication settings. Incontrast, security definitions of ratcheting that restrict the adversary more thannecessary in exposing the local state or in solving embedded game challenges(i.e., by excluding more than unpreventable attacks) allow for instantiationsthat can dispense with these inefficient building blocks.

However, the two previous security definitions fulfilled by constructions thatuse kuKEM as a building block (cf. Table 1) consider only randomness reveal [13]or even secure randomness [20]. This raises the question whether using kuKEM inthese cases was indeed necessary (or not). The resulting gap between the notionsof ratcheting that can be built from only standard PKC and our optimally

is already provided manipulately to the Dec oracle, the challenge key is alreadyindependent from the key, computed in the Dec oracle.

28

secure URKE definition with randomness manipulation, implying kuKEM, willbe discussed in the following.

Implications under Randomness Reveal The core of our proof (showing thatURKE implies kuKEM under randomness manipulation) is to utilize URKE’sstate update in algorithms snd and rcv for realizing public key and secret keyupdates in kuKEM’s up algorithm. In order to remove the otherwise necessarycommunication between snd and rcv algorithms of RKE, snd is de-randomizedby fixing its random coins to a static value. While this de-randomization trickis not immediately possible if the reduction to URKE KIND security cannotmanipulate the randomness of snd invocations, one can utilize a programmablerandom oracle to emulate it: instead of fixing the (input) random coins of sndinvocations to a static value, one could derive these coins from the output of arandom oracle on input of the respective update’s associated data (i.e., ad inputof algorithm up). Additionally, instead of directly forwarding the update’s asso-ciated data to the associated data input of snd, another random oracle could beinterposed between them. The reduction then simply pre-computes all kuKEMup invocations independent of associated data inputs by querying the SndA or-acle in the URKE KIND game on random associated data strings. Then thereduction reveals all used random coins in the URKE KIND game and pro-grams them as output into the random oracle lazily (i.e., as soon as the adver-sary queries the random oracle on update associated data strings). By correctlyguessing, which of the adversary’s random oracle queries fit its queried kuKEMupdate invocations, the reduction can perform the same de-randomization trickas in our proof. The probability of guessing correctly is, however, exponential inthe number of queried kuKEM updates such that a useful implication may onlybe derivable for a constant number of queried updates.

In conclusion, we conjecture that URKE under randomness reveal alreadyrequires the use of a kuKEM-like building block with a constantly boundednumber of public key and secret key updates. Thereby we argue that our proofapproach partially carries over to the case of randomness reveal. This wouldindicate that the use of a kuKEM-like building block in the construction of Jaegerand Stepanovs [13] is indeed necessary. The formal analysis of this conjecture isleft as an open question for future work.

Implications under Secure Randomness For optimal security under secure ran-domness, Poettering and Rösler [20] show that URKE can be instantiated fromstandard PKC only (cf. Table 1). In contrast, their construction for sesquidi-rectional RKE (SRKE: a restricted interactive RKE variant) uses kuKEM forsatisfying optimal security under secure randomness. Since a reduction towardsSRKE (under KIND security with secure randomness) has no access to ran-dom coins respectively used in the RKE algorithms, our de-randomization trickseems inapplicable. Furthermore, while the RKE algorithms snd and rcv canuse exchanged ciphertexts for their state updates, generically transforming thisstate update to realize a ‘silent’, non-interactive key update needed for kuKEMwithout our trick appears (at least) problematic.

29

Nevertheless, it is likely that SRKE KIND security under secure randomnessrequires kuKEM-like building blocks. This intuition is based on an example at-tack by Poettering and Rösler [19, Appendix B.2]. It illustrates that a key k∗,computed by any secure SRKE construction under the following attack, needsto be indistinguishable from a random key according to this security notion.The attack proceeds as follows: 1. Alice’s and Bob’s states are exposed (sA ←ExposeA(ε); sB ← ExposeB(ε)), 2. Bob sends update information to Alice (which ispossible in SRKE) to recover from his exposure (c← SndB(ε, ε); RcvA(ε, c)). Keysestablished by Alice after receiving the update information are required to besecure again. Translated to the kuKEM setting, this step corresponds to Bob gen-erating a new key pair and publishing the respective public key. 3. SimultaneouslyAlice is impersonated towards Bob ((s′A, k′, c′) ←$ sndA(sA, ε); RcvB(ε, c′)). Thisrequires Bob’s state to become incompatible with Alice’s state. In the kuKEMsetting, this corresponds to the secret key being updated with c′ as associateddata. Note that c′ can be independent of Bob’s state update from step 2 via c,and the computation of c′ is controlled by the adversary. 4. Afterwards Bob’sstate is again exposed (s′B ← ExposeB((ε, c)‖(ε, c′))). 5. Finally, Alice sends andestablishes key k∗ which is required to be secure (c′′ ← SndA(ε, ε)). 6. ExposingAlice’s state thereafter should not harm security of k∗ (s′′A ← ExposeA((ε, c′′))).

We observe that, as with a kuKEM public key, Alice’s state is publicly knownduring the entire attack. Only Alice’s random coins when establishing k∗ andupdating her state, and Bob’s random coins when sending, as well as his resultingstate until he receives c′ are hidden towards the adversary. We furthermore notethat, by computing ciphertext c′, the adversary controls Bob’s state update. Asa consequence, Bob’s state update must reach forward-secrecy for key k∗ withrespect to adversarially chosen associated update data c′ and Bob’s resulting(diverged) state s′B .

All in all, the security requirements highlighted by this attack emphasize thesimilarity of kuKEM’s and SRKE’s security. Nevertheless, we note that all ourattempts to apply our proof technique for this case failed due to the above men-tioned problems. Therefore, formally substantiating or disproving the intuitionconveyed by this attack remains an open question for future work.

Open Questions and Impact With our work we aim to motivate research onanother remaining open problem: can key-updatable KEM be instantiated moreefficiently than generically from HIBE? It is, in contrast, evident that equivalencebetween HIBE and RKE is unlikely as constructions of the latter only utilize“one identity path” of the whole “identity tree” of the former.

Conclusively, we note that defining security for, and constructing schemes ofinteractive ratcheted key exchange variants (i.e., under bidirectional communica-tion) is highly complicated and consequently error-prone.5 By providing genericconstructions (instead of ad-hoc designs) and grasping core components and con-cepts of ratcheted key exchange, complexity is reduced and sources of errors areeliminated. Additionally, our equivalence result serves as a benchmark for cur-rent and future designs of ratcheted key exchange – especially group RKE. Forfuture constructions that only rely on standard public key cryptography either

30

of the following questions may arise: how far is the adversary restricted suchthat our implication is circumvented, or how far is the construction secure underthe respective security definition?

References

1. Alwen, J., Capretto, M., Cueto, M., Kamath, C., Klein, K., Pascual-Perez, G.,Pietrzak, K., Walter, M.: Keep the dirt: Tainted treekem, an efficient and prov-ably secure continuous group key agreement protocol. Cryptology ePrint Archive,Report 2019/1489 (2019), https://eprint.iacr.org/2019/1489

2. Alwen, J., Coretti, S., Dodis, Y.: The double ratchet: Security notions, proofs, andmodularization for the Signal protocol. In: Ishai, Y., Rijmen, V. (eds.) EURO-CRYPT 2019, Part I. LNCS, vol. 11476, pp. 129–158. Springer, Heidelberg (May2019)

3. Alwen, J., Coretti, S., Dodis, Y., Tselekounis, Y.: Security analysis and improve-ments for the IETF MLS standard for group messaging. Cryptology ePrint Archive,Report 2019/1189 (2019), https://eprint.iacr.org/2019/1189

4. Bellare, M., Singh, A.C., Jaeger, J., Nyayapati, M., Stepanovs, I.: Ratcheted en-cryption and key exchange: The security of messaging. In: Katz, J., Shacham, H.(eds.) CRYPTO 2017, Part III. LNCS, vol. 10403, pp. 619–650. Springer, Heidel-berg (Aug 2017)

5. Borisov, N., Goldberg, I., Brewer, E.A.: Off-the-record communication, or, why notto use PGP. In: Atluri, V., Syverson, P.F., di Vimercati, S.D.C. (eds.) Proceedingsof the 2004 ACMWPES 2004, Washington, DC, USA, October 28, 2004. pp. 77–84.ACM (2004)

6. Caforio, A., Durak, F.B., Vaudenay, S.: On-demand ratcheting with security aware-ness. Cryptology ePrint Archive, Report 2019/965 (2019), https://eprint.iacr.org/2019/965

7. Checkoway, S., Niederhagen, R., Everspaugh, A., Green, M., Lange, T., Risten-part, T., Bernstein, D.J., Maskiewicz, J., Shacham, H., Fredrikson, M.: On thepractical exploitability of dual EC in TLS implementations. In: Fu, K., Jung, J.(eds.) USENIX Security 2014. pp. 319–335. USENIX Association (Aug 2014)

8. Cohn-Gordon, K., Cremers, C.J.F., Dowling, B., Garratt, L., Stebila, D.: A formalsecurity analysis of the signal messaging protocol. In: 2017 IEEE European Sym-posium on Security and Privacy, EuroS&P 2017, Paris, France, April 26-28, 2017.pp. 451–466 (2017)

9. Durak, F.B., Vaudenay, S.: Bidirectional asynchronous ratcheted key agreementwith linear complexity. Cryptology ePrint Archive, Report 2018/889 (2018),https://eprint.iacr.org/2018/889

10. Durak, F.B., Vaudenay, S.: Bidirectional asynchronous ratcheted key agreementwith linear complexity. In: Attrapadung, N., Yagi, T. (eds.) IWSEC 19. LNCS,vol. 11689, pp. 343–362. Springer, Heidelberg (Aug 2019)

11. Heninger, N., Durumeric, Z., Wustrow, E., Halderman, J.A.: Mining your ps andqs: Detection of widespread weak keys in network devices. In: Kohno, T. (ed.)USENIX Security 2012. pp. 205–220. USENIX Association (Aug 2012)

12. Hofheinz, D., Hövelmanns, K., Kiltz, E.: A modular analysis of the Fujisaki-Okamoto transformation. In: Kalai, Y., Reyzin, L. (eds.) TCC 2017, Part I. LNCS,vol. 10677, pp. 341–371. Springer, Heidelberg (Nov 2017)

31

13. Jaeger, J., Stepanovs, I.: Optimal channel security against fine-grained statecompromise: The safety of messaging. In: Shacham, H., Boldyreva, A. (eds.)CRYPTO 2018, Part I. LNCS, vol. 10991, pp. 33–62. Springer, Heidelberg (Aug2018)

14. Jaeger, J., Stepanovs, I.: Optimal channel security against fine-grained state com-promise: The safety of messaging. Cryptology ePrint Archive, Report 2018/553(2018), https://eprint.iacr.org/2018/553

15. Jost, D., Maurer, U., Mularczyk, M.: Efficient ratcheting: Almost-optimal guar-antees for secure messaging. In: Ishai, Y., Rijmen, V. (eds.) EUROCRYPT 2019,Part I. LNCS, vol. 11476, pp. 159–188. Springer, Heidelberg (May 2019)

16. Langley, A.: Source code of Pond (05 2016), https://github.com/agl/pond17. Marlinspike, M., Perrin, T.: The double ratchet algorithm (11 2016),

https://whispersystems.org/docs/specifications/doubleratchet/doubleratchet.pdf

18. Off-the-Record Messaging. http://otr.cypherpunks.ca (2016)19. Poettering, B., Rösler, P.: Asynchronous ratcheted key exchange. Cryptology

ePrint Archive, Report 2018/296 (2018), https://eprint.iacr.org/2018/29620. Poettering, B., Rösler, P.: Towards bidirectional ratcheted key exchange. In:

Shacham, H., Boldyreva, A. (eds.) CRYPTO 2018, Part I. LNCS, vol. 10991, pp.3–32. Springer, Heidelberg (Aug 2018)

21. Raimondo, M.D., Gennaro, R., Krawczyk, H.: Secure off-the-record messaging. In:Atluri, V., di Vimercati, S.D.C., Dingledine, R. (eds.) Proceedings of the 2005ACM WPES 2005, Alexandria, VA, USA, November 7, 2005. pp. 81–89. ACM(2005)

22. Rescorla, E., Salter, M.: Extended random values for tls (2009), https://tools.ietf.org/html/draft-rescorla-tls-extended-random-02

23. Yilek, S., Rescorla, E., Shacham, H., Enright, B., Savage, S.: When private keysare public: results from the 2008 debian openssl vulnerability. In: Proceedings ofthe 9th ACM SIGCOMM Internet Measurement Conference, IMC 2009, Chicago,Illinois, USA, November 4-6, 2009. pp. 15–27 (2009)

32

A Proof Figure for KUOWR Security under KINDR Security

Simulation S00 n← 001 nGen ←$ [qGen] G≥102 nEnc ←$ [qEnc]; e← 0 G≥203 tr◦ ← ε; c◦ ← ⊥ G≥204 k• ← ⊥; k.m• ← ⊥; ck• ← ⊥; c• ← ⊥ G≥305 Invoke A06 Stop with 0

Oracle Gen07 n← n+ 108 If n = nGen: T[·]← ⊥ G=309 (sA, sB)←$ init10 pkn ← sA; skn ← (sA, sB)11 CKn[·]← ⊥; XPn ← ∅12 trsn ← ε; trrn ← ε13 SKn[·]← ⊥; SKn[trrn]← skn

14 Return pkn

Oracle UpS(i, ad)15 Require 1 ≤ i ≤ n ∧ ad ∈ AD16 (pki, k, c)← snd(pki, (0, ad); 0)17 If i = nGen: G=318 T[trsi‖ad]← T[trsi]‖((0, ad), c) G=3

19 trsiq← ad

20 Return pki

Oracle Enc(i, rc)21 Require 1 ≤ i ≤ n22 Require rc ∈ R ∪ {ε}23 If rc = ε: mr ← F; rc ←$ R24 Else: mr ← T25 ck ←$ K26 (pki, (k, k.m), c′)←$ snd(pki, (1, ck); rc)27 If i = nGen ∧ e = nEnc: G≥228 If mr = T ∨ (∃pk′ ∈ PK, τ ′ ∈ T :

trsi‖(ck, pk′, c′, τ ′) ∈ XPi

∨trsi‖(ck, pk′, c′, τ ′) � trr i): G≥229 Abort G≥230 (ck•, c•)← (ck, c′) G≥331 (k•, k.m•)←$ KUR; (k, k.m)← (k•, k.m•) G≥332 τ ←$ tag(k.m, (ck, pki, c

′))33 c← (ck, pki, c

′, τ)34 (pki, c

′′, k′′)← snd(pki, (2, c); 0)35 If i = nGen: G≥236 If e = nEnc: G≥237 tr◦ ← trsi; c◦ ← c G≥238 e← e+ 1 G≥239 T[trsi‖c]←T[trsi]‖((1, ck), c′)‖((2, c), c′′) G=3

40 trsiq← c

41 If mr = F: CKi[trsi]← k42 Return (pki, c)

Oracle Solve(i, tr , k)43 Require 1 ≤ i ≤ n44 Require tr /∈ XPi

45 Require CKi[tr ] 6= ⊥46 Reward k = CKi[tr ] G<147 If i = nGen: G≥148 If tr = tr◦‖c◦: G≥249 Reward k = CKi[tr ] G≥1,250 Else if k = CKi[tr ]: Abort G≥151 Return

Oracle UpR(i, ad)52 Require 1 ≤ i ≤ n ∧ ad ∈ AD53 (sA, sB)← SK i[trr i]54 (sA, k, c)← snd(sA, (0, ad); 0)55 (sB , k)← rcv(sB , (0, ad), c)56 If i = nGen: G=357 T[trr i‖ad]← T[trr i]‖((0, ad), c) G=3

58 trr iq← ad

59 SK i[trr i]← (sA, sB)60 Return

Oracle Dec(i, c)61 Require 1 ≤ i ≤ n ∧ c ∈ C62 (sA, sB)← SK i[trr i]63 (ck, pk, c′, τ)← c64 (sB , (k, k.m))← rcv(sB , (1, ck), c′)65 If trr i = tr◦ ∧ (ck•, c•) = (ck, c′) 6= (⊥,⊥): G≥366 (k, k.m)← (k•, k.m•) G≥367 Require vfyM(k.m, (ck, pk, c′), τ)68 If trr i = tr◦ ∧ c 6= c◦

∧(ck•, c•) = (ck, c′) 6= (⊥,⊥): G≥469 Abort G≥470 (sA, k

′′, c′′)← snd(pk, (2, c); 0)71 (sB , k

′′′)← rcv(sB , (2, c), c′′)72 If i = nGen: G=373 T[trr i‖c]← T[trr i]‖((1, ck), c′)‖((2, c), c′′) G=3

74 trr iq← c

75 SK i[trr i]← (sA, sB)76 If CKi[trr i] 6= ⊥:77 Return78 Return k

Oracle Expose(i, tr)79 Require 1 ≤ i ≤ n80 Require SK i[tr ] ∈ PK × SK81 If tr � tr◦: Abort G≥282 XPi

∪← {tr∗ ∈ (AD ∪ C)∗ : tr ≺ tr∗}83 (sA, sB)← SK i[tr ]84 Return (sA, sB)

Fig. 10: Games of simulation for proof of KUOWR security for construction from Figure 9.

33

B Full Proof of URKE KINDR Security

Below we describe the full proof of Theorem 1 for which a sketch is in Section 5.

Proof (Theorem 1).The high-level organization of our proof is as follows: We first expand the KINDR security game by

replacing each generic call to URKE’s algorithms with their actual instantiation in the UR construction.Then, starting from this game, we insert and remove lines of codes in the game, in such a way that theinteraction of A with the game never changes, i.e. the game-hops are merely bridging steps. Therefore, wedefine new games that look different in code, but are essentially same, and A’s advantage does not changefrom one to another. Our motivation behind these syntactic updates is to prepare the game for reductionsto KUOWR and SUF security games of kuKEM∗ and MAC respectively. Finally, we describe in detail howthese reductions work.

Although, the type of transcripts collected by variables tr ∈ (AD × C × T )∗ (after expansion of theUR construction w.r.t. the original KINDR definition) and t ∈ (AD × C)∗ (from the UR construction) aredifferent, tr can be reduced to (AD×C)∗ by removing the tag part τ from each element in the list. Therefore,t � tr , t ≺ tr and {t} ∈ X ⊆ (AD × C × T )∗ should be interpreted as abuse of notation frequently usedthroughout the proof.

Game 0 The original KINDR game of URKE where invocation of UR’s algorithms are expanded accordingto Figure 7. We also simulate the random oracle with H as described in Figure 12.

Game 1 In order to prepare the game simulation to the KUOWR reduction, we make few syntacticalmodifications in the game which does not affect the advantage of the adversary. Namely, the new simulationkeeps two lists: CK for challengeable keys and NK for non-challengeable keys. Intuitively, CK is synchronizedwith CKi list defined in the KUOWR game in Figure 4, therefore any (non-trivial) hash query containing akey from CK will lead to a win. CK is updated only when the random coins used by the encapsulation aresampled by the oracle, but not chosen by the adversary. This condition is captured in line 24 in Figure 11.

On the other hand, NK represents the rest of the keys derived in the game and can be thought ascomplementary to CK. Although the keys from NK might allow the adversary A to win the KINDR game,it does not lead to a winning reduction in the KUOWR game, because the latter only rewards keys thatbelongs to CK (line 24 in Figure 4).

Game 2 We split the random oracle interfaces into two: H works with input (K, k, t) and G works onlywith t. The adversary uses H, and the simulator uses G for hash queries. G allows the simulator to producekeys (k.o,K, k.m, k.u) by programming the hash output of the yet-unknown key k or even the symmetricstate key K.

More precisely, dictionaries LH, LG are used for bookkeeping, whose all entries are set to ⊥ initially.Query inputs (K, k, t) and t are directly used as access keys to their corresponding entries in the dictionaries.For repeating queries, oracles return their previous answer for consistency. Otherwise, when a hash query ismade with input (K, k, t) (resp. t), H (resp. G) checks whether there is a matching entry in LG (resp. LH),and if so, it copies the key into LH[K, k, t] (resp. LG[t]). Otherwise, a fresh key is sampled for LH[K, k, t](resp. LG[t]).

We now focus on keeping G and H in harmony when queries are intertwined. This boils down to deter-mining whether given (K, k, t) tuple matches a transcript t with respect to the history of states and keys ofthe game. This is captured by the Match in Figure 12 which takes (K, k, t) as input and decides whether(K, k) and t are matching each other, with the help of states SA, SB and derived key lists CK,NK.

Therefore, the game follows exactly same and the advantage of the adversary remains same.Game 3 We now isolate K, which we call the symmetric state key, that resides in the both states of the

sender and the receiver. Our ultimate goal is to show that the adversary cannot recover the symmetric statekey K, except some trivial state exposures, therefore making a hash query with a matching K requires acollision on the domain K.

Our argument is that since keys K are never used besides as input to random oracle, the view of A shouldbe independent of choices of K values, therefore it has no information over them. This independence worksso long as a symmetric state key K is not a part of states known by A which are due to state exposurequeries and malicious random coins connected to these states. However, A’s knowledge is strictly limited

34

Simulation KINDRbUR(A)

00 trs ← ε; trr ← ε; XPA ← ∅01 MR ← ∅; KN← ∅; CH← ∅02 SA[·]← ⊥; SB [·]← ⊥; key[·]← ⊥03 NK[·]← ⊥; CK[·]← ⊥ G≥104 TK[·]← ⊥ G≥305 MK[·]← ⊥ G≥406 kuowr ← F; suf ← F; coll ← F G=507 (pk, sk)←$ genK08 K ←$ K; k.m ←$ K; t← ε09 sA ← (pk,K, k.m, t)10 sB ← (sk,K, k.m, t)11 SA[trs]← sA; SB [trr ]← sB ; b′ ←$ A12 Require KN ∩ CH = ∅13 Stop with b′

Oracle SndA(ad, rc)14 Require ad ∈ AD ∧ rc ∈ R ∪ {ε}15 (pk,K, k.m, t)← sA

16 pk′ ← pk G≥117 If rc = ε: (pk, k, c)←$ enc(pk)18 Else: (pk, k, c)← enc(pk; rc)19 k.m ← MK[t] G≥420 τ ←$ tag(k.m, (ad, c))21 C ← (c, τ); t q← (ad, c)22 (k.o,K, k.m, k.u)← H(K, k, t) G<223 (k.o,K, k.m, k.u)← G(t) G≥224 If rc = ε: CK[t]← k G≥125 Else: (_,NK[t],_)← enc(pk′; rc) G≥126 pk ← up(pk, k.u)27 sA ← (pk,K, k.m, t)28 If rc 6= ε:29 MR ∪← {trs‖(ad, C)}30 If trs ∈ XPA:31 KN ∪← {trs‖(ad, C)}32 XPA

∪← {trs‖(ad, C)}33 trs q← (ad, C); key[trs]← k.o; SA[trs]← sA

34 Return C

Oracle Reveal(tr) (see Figure 6)

Oracle Challenge(tr) (see Figure 6)

Oracle RcvB(ad, C)35 Require ad ∈ AD ∧ C ∈ C ∧ sB 6= ⊥36 If trr‖(ad, C) 6� trs

∧LCP(trs, trr) ∈ XPA:37 KN ∪← {trr‖(ad, C)}38 (sk,K, k.m, t)← sB

39 (c, τ)← C40 k.m ← MK[t] G≥441 Require vfyM(k.m, (ad, c), τ)42 If trr‖(ad, C) 6� trs: suf ← t /∈ KN G=543 (sk, k)← dec(sk, c)44 If CK[trr ‖(ad, C)] = ⊥: G≥145 NK[trr ‖(ad, C)]← k G≥1

46 Require k 6= ⊥; t q← (ad, c)47 (k.o,K, k.m, k.u)← H(K, k, t) G<248 (k.o,K, k.m, k.u)← G(t) G≥249 sk ← up(sk, k.u)50 sB ← (sk,K, k.m, t)51 If sB = ⊥: Return ⊥52 trr q← (ad, C); key[trr ]← k.o; SB [trr ]← sB

53 Return

Oracle ExposeA(tr) (see Figure 6)54 Require SA[tr ] ∈ SA

55 XPA∪← {tr}

56 trace ← {tr∗ ∈ T R∗ : ∀tr ′ ∈ T R∗(tr ≺ tr ′ � tr∗ =⇒ tr ′ ∈ MR)}

57 KN ∪← trace; XPA∪← trace

58 If TK[t] = ⊥: TK[t]←$ K G≥359 SA[tr ][1]← TK[t] G≥360 SA[tr ][2]← MK[t] G≥461 Return SA[tr ]

Oracle ExposeB(tr)62 Require SB [tr ] ∈ SB

63 · KN ∪← {tr∗ ∈ T R∗ : tr ≺ tr∗}64 If TK[t] = ⊥: TK[t]←$ K G≥365 SB [tr ][1]← TK[t] G≥366 SB [tr ][2]← MK[t] G≥467 Return SB [tr ]

Fig. 11: The simulation of KINDR game, extended with regards to UR construction. SA[t][i] refers to i-th elementof SA[t] = (pk,K, k.m, t) tuple where indexing starts from 0, and goes upto 3. Although, the type of transcriptscollected by tr ∈ (AD × C × T )∗ and t ∈ (AD × C)∗ are different, tr can be reduced to (AD × C)∗ by removing thetag part τ from each element in the list.

to these chains of states. We utilize KN array introduced by the original game definition to keep track ofsymmetric state keys K known by A.

In order to show independence of state keys K from rest of the values derived in the game, we use lazysampling forK. Initially all values of TK are set to ⊥. Then, we ignoreK that resides in the state informationcompletely, and always use the corresponding state key from TK[t] for a transcript t. A can receive TK[t]values either by exposing the state of A or B; or through querying the hash oracle H. Therefore, we returnthese symmetric state keys to A by overwriting the values of SA[t],SB [t], in lines 59,65 of Figure 11.

35

Oracle H(K, k, t) G≥000 (k.o,K, k.m, k.u)←$ K4

01 If LH[K, k, t] 6= ⊥:02 (k.o,K, k.m, k.u)← LH[K, k, t]03 Else if LG[t] 6= ⊥ ∧Match(K, k, t): G≥204 (k.o,K, k.m, k.u)← LG[t] G≥205 K ← TK[t] G≥306 k.m ← MK[t] G≥407 LH[K, k, t]← (k.o,K, k.m, k.u)08 Return (k.o,K, k.m, k.u)

Oracle G(t) G≥209 (k.o,K, k.m, k.u)←$ K4

10 If LG[t] 6= ⊥:11 (k.o,K, k.m, k.u)← LG[t]12 Else if ∃k,K LH[K, k, t] 6= ⊥

∧Match(K, k, t):13 (k.o,K, k.m, k.u)← LH[K, k, t]14 Else: MK[t]←$ K G≥415 LG[t]← (k.o,K, k.m, k.u)16 Return (k.o,K, k.m, k.u)

Predicate Match(K, k, t) G≥217 If t = ε: Return F18 t′‖(ad, c)← t19 If t � trs: K′ ← SA[t][1] G<320 Else: K′ ← SB [t][1] G<321 If TK[t] = ⊥: G≥322 TK[t]←$ K; K′ ← TK[t] G≥323 If K′ = K:24 kuowr ← CK[t] = k ∧ t /∈ KN G=525 coll ← t /∈ KN G=526 Return CK[t] = k ∨NK[t] = k27 Return F

Fig. 12: The simulation of the random oracle during KINDR security game of UR construction through separateinterfaces H (accessible by the adversary) and G (accessible by the game oracles). We assume there is mapping fromthe type of tr to the type of t, as explained in the caption of Figure 11.

Lastly, before returning TK[t] to A, we also make sure that its value is initialized. This initialization ishandled in lines 58,64 in Figure 11 and line 22 in Figure 12.

These changes are again syntactical and does not affect A’s advantage.Game 4 We perform the similar changes of Game 3 for MAC keys. We add a new array MK for MAC

keys. In SUF game, we recall that the adversary can request the generation of multiple MAC keys, andexpose a subset of them adaptively. Its final goal is to forge a message and a MAC for one of the unexposedkeys.

For ExposeA and ExposeB, we again overwrite k.m keys from the array MK. For G(t) queries, we treatk.m keys specially. Namely, for each fresh G(t) query, we initialize a new MAC key as MK[t]. We again usethe array KN to keep track of revealed MAC keys.

Game 5 We introduce three boolean flags, all of which are initially set to F. Conditioned on A making aspecial hash query, i.e. a hash query that reveals one of the challengeable keys, then these flags will assumethe following meanings:

– kuowr flag in line 24 of Figure 12 captures whether the adversary made a special hash query, from whichwe can recover the key k to win the KUOWR game.

– coll flag in line 25 of Figure 12 captures A’s correct guess on K for one of the states not exposed to Ain one of its hash queries, which leads to a collision in K.

– suf flag in line 42 of Figure 11 captures the RKE ciphertext forgery which contains a MAC forgery, andleads to a win in the SUF game.

Finally we classify all cases for which A wins the KINDR game by making a special hash query H(K, k, t)such that its matching G(t) query was made by the game simulation to derive either CK[t] or NK[t] witht /∈ KN. Suppose that a special hash query is made for one of:

– CK[t] where t � trs. This sets the flag kuowr to T during the game, because the special hash queryprovides the correct key k of the underlying encapsulation.

– NK[t] where t � trs. This implies that the last encapsulation query leading to NK[t] used maliciousrandom coins chosen by A, and t /∈ XPA. This query sets the flag coll to T.

36

– NK[t] where t 6� trs. This implies that t � trr and t /∈ KN. Then, either the forgery flag suf or thecollision flag coll is set to T during the game. The reason is that either B receives a MAC whose key isnot exposed (meaning coll = F), or a previous hash query exposed the MAC key (meaning coll = T).We should treat the ordering of these flags with care, as they will determine the order of abortion.

By the definition of Game 5, since kuowr =⇒ coll (i.e. whenever the former is triggered, the latteris also triggered), we consider coll ∧ ¬kuowr as collisions over K. Secondly, since a MAC forgery requirescoll = F (otherwise the MAC key is exposed, so the forgery becomes trivial) besides suf = T, we considersuf ∧¬coll∧¬kuowr for MAC forgeries. Thereby, we bound the probability of events, each of which is disjointto the others.BK: Reduction to KUOWR. We define the reduction BK which replaces kuKEM∗ operations with the oraclesof KUOWR game. More precisely, the difference between BK and G5 are as follows:– Instead of generating key pairs, BK receives the public key from KUOWR and assigns ⊥ to the secret

key. The line 07 is replaced by sk ← ⊥; pk ← Gen().– In SndA, encapsulation and key update operations are passed to the KUOWR game. Lines 17,18 are

updated as (pk, c)← Enc(1, rc); and line 26 is replaced with pk ← UpS(1, ku).– In RcvB, decapsulation and key update operations are passed to the KUOWR game. Line 43 is updated

as k ← Dec(1, c); and line 49 is updated as UpR(1, k.u).– When A requests ExposeB with tr , Expose(1, tr ′) query is made in KUOWR, where tr ′ is an array ofc and k.u values that matches the corresponding key in KUOWR, and its value is extracted from trand the table of internal hash queries LG. BK stores the recovered secret key sk in SA[tr ] (which mightpreviously contain sk = ⊥).

– The predicate Match is also updated. Specifically, we only expand the condition in line 26 of Figure 12.If t ∈ KN, BK can compute the key CK[t] by iteratively applying dec algorithm by using the stateinformation contained in SB . If t /∈ KN, then BK uses the Solve oracle of KUOWR. If Solve does notabort with rewarding a win, then it can be deduced that CK[t] 6= k.

– If A terminates with failure, BK aborts with failure.

Bounding collisions over K. The total number of keys stored in TK array is bounded by the number of statesthat can be generated through send and receive calls, i.e. qSndA + qSndB at most. If A makes qH hash queries,then the probability of guessing the key TK[t] for some t /∈ KN is bounded by qH·(qSndA+qRcvB)

|K| . If we treatcollision finding over K as a game, then this reduction would abort with failure either if kuowr is triggeredor if A terminates with failure. Therefore the success is captured by coll ∧ ¬kuowr .BM: Reduction to SUF. We define the reduction BM which replaces MAC key generation, tagging and verifi-cation operations with the oracles of the SUF game. More precisely, the difference between BM and G5 areas follows:– During the initialization, instead of generating a MAC key, the Gen oracle of the SUF game is called,

and ⊥ is assigned to MK[ε].– In the SndA oracle, the tagging algorithm tag is replaced with a Tag oracle of SUF.– In the RcvB oracle, the tag verification algorithm vfyM is replaced with a Vfy oracle of SUF.– In the ExposeA,ExposeB oracles, the MAC keys are first revealed via oracle Expose of the SUF game,

and then the updated state is returned.– For any update in KN, we also expose the added keys.– Inside G(t), we request the generation of a new MAC key from the SUF game, instead of sampling a

fresh k.m.– BM aborts with failure if kuowr ∨ coll is set to T at any point, or A terminates with failure.Since a special forgery implies kuowr ∨ coll ∨ suf , we conclude that:

AdvkindrUR (A) ≤ Pr[kuowr ] + Pr[coll ∧ ¬kuowr ] + Pr[suf ∧ ¬kuowr ∧ ¬coll]

therefore:Advkindr

UR (A) ≤ AdvkuowrK (BK) + qH · (qSndA + qRcvB)

|K|+ Advsuf

M (BM)

ut

37

C Insufficiency of Previous URKE Schemes

As described before, both previous unidirectional RKE security definitions are slightly weaker than ours,allowing the instantiations to bypass our equivalence result. In the following we describe (non-trivial) attacksaccording to our security definition against both schemes.

As Poettering and Rösler already described [20], due to only allowing exposures of A in the unidirec-tional RKE security definition of Bellare et al. [4], no forward secure state update for B is required duringinvocations of the rcv algorithm. Accordingly, when exposing the state of B (which contains a static secretkey) in the scheme by Bellare et al., all established keys between A and B become insecure (as opposed toonly keys established with this exposed or future states).Example: c← SndA(ε, ε); RcvB(ε, c); c′ ← SndA(ε, ε); RcvB(ε, c′); sB ← ExposeB((ε, c)‖(ε, c′)); (X,σ)← c;(hk, y, i, . . . )← sB ; k ← H(hk, (i, σ,X,Xy)); Return k = Challenge((ε, c))

While allowing the adversary to expose B’s state in their unidirectional RKE security definition, Poet-tering and Rösler [20] do not consider randomness reveal (nor manipulation of randomness) in their model.Their unidirectional RKE scheme exploits this in the state update of A and B during the invocation of sndand rcv respectively. The new state of A during the snd invocation is derived by generating a new KEMkey pair based on the randomness of this invocation together with the secrets in the previous state of A.The secret key of this KEM key pair is immediately discarded and only the public key is stored in A’s state.B derives the corresponding secret key from the ciphertext that he receives from A and his previous statesecrets. As a consequence, an adversary obtains B’s current secret key (and thereby all his future secretkeys) as soon as it once knows the current state of A and then manipulates randomness for the subsequentinvocation of snd.Example: sA ← ExposeA(ε); (rc0‖rc1) ←$ R; c′ ← SndA(ε, rc0‖rc1); c ← SndA(ε, ε); (pk,K, km, t) ← sA;(k′e, c′e) ← enc(pk; rc0); t ← (ε, c′) (k′,K, km, sk) ← H(K, ke, t); (ce, τ) ← c; ke ← dec(sk, ce); t q← (ε, c);(k,K, km, sk)← H(K, ke, t); Return k = Challenge((ε, c′)‖(ε, c))

D Insufficiency of Weakly Updatable PKE

Apart from the kuKEM notion by Poettering and Rösler [20] (similar to kuPKE by Jaeger and Stepanovs [13])and our enhanced kuKEM∗ notion, Jost et al. [15] introduced the notion of healable and key-updating public-key encryption (HkuPke). The former three are instantiated from HIBE and the latter can be derived fromefficient building-blocks based on Diffie-Hellman assumptions.

Intuitively, the key update mechanism in kuKEM∗ (and kuKEM) depicts a one-way function that can beapplied independently on secret key and public key with respect to some associated data. It is yet unclear,how to implement this mechanism without relying on HIBE primitives.

In contrast, the intuition behind the update mechanism in HkuPke depicts a merging of an old key pairwith some update key pair (implemented via multiplying public Diffie-Hellman shares and adding their secretexponents respectively), and a deterministic deriving of new key pairs. Problems with this mechanism arethat the merging is not one-way (i.e., it can be inverted) and it either requires interaction from secret keyholder to public key holder (for transmitting the update public key), or the public key holder learns thesecret update exponent during the update (the former is the case for their first public key ekupd which istransmitted, and the latter is the case for their second public key ekeph which is derived together with itssecret key on the sender side).

Why One-Wayness is Needed in URKE It is essential for KINDR security of URKE that the following attackis harmless with respect to the security of key k for all random coins rc, rc∗ ∈ R, rc 6= rc∗:s0

A ← ExposeA(ε); ad ← ε; c1 ← SndA(ad, rc); (s1A, k

1, c1)← snd(s0A, ad; rc); (s∗A, k∗, c∗)← snd(s0

A, ad; rc∗);RcvB(ad, c∗); s∗B ← ExposeB((ad, c∗)); c2 ← SndA(ad, ε); s2

A ← ExposeA((ad, c1)‖(ad, c2)); k ← Challenge((ad, c1)‖(ad, c2))

The state updates due to oracle queries SndA(ad, rc) and RcvB(ad, c∗) (i.e., in the respective algorithminvocations of snd and rcv) must diverge states s1

A and s∗B such that they cannot be used by an adversaryto derive the key encapsulated in c2. Note that the random coins rc∗ can be arbitrarily chosen (e.g., similar

38

to rc) in order to let c∗ differ from c1 only in few bits. Since any difference between c1 and c∗ must result ina divergence of s∗B from a state that can be used to derive the key encapsulated in c2, the secrets in B’s statemust be updated on the entire incoming ciphertext. This requires a ‘one-way’ update of the secrets in B’sstate that takes c∗ as respected (associated) data. Furthermore, all computations for deriving s1

A and s∗A canbe traced and determined by the adversary, since rc and rc∗ are chosen by it. Hence, the public key update(in this state derivation) is computed publicly (and cannot rely on any inputs from B), and the secret keyupdate (in the derivation of s∗B) must respect all incoming ciphertext bits.

Consequently, the public key update is deterministic (or probabilistic on adversarially chosen randomcoins) and based on public inputs, and a secret key update is based on adversarially chosen (ciphertext as)associated data, which is what the notion of KUOWR secure kuKEM∗ (and KUOW secure kuKEM) reflectsbut the syntax of HkuPku does not allow.

We finally have two remarks: (1) Jost et al. [15] explicitly make it transparent that they do not aim toprotect against such attacks as their main goal is an efficient protocol but not optimal security (hence wedo not label it a weakness of their primitive but only an important and notable difference), but (2) theirconstruction of HkuPke itself is actually not correct – we reported this problem to the authors.

E One-Time MAC from URKE

Here we describe the construction of a one-time message authentication code from a generic URKE scheme.The symmetric key can be thought of as the random coins for the state initialization (and the tag algorithm) ofthe URKE scheme. A tag is generated by taking the message as associated data for the snd algorithm (whichis invoked on randomness that is derived from key k). The MAC tag then contains the resulting ciphertext aswell as the output key. For verification, the rcv algorithm is invoked on the message as associated data andthe ciphertext from the tag. The resulting key is then compared to the key from the MAC tag. We depictthis scheme in Figure 13.

Proc tag(k,m)00 rci‖rcs ← k01 (sA, sB)← init(rci)02 (sA, κ, c)← snd(sA,m; rcs)03 τ ← (κ, c)04 Return τ

Proc vfyM(k,m, τ)05 rci‖rcs ← k06 (sA, sB)← init(rci)07 (κ, c)← τ08 (sB , κ

′)←$ rcv(sB ,m, c)09 Require κ = κ′

10 Return T

Fig. 13: One-time MAC scheme M from generic URKE scheme UR = (init, snd, rcv).

Corollary 1. If URKE scheme UR is KINDR secure, then one-time MAC scheme M from Figure 13 isSUF secure with Advsuf

M (A) ≤ qGenqVfyAdvkindrUR (B) where qGen is the number of Gen queries and qVfy is the

number of Vfy queries in the multi-instance SUF notion.

Please note that in the proof of Theorem 2, only one instance and one tag verification are necessary,resulting in a tight proof to URKE KINDR security.

The proof of single-instance SUF security with one Vfy oracle query is immediate: The Tag oracle of theSUF game is simulated by the KINDR’s SndA and Challenge oracles to produce the MAC tag τ = (κ, c).When the (successful) adversary eventually provides a valid tag forgery τ∗ = (κ∗, c∗) to the Vfy oracle, twocases are considered:

1. If c 6= c∗, then the KINDR’s RcvB oracle is invoked on c∗ and the Challenge oracle is queried on theresulting key. If this challenge key κ′ equals κ∗, then b′ = 0 is returned to the KINDR game. Otherwiseb′ = 1 is returned.

2. If c = c∗ ∧ κ 6= κ∗, then b′ = 1 is returned.

39

Please note that the reduction looses tightness linearly in the number of Gen and Vfy queries. As queriesto Vfy either contain a known tag, an invalid tag, or a tag forgery, the simulation is straight forward: thereduction guesses, which unknown tag is the first correct tag forgery (and uses it to solve the KINDR game)and treats all remaining queries with unknown tags as invalid tags.

Below in Figure 14 we define the one-time multi-instance strong unforgeability security game SUF (whichis adopted from [19] Figure 20).

Game SUF(A)00 n← 0; XP← ∅01 Invoke A02 Stop with 0

Oracle Gen03 n← n+ 104 kn ←$ K05 mtn ← ⊥06 Return

Oracle Expose(i)07 Require 1 ≤ i ≤ n08 XP ∪← {i}09 Return ki

Oracle Tag(i,m)10 Require 1 ≤ i ≤ n11 Require m ∈M12 Require mti = ⊥13 τ ← tag(ki,m)14 mti ← (m, τ)15 Return τ

Oracle Vfy(i,m, τ)16 Require 1 ≤ i ≤ n17 Require m ∈M∧ τ ∈ T18 b← vfyM(ki,m, τ)19 If i /∈ XP ∧ (m, τ) 6= mti:20 Reward b21 Return b

Fig. 14: Security game SUF for a MAC scheme M, defining one-time multi-instance strong unforgeability.

40