Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Highly Efficient Key Exchange Protocols

with Optimal Tightness

Abstract. Authenticated key exchange protocols underlie most of mod-

ern communication security. In this paper, we give nearly-tight reductions
for two modern implicitly authenticated Diffie-Hellman protocols in the
style of the Signal and Noise protocols, which are extremely simple and
efficient. Our reductions have only a linear loss in the number of users,
implying that our protocols can be instantiated more efficiently than the
state of the art when instantiated with theoretically-sound parameters.
We also prove that our security proofs are optimal, in the sense that a
linear loss in the number of users is unavoidable for a large and natural
class of reductions.

1 Introduction

Key exchange protocols serve as a building block for nearly all globally deployed
secure communications. Their deployment involves fixing several parameters,
such as key sizes. In recent years, more and more practically deployed protocols
have received academic scrutiny, for example in the form of provable security
arguments, which has substantially improved confidence in the security of such
protocols. These arguments relate the security parameter n of a protocol to the
security parameter f (n) of an assumed-hard problem, such that breaking the
protocol with parameter n would lead to an attack on the hard problem with
parameter f (n). We say a protocol is deployed in a theoretically-sound way if n is
chosen such that the underlying problem is “hard enough” with parameter f (n).
Unfortunately, strictly speaking, many of these formal security arguments
fail to apply to deployed protocols, because f (n) is too small for the underlying
problem to be hard enough. For example, security proofs for TLS [8,19,24] have a
quadratic security loss. If one aims for “128-bit security”, and assumes 230 users
and up to 230 sessions per user (very plausible for TLS), then a theoretically-
sound choice of parameters would have to provide at least “248-bit security”.
In the case of algebraic groups for a Diffie-Hellman key exchange protocol, this
would require a group of order |G| ≈ 2496 instead of the common, 128-bit-secure
choice of |G| ≈ 2256 . If TLS is deployed with smaller groups, the proof reduces
an attack on TLS to an attack on a too-easy Diffie-Hellman problem.
It would be desirable if protocols could be deployed in practice in a theoretically
sound way. This has led to the study of so-called tight security, in which we
aim to construct proofs such that the gap between n and f (n) is as small as
possible. There have been several recent advances in this field [3, 16]. However,
these advances achieve tighter security at the cost of more complex primitives
and constructions, which themselves require more or larger keys. This leads to the
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

perhaps counter-intuitive observation that the resulting protocols have a tighter

security proof, but are substantially less efficient. For example, the GJ protocol [16]
has a constant security loss: an attack on GJ leads to an attack on decisional
Diffie-Hellman with essentially the same parameter. However, it is (like TLS and
SSH) a signed Diffie-Hellman protocol, and thus must be instantiated with a
tightly-secure signature scheme, leading to a total of seventeen exponentiations.
This can overwhelm its efficiency saving from using a smaller group. In some
sense, they overshoot their goal: they achieve tightness without actually achieving
the goal of efficient deployment in a theoretically-sound manner.
Over the past few years, implicitly-authenticated Diffie-Hellman protocols
have been deployed in the mainstream. Perhaps the most famous is the Signal
protocol [31], which encrypts messages for WhatsApp’s 1.5 billion users. Another is
the Noise protocol framework [34], whose IK pattern powers the new Linux kernel
VPN Wireguard [13]. Other such protocols in the literature include KEA+ [27]
and UM [21]. We will give a proof of a simple instance of this class, very close to
Signal’s basic design.
This isn’t in and of itself particularly noteworthy. What is noteworthy, how-
ever, is the tightness of the proof. Unlike any other proof for a protocol as simple
and efficient, our proof only incurs a security loss which is linear in the number
of users µ and constant in the number of sessions per user ℓ. This is in stark
contrast to other key exchange proofs that are typically quadratic in at least one
of these parameters, and most of the time quadratic even in their product µℓ.

Our contributions. Our contributions revolve around two protocols, which aim for
high practical efficiency when instantiated with theoretically-sound parameters.
The first protocol, which we call Π, is a simple and clean implicitly authenticated
Diffie-Hellman protocol very close to Signal, Noise-KK, KEA+ and UM. We
specify it precisely in Section 4; users exchange a single group element and perform
four group exponentiations to establish a session key. Π aims for maximal efficiency
under the Strong-DH assumption (Section 2). The second protocol, Twin-Π, needs
two more exponentiations and one more message of communication than Π, but in
return it requires only the standard CDH and DDH assumptions. It is specified in
Section 5. Both Π and Twin-Π are simple and conventional, with no heavyweight
cryptographic machinery: they exchange ephemeral keys and derive a session key
from the static-ephemeral, ephemeral-static and ephemeral-ephemeral DH values
via a hash function H. In our proofs H will be a random oracle.
Our first core contribution is to give new reductions for both protocols with
linear loss L = O(µ) in the random oracle model. This is better than almost all
known AKE protocols. Even though the loss is not constant, since our protocols
are so efficient they perform better than both fully-tight protocols and the most
efficient non-tight AKEs (when instantiated with theoretically sound parameters
and under reasonable assumptions on µ and ℓ in modern deployment settings).
In contrast to previous works, our proofs enable theoretically-sound deployment
of conventional protocols with high efficiency.
Our second core contribution is to show that the L = O(µ) tightness loss is
essentially optimal for the protocols considered in this paper, at least for “simple”

2
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

reductions. Essentially, a “simple” reduction runs a single copy of the adversary

only once. To the best of our knowledge, all known security reductions for AKE
protocols are of this type. Hence, in order to give a tighter security proof, one
would have to develop a completely new approach to prove security.
The lower-bound proof will be based on the meta-reduction techniques de-
scribed in [4]. However, these techniques are only able to handle tight reductions
from non-interactive assumptions, while our first protocol is based on the interac-
tive strong Diffie-Hellman assumption. Therefore we develop a new variant of the
approach in [4], which makes it possible to also handle the strong Diffie-Hellman
assumption.

Related work We briefly touch on some other protocols with non-quadratic

security loss. KEA+ [27] achieves L = µℓ under the Gap-DH assumption, where
the reduction takes t log t time. However, it does not achieve weak forward secrecy
in a modern model: only one side’s long term key can be corrupted.
The first AKE protocols with L independent of µ and ℓ were described by
Bader et al. [3] at TCC 2015. They describe two protocols, one with constant
security loss L = O(1) and another with loss L = O(κ) linear in the security
parameter. Both protocols make use of rather heavy cryptographic building blocks,
such as tree-based signature schemes, Groth-Sahai proofs [17], and cryptographic
pairings, and are therefore not very efficient.
Very recently, at CRYPTO 2018, Gjøsteen and Jager [16] described a more
practical protocol, which essentially is a three-message variant of “signed Diffie-
Hellman”. Even though their protocol uses a rather complex signature scheme
to achieve tightness (a single key exchange requires 17 exponentiations and the
exchange of sixteen group elements and exponents), when instantiated with
theoretically-sound parameters, then it turns out to be even more efficient then
plain signed Diffie-Hellman with EC-DSA, at least for large-scale deployments.
The security analysis is in the random oracle model [6], because the paper aims
at maximal practical efficiency.

2 Background
In this section, we recap some background and standard definitions.

Diffie-Hellman Problems The computational and decisional Diffie-Hellman prob-

lems are natural problems related to breaking the Diffie-Hellman protocol.

Definition 1. Consider the following experiment involving an adversary A. The

$
experiment samples x, y ← Zp and starts A(g x , g y ). We define the advantage of
A in solving the computational Diffie-Hellman problem as

SuccCDH x y xy
G,g (A) := Pr [A(g , g ) = g ]

Definition 2. Consider the following experiment involving an adversary A. The

$ $
experiment samples x, y, z ← Zp and tosses a coin b ← {0, 1}. If b = 1 then it

3
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

sets Z := g xy , while if b = 0 then it sets Z = g z . We define the advantage of A

in solving the decisional Diffie-Hellman problem as

AdvDDH x y
G,g (A) := |Pr [A(g , g , Z) = b] − 1/2|

The strong Diffie-Hellman problem is related to the gap Diffie-Hellman prob-

lem, except that the adversary gets a less capable oracle.

Definition 3. Consider the following experiment involving an adversary A and

$
an oracle O. The experiment samples x, y ← Zp and starts AO (g x , g y ). Whenever
the adversary queries O on input Ŷ , Ẑ ∈ G, the oracle returns 1 if and only
if Ẑ = Ŷ x . We define the advantage of A in solving the strong Diffie-Hellman
problem as
SuccsCDH
 O x y xy

G,g (A) := Pr A (g , g ) = g

A crucial tool in any tight proof using Diffie-Hellman problems is rerandomi-

sation [5], where a single Diffie-Hellman problem instance can be turned into
many, in such a way that an answer to any one of them can be turned into an
answer to the original instance. We will use this within our proofs.

The Strong Twin Diffie-Hellman Problem. The strong twin Diffie-Hellman prob-
lem was introduced by Cash, Kiltz, and Shoup at EUROCRYPT 2008 [10]. It is
closely related to the standard computational Diffie-Hellman (CDH) problem,
except that it “twins” certain group elements, in order to enable an efficient
“trapdoor-DDH” test that makes it possible to simulate a stong-CDH oracle. This
makes it possible to show that the twin-DH problem is equivalent to the standard
CDH problem.

Definition 4. Consider the following experiment involving an adversary A and

$
an oracle O. The experiment samples x0 , x1 , y ← Zp and starts AO (g x0 , g x1 , g y ).
Whenever the adversary queries O on input Ŷ , Ẑ0 , Ẑ1 ∈ G, the oracle returns 1
if and only if Ẑ0 = Ŷ x0 ∧ Ẑ1 = Ŷ x1 .
We define the advantage of A in solving the strong twin Diffie-Hellman
problem as

Succ2-CDH
 O x0 x1 y x0 y x1 y

G,g (A) := Pr A (g , g , g ) = (g ,g )

The following theorem was proven in [10, Theorem 3].

Theorem 1. Let A be a strong twin DH adversary that makes at most Q queries

to oracle O and runs in time tA . Then one can construct a DH adversary B that
runs in time tA ≈ tB such that

SuccCDH 2-CDH
G,g (B) ≥ SuccG,g (A) − Q/p

If B does not output “failure”, then its output is correct with probability at least
1 − 1/p.

4
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

3 Security Model

In this section we define our game-based key exchange security model. It is

based on the real-or-random (“RoR”) security definition of Abdalla, Fouque, and
Pointcheval [2], and incorporates the extension of [1] in order to include forward
secrecy. In this model all Test-queries share the same random bit b that is used
to determine whether the Test-query responds with a “real” or a “random” key.
We prefer to work in a RoR-model because it automatically lends itself to
tight composition with protocols that use the session keys of the key exchange
protocol. For security models where each Test-query is answered based on an
individual random bit [3, 16], or where only a single Test-query is allowed, such a
composition is not automatically tight.
Although we only consider key exchange protocols with implicit authentication
in this paper, explicit authentication can be added generically by adding key-
confirmation messages to the protocol [38]. Again, since we work in a RoR-model,
we expect this transformation to work tightly.

Execution Environment. We consider µ parties P1 , . . . , Pµ . Each party Pi is

represented by a set of ℓ oracles, {πi1 , . . . , πiℓ }, where each oracle corresponds
to a session, i.e., a single execution of a protocol role, and where ℓ ∈ N is the
maximum number of protocol sessions per party. Each oracle is equipped with a
randomness tape containing random bits, but is otherwise deterministic. Each
oracle πis has access to the long-term key pair (ski , pki ) of party Pi and to the
public keys of all other parties, and maintains a list of internal state variables
that are described in the following:

– Pidsi (“peer id”) stores the identity of the intended communication partner.
– Ψis ∈ {∅, accept, reject} indicates whether oracle πis has successfully com-
pleted the protocol execution and “accepted” the resulting key.
– kis stores the session key computed by πis .
– sentsi contains the list of messages sent by πis in chronological order.
– recvsi contains the list of messages received by πis in chronological order.
– rolesi ∈ {∅, init, resp} indicates πis ’s role during the protocol execution.

For each oracle πis these variables are all initialized to the empty string ∅. The
computed session key is assigned to the variable kis if and only if πis reaches the
accept state, that is, we have kis 6= ∅ ⇐⇒ Ψis = accept.

Partnering. In order to define when two oracles are supposed to derive the same
session key we use a variant of matching conversations. In addition to agreement
on their transcripts, they should also agree upon each other’s identities and have
compatible roles (one being the initiator the other the responder). We remark
that our protocol messages consist only of group elements and deterministic
functions of them. This means that they are not vulnerable to the “no-match”
attacks of Li and Schäge [29].

5
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Definition 5 (Origin-oracle). An oracle πjt is an origin-oracle for an oracle

πis if Ψjt 6= ∅, Ψis = accept, and the messages sent by πjt equal the messages
received by πis , i.e., if senttj = recvsi .

Definition 6 (Partner oracles). We say that two oracles πis and πjt are part-
ners if (1) each is an origin-oracle for the other; (2) each one’s identity is the
other one’s peer identity, i.e., Pidsi = j and Pidtj = i; and (3) they do not have
the same role, i.e., rolesi 6= roletj .

Attacker Model. The adversary A interacts with the oracles through queries. It is
assumed to have full control over the communication network, modeled by a Send
query which allows it to send arbitrary messages to any oracle. The adversary
is also granted a number of additional queries that model the fact that various
secrets might get lost or leaked. The queries are described in detail below.

– Send(i, s, j, m): This query allows A to send any message m of its choice to
oracle πis on behalf of party Pj . The oracle will respond according to the
protocol specification and depending on its internal state. For starting a role
there are additional actions:
[Initiator] If (Pidsi , Ψis ) = (∅, ∅) and m = ∅, then this means that A requests
πis to start the initiator role with peer Pj . In this case, πis will set Pidsi := j
and rolesi := init.
[Responder] If (Pidsi , Ψis ) = (∅, ∅) and m = 6 ∅, then this means that A requests
πis to start the responder role with peer Pj with first message m. In this case,
πis will set Pidsi := j and rolesi := resp.
– RevLTK(i): For i ≤ µ, this query allows the adversary to learn the long-term
private key ski of user Pi . After the query Pi is said to be corrupted, and all
oracles πi1 , . . . , πiℓ now respond with ⊥ to all queries.
– RegisterLTK(i, pki ): For i > µ, this query allows the adversary to register a
new party Pi with public key pki . We do not require that the adversary knows
the corresponding private key. After the query the pair (Pi , pki ) is distributed
to all other parties. Parties registered by RegisterLTK are corrupted by
definition.
– RevSessKey(i, s): The is query allows the adversary to learn the session key
derived by an oracle. That is, query RevSessKey(i, s) returns the contents
of kis . Recall that we have kis = 6 ∅ if and only if Ψis = accept. After this query
s
πi is said to be revealed.

Note that unlike, e.g., [7,9], we do not allow the adversary to learn the sessions’
ephemeral randomness.

Security experiment. To define the security of a key exchange protocol we want

to evaluate the attacker’s knowledge of the session keys. For this purpose we use
a special Test query:
$
– Test(i, s): This query return kb , where k0 = ksi and k1 ← K is a random key.
After the query oracle πis is called tested.

6
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

The adversary can issue many Test queries, to different oracles, but all are
answered using the same bit b.
We now describe the AKE security game, played between an adversary A and
a challenger C. The game, denoted GΠ (µ, ℓ), is parameterized by the protocol Π
and two numbers µ (the number of honest parties) and ℓ (the maximum number
of protocol executions per party). The goal of the adversary is to guess b.
$
1. C begins by  drawing a random bit b ← {0, 1}, then generates µ long-term
key
 s pairs (ski , pki ) i ∈ [1, . . . , µ] , and initializes the collection of oracles
πi i ∈ [1, . . . , µ], s ∈ [1, . . . , ℓ] .
2. C now runs A, providing all the public keys pk1 , . . . , pkµ as input. During its
execution, A may adaptively issue Send, RevLTK, RevSessKey, RegisterLTK
and Test queries any number of times and in arbitrary order. The only
requirement is that all tested oracles remain fresh throughout the game (see
Definition 7 below). Otherwise, the game aborts and outputs a random bit.
3. The game ends when A terminates with output b′ , representing its guess of b.
If not all test oracles are fresh, the security game outputs a random bit. If all
test oracles are fresh and b′ = b, the game outputs 1. Otherwise, the game
outputs 0.

Definition 7 (Freshness). An oracle πis is fresh, written fresh(i, s), if:

(i)it has accepted,
(ii)no query Test(i, s) has been issued,
(iii)no query RevSessKey(i, s) has been issued,
(iv) no query Test(j, t) or RevSessKey(j, t) has been issued, where πjt is a partner
of πis , and
(v) Pidsi is:
(a) not corrupted until πis accepts, and
(b) not corrupted if πis has no origin-oracle.
Definition 8 (Attack events). We define the following three attack events on
game GΠ (µ, ℓ).

(i) Event breakSound occurs if there exist two partner oracles πis and πjt with
kis 6= kjt . In other words, there are two partner oracles which compute different
session keys.
(ii) Event breakUnique occurs if for some oracle πis there exist distinct oracles πjt
′ ′
and πjt ′ such that πis is a partner oracle to both πjt and πjt ′ . In other words,
there exists an oracle with more than one partner oracle.
(iii) Let guessKE be the output of game GΠ (µ, ℓ). We define breakKE to be the
event guessKE = 1.

Definition 9 (AKE Security). An attacker A breaks the security of protocol

Π, if at least one of breakSound , breakUnique , or breakKE occurs in Gπ (µ, ℓ). The
advantage of the adversary A against AKE security of Π is

AdvAKE
Π (A) = max {Pr [breakSound ] , Pr [breakUnique ] , | Pr [breakKE ] − 1/2|} .

7
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

We say that A (ǫA , t, µ, ℓ)-breaks Π if its running time is t and AdvAKE

Π (A) ≥ ǫA .
Again, we include the running time of the security experiment into the running
time of A.

Security properties The core aspects of the security properties in our model are
captured by the breakKE event, combined with the adversary’s capabilities and
the restrictions imposed on them through the freshness predicate.
The freshness clauses (iii) and (iv) imply that we only exclude the reveal
of session keys of the Test or partnered sessions. This encodes both (a) key
independence, if the revealed key is different from the session key: knowing some
keys must not enable computing other keys, as well as (b) implicitly ensuring
agreement on the involved parties, since sessions that compute the same session
key but disagree on the parties would not be partnered, and reveal the Test
session’s key.
Our freshness clause (v) encodes weak forward secrecy: the adversary can learn
the peer’s long-term key after the tested session, but only if it has been passive
during the tested session. Krawzcyk [23] presented a generic attack that shows
that a class of implicitly authenticated two-message protocols cannot achieve full
forward secrecy, but only weak forward secrecy. One of our protocols falls within
this class, which also includes (H)MQV and NAXOS.
Another property captured by our model is resistance to key-compromise
impersonation attacks. Recall that KCI attacks are those where the adversary
uses a party A’s own private long-term key to impersonate other users towards
A. This is (implicitly) encoded by the absence of any adversary restrictions on
learning the private long-term key of a test-oracle itself.
Additionally, the breakUnique event captures the resistance to replay attacks.
The breakSound event serves to ensure that two parties that execute the protocol
together as expected also compute the same session key.
Some recent protocols also offer post-compromise security, in which the com-
munication partner πjt may be corrupted before πis has accepted. However, in this
work we consider only stateless protocols, which cannot achieve this goal [11].

4 Protocol Π
The Π protocol defined in Figure 1 uses a mix of static-ephemeral and ephemeral-
ephemeral Diffie-Hellman key exchanges to get an extremely efficient protocol, in
particular communications-wise, but also with respect to computational effort
required.
In order to bound AdvAKEΠ (A) for this protocol, note first that Pr [breakSound ] =
0 follows immediately from perfect correctness of the protocol. Furthermore,
since all oracles output group elements that are uniformly distributed, we have
Pr [breakUnique ] ≤ (µℓ)2 /p. Note that this probability is statistically small, even
though it contains a quadratic term. Hence, we get
AdvAKE 2

Π (A) ≤ max (µℓ) /p, |Pr [breakKE ] − 1/2|

It remains to bound Pr [breakKE ].

8
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Public Parameters: g ∈ G
Alice Bob
$ $
sk A := a ← {0, 1, . . . , p − 1} sk B := b ← {0, 1, . . . , p − 1}
pk A := g a pk B := g b

$
r ← {0, 1, . . . , p − 1}
u := g r
u
−−−−−−−−−−−−−−−−−−−−
→−
$
s ← {0, 1, . . . , p − 1}
v := g s
k :=
H(blobA,B kpk sA kub kus )
v
−
←−−−−−−−−−−−−−−−−−−−−
k :=
H(blobA,B kv a kpk rB kv r

Fig. 1. Protocol description of Π, where blobA,B = AkBkpk A kpk B kukv.

Theorem 2. Consider the protocol Π defined in Figure 1 and an adversary A

against AKE security of Π. Then there exists adversaries B1 , B2 and B3 against
strong Diffie-Hellman such that

1 ℓ2
Pr [breakKE ] ≤ + µ · SuccsCDH
G,g (B 1 ) + Succ sCDH
G,g (B 2 ) + µ · Succ sCDH
G,g (B 3 ) + .
2 p

The strong Diffie-Hellman adversaries all run in essentially the same time as A,
and make at most as many queries to their DDH oracle as A makes to its hash
oracle H.

The proof of the theorem is structured as a sequence of games, where we

bound the difference in the adversary’s advantage in each game. Then we argue
that the adversary’s advantage is 0 in the final game, from which the theorem
follows.
In order to achieve this result in the final game, we shall have our oracles
choose session keys at random, without reference to secret keys or messages.
Obviously, we have to ensure consistency with what the adversary can learn. This
means that we have to make sure that partnered oracles both choose the same
key (Game 2); that keys the adversary should be able to compute on his own are
the same as chosen by the oracle (Game 2), and that corruptions of long-term
keys that enable the adversary to compute session keys on his own return results
consistent with previous reveal queries (Game 3 and 5).
The general technique we use is to have our oracles refrain from computing the
input to the key derivation hash oracle, but instead check to see if the adversary
somehow computes it. The idea is that computing the hash input is hard to

9
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

simulate in the strong Diffie-Hellman game, but checking if someone else has
computed the hash input is easy using the DDH oracle provided in the strong
Diffie-Hellman game.
We call an oracle honest at some point if it has not yet been corrupted. There
are five types of oracles for which we will eventually replace all keys with random
for (in other words: these are the fresh oracles):

– (I) initiator oracles whose response message comes from a responder oracle,
which has same blob and which is honest when the response is received;
– (II) other initiator oracles whose intended peer is honest until the oracle
accepts;
– (III) responder oracles whose initial message comes from an initiator, which
has the same blob (up to the responder message) and which is honest when
the response is received;
– (IV) other responder oracles whose intended peer is honest until the oracle
accepts; and
– (V) oracles whose intended peer is corrupted.

Note that at the time an initiator oracle starts, we cannot know if it will be of
type I or II. However, we will know what type it is when it is time to compute
the oracle’s session key.
In the following, let Xj denote the event that the adversary wins the experi-
ment in Game j.

Game 0. Our starting point Game 0 is the security experiment defining AKE
security. We have that
Pr [breakKE ] = Pr[X0 ]. (1)

We begin with an administrative step to avoid pathologies where honest

players choose the same random nonces.

Game 1. In this game, we abort if two honest initiator oracles or two honest
responder oracles ever arrive at the same blobA,B . The probability of this hap-
pening can be upperbounded by the probability of two oracles choosing the same
nonce, and we get that
ℓ2
| Pr[X1 ] − Pr[X0 ]| ≤ . (2)
p

4.1 Preparing Oracles

Our goal in this game is to change every honest oracle so that it no longer
computes the input to the key derivation hash H, but instead checks if the
adversary computes this input and adapts accordingly. This is essential for later
games, since it allows us to replace every use of the secret key with queries to a
DDH oracle.

10
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Game 2. In this game, we modify how our oracles determine their session keys.
Note that at the point in time where an initiator oracle determines its session
key, we know its type exactly.
A type III, IV or V responder oracle with blob ikjkpk i kpk j kukv, secret key b
and nonce s does the following to determine its session key k: First, it checks to
see if any oracle queries ikjkpk i kpk j kukvkz1 kz2 kz3 have been made satisfying

z1 = pk si z2 = u b z3 = u s . (3)

If any such query is found (which is exceedingly unlikely), k is set to the corre-
sponding hash value. Otherwise, the session key is chosen at random. And if such
a hash query happens later, the hash value is set to the chosen session key.
A type I initiator oracle will simply use the key from the corresponding
responder oracle.
A type II or V initiator oracle with blob ikjkpk i kpk j kukv, secret key a and
nonce r does the following to determine its session key k: First, it checks to see
if any oracle queries ikjkpk i kpk j kukvkz1 kz2 kz3 have been made satisfying

z1 = v a z2 = pk rj z3 = v r . (4)

If any such query is found, k is set to the corresponding hash value. Otherwise,
the session key is chosen at random. And if such a hash query happens later, the
hash value is set to the chosen session key.
The only potential change in this game is at which point in time the key
derivation hash oracle value is first defined, which is unobservable. It follows that

Pr[X2 ] = Pr[X1 ]. (5)

4.2 Type IV Responder Oracles

Game 3. In this game type IV oracles choose their session key at random, but do
not modify the hash oracle unless the intended peer is corrupted. If the adversary
corrupts the intended peer i of a type IV oracle running as user j with secret key
b, nonce s and chosen key k, then from that point in time, any query of the form

ikjkpk i kpk j kukvkpk si kub kus

to the key derivation hash oracle H will result in the hash value k.
Unless one of these queries happen before user i is corrupted, the only change
is at which point in time the key derivation hash oracle value is first defined,
which is unobservable. Let F be the event that a query as above happens before
the corresponding long-term key is corrupted. Then

| Pr[X3 ] − Pr[X2 ]| ≤ Pr[F ].

Let Fi be the same event

P as F , but with the intended peer being user i. We
then have that Pr[F ] = i Pr[Fi ].

11
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Next, consider the event Ei which is that for some type IV oracle as above,
any query of the form

ikjkpk i kpk j kukvkz1 kz2 kz3 z1 = pk si = v b (6)

to the key derivation hash oracle H happens before user i is corrupted. Then
Pr[Fi ] ≤ Pr[Ei ].
We shall now bound the probability of the event Ei by constructing an
adversary against strong Diffie-Hellman. This adversary will embed its DH
challenge in some user i’s public key and type IV oracle responses for oracles
whose intended peer is user i, and recover the solution to its DH challenge from
the hash query in event Ei .

Strong Diffie-Hellman adversary B1 . The algorithm B1 takes as input a DH

challenge (x, y) and outputs a group element z. It has access to a DDH oracle
that accepts tuples of the form (g, x, z1 , z2 ). (That is, queries with the generator
g and x fixed.) Our reduction B1 runs Game 2 with the following changes: It
chooses i uniformly at random and sets user i’s public key pk i = x. For type IV
oracles whose intended peer is user i, B1 sets v = g ρ0 y, with ρ0 random. If the
adversary corrupts user i, the reduction B1 aborts. (For other users, the reduction
simply returns the secret key, as in Game 2.)
We need to recognise hash queries of the form (3) and (4) that involve user
i, as well as queries of the form (6). For (3), where user i is the responder, we
know the oracle’s nonce s, so we only need to recognise if z2 is u raised to user
i’s secret key, which can be done by submitting (g, x, u, z2 ) to the DDH oracle.
For (4), where user i is the initiator, we know the oracle’s nonce r, so we only
need to recognise if z1 is v raised to user i’s secret key, which can be done by
submitting (g, x, v, z1 ) to the DDH oracle. Finally, for (6), we need to recognise
if a group element z1 is v raised to user i’s secret key, which can be done by
submitting (g, x, v, z1 ) to the DDH oracle.
When we recognise a query like (6) where v = g ρ0 y, we know that z1 = v a ,
where a = logg x, and we output

z = z1 x−ρ0 = v a x−ρ0 = g ρ0 a y a x−ρ0 = y a .

In other words, our adversary B1 succeeds whenever Ei would happen in Game 2.

Furthermore, Ei in Game 2 can only happen before user i is corrupted, so
whenever Ei would happen in Game 2, B1 would not have aborted.
We get that

1X 1X 1
SuccsCDH
G,g (B1 ) ≥ Pr[Ei ] ≥ Pr[Fi ] = Pr[F ],
µ i µ i µ

from which it follows that

| Pr[X3 ] − Pr[X2 ]| ≤ Pr[F ] ≤ µ · SuccsCDH

G,g (B1 ). (7)

12
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

4.3 Type III Responder Oracles

Game 4. In this game type III responder oracles choose their session key at
random, and do not modify the key derivation hash oracle.
Consider a type III responder oracle for user j with secret key b, nonce s and
intended peer i, who has secret key a. Unless the adversary ever makes a hash
query of the form

ikjkpk i kpk j kukvkz1 kz2 kz3 z3 = u s , (8)

this change is unobservable.

Let F be the event that a hash query of this form is ever made. We shall bound
the probability of F by constructing an adversary against strong Diffie-Hellman.
This adversary will embed its challenge in type I or II initiator oracles’ message,
as well as in type III responder oracles’ message. It will recover the solution to
its DH challenge from the hash query in event F .

Strong Diffie-Hellman adversary B2 . The algorithm B2 takes as input a DH

challenge (x, y) and outputs a group element z. It has access to a DDH oracle
that accepts tuples of the form (g, x, z1 , z2 ). (That is, queries with the generator
g and x fixed.)
Our reduction B2 runs Game 3 with the following changes: For type I and II
initiator oracles (we cannot distinguish these at this point in time), it computes
u = g ρ0 x, with ρ0 random. For type III responder oracles, it computes u = g ρ1 y.
Note that in this game, the reduction knows all secret keys, so user corruption is
handled exactly as in Game 3.
We need to recognise hash queries of the form (4) for type II initiator oracles,
as well as queries of the form (8). In the following, let τ = logg x. For (4), where
we do not know the initiator oracle’s nonce, we do know the secret keys, which
means that we only need to recognise if z3 is v raised to logg u = ρ0 + τ . Of
course, if z3 = v ρ0 +τ , then z3 v −ρ0 = v τ , which we can detect by submitting
(g, x, v, z3 v −ρ0 ) to the DDH oracle. For (8), we must recognise if z3 is v raised to
logg u = ρ0 + τ . As above, we can detect this by submitting (g, x, v, z3 v −ρ0 ) to
the DDH oracle. Of course, when we do recognize a query such that v τ = z3 v −ρ0 ,
with v = g ρ1 y, we output

z = z3 v −ρ0 x−ρ1 = g τ ρ1 y τ g −τ ρ1 = y τ .

In other words, B2 succeeds whenever F would happen in Game 3. We get that

| Pr[X4 ] − Pr[X3 ]| ≤ Pr[F ] = SuccsCDH

G,g (B2 ). (9)

4.4 Type II Initiator Oracles

Game 5. In this game type II initiator oracles choose their session key at random,
but do not modify the hash oracle unless the intended peer is corrupted. If the
adversary corrupts the intended peer j of a type II oracle running as user i with

13
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

secret key a, nonce r and chosen key k, then from that point in time, any query
of the form
ikjkpk i kpk j kukvkv a kpk rj kv r
to the key derivation hash oracle H will result in the hash value k.
Unless one of these queries happen before the user j is corrupted, the only
change is at which point in time the key derivation hash oracle value is first
defined, which is unobservable. Let F be the event that a query as above happens
before the corresponding long-term key is corrupted. Then
| Pr[X5 ] − Pr[X4 ]| ≤ Pr[F ].
Let Fj be the same event
P as F , but with the intended peer being user j. We
then have that Pr[F ] = j Pr[Fj ].
Next, consider the event Ej which is that for some type II oracle as above,
any query of the form
ikjkpk i kpk j kukvkz1 kz2 kz3 z2 = pk rj = ub (10)
to the key derivation hash oracle H happens before user j is corrupted. Then
Pr[Fj ] ≤ Pr[Ej ].
We shall now bound the probability of the event Ej by constructing an
adversary against strong Diffie-Hellman. This adversary will embed its DH
challenge in some user j’s public key and type II oracle messages for oracles
whose intended peer is user j, and recover the solution to its DH challenge from
the hash query in event Ej .

Strong Diffie-Hellman adversary B3 . The algorithm B3 takes as input a DH

challenge (x, y) and outputs a group element z. It has access to a DDH oracle
that accepts tuples of the form (g, x, z1 , z2 ). (That is, queries with the generator
g and x fixed.)
Our reduction B3 runs Game 4 with the following changes: It chooses j
uniformly at random and sets user j’s public key pk j = x. For type I and II
initiator oracles whose intended peer is user j, B3 sets u = g ρ0 y, with ρ0 random.
If the adversary corrupts user j, the reduction B3 aborts. (For other users, the
reduction simply returns the secret key, as in Game 4.)
We need to recognise hash queries of the form (3) and (4) that involve user
j, as well as queries of the form (10). For (3), where user j is the responder, we
know the oracle’s nonce s, so we only need to recognise if z2 is u raised to user
j’s secret key, which can be done by submitting (g, x, u, z2 ) to the DDH oracle.
For (4), where user j is the initiator, we know the oracle’s nonce r, so we only
need to recognise if z1 is v raised to user j’s secret key, which can be done by
submitting (g, x, v, z1 ) to the DDH oracle. Finally, for (10), we need to recognise
if a group element z2 is u raised to user j’s secret key, which can be done by
submitting (g, x, u, z2 ) to the DDH oracle.
When we recognise a query like (10) where u = g ρ0 y, we know that z2 = v b ,
where b = logg x, and we output

z = z2 x−ρ0 = ub x−ρ0 = g ρ0 b y b x−ρ0 = y b .

14
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

In other words, our adversary B3 succeeds whenever Ej would happen in Game 4.

Furthermore, Ej in Game 4 can only happen before user j is corrupted, so
whenever Ej would happen in Game 4, B3 would not have aborted. We get that
1X 1X 1
SuccsCDH
G,g (B3 ) ≥ Pr[Ej ] ≥ Pr[Fj ] = Pr[F ],
µ j µ j µ

from which it follows that

| Pr[X5 ] − Pr[X4 ]| ≤ Pr[F ] ≤ µ · SuccsCDH
G,g (B3 ). (11)

4.5 Summary
Note that in Game 5, every session key is chosen at random independent of every
key and sent message.
For type V oracles, the key derivation hash oracle is immediately programmed
so that the session key is available to the adversary. But type V oracles have no
expectation of security, hence they are never fresh and therefore never subject to
a Test query.
For type II and IV oracles, the key derivation hash oracle is programmed
to make the session key available to the adversary only after the intended peer
is corrupted. But if the intended peer is corrupted, a type II or IV oracle will
become non-fresh, which means that it should never have been subject to a Test
query.
For type I and III oracles, the key derivation hash oracle will never make the
session key available to the adversary.
This means that for any oracle subject to a Test query, the session key is and
will remain independent of every key and sent message. Which means that the
adversary cannot distinguish the session key from a random key. It follows that
1
Pr[X5 ] = . (12)
2
It is now easy to see that Theorem 2 follows from the construction of B1 , B2 and
B3 as well as equations (1), (2), (5), (7), (9), (11) and (12).

5 Protocol Twin-Π
The proof of the Π protocol relies on strong Diffie-Hellman, which is a non-
interactive assumption. A natural goal is to look for a protocol whose proof
relies on standard non-interactive assumptions. One possible approach is to use
twinning [10] with the Π protocol. It is straightforward to apply twinning to the
static-ephemeral parts of the Π protocol, but less obvious how twinning could
apply to the ephemeral-ephemeral part.
We solve this by using a commitment trick [16] and obtain a protocol which
uses dual twinned static-ephemeral Diffie-Hellman key exchanges for authentica-
tion, combined with straight Diffie-Hellman key exchange for forward security,
shown in Figure 2.

15
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Public Parameters: g ∈ G
Alice Bob
$ $
sk A := (a0 , a1 ) ← Z2p sk B := (b0 , b1 ) ← Z2p
pk A := (xA0 , xA1 ) = (g , g a1 )
a0
pk B := (xB0 , xB1 ) = (g b0 , g b1 )

$
r ← {0, 1, . . . , p − 1}
u := g r
h := G(u)
h
−−−−−−−−−−−−−−−−−−−−
→−
$
s ← {0, 1, . . . , p − 1}
v := g s
v
−
←−−−−−−−−−−−−−−−−−−−−

k := H(blobA,B kv a0 k
v a1 kxrB0 kxrB0 kus )
u
−−−−−−−−−−−−−−−−−−−−
→−
verify h = G(u)
k := H(blobA,B kxsA0 k
xsA1 kub0 kub1 kus )

Fig. 2. Protocol description of ΠTwin , where blobA,B = AkBkpk A kpk B kukv.

Note first that again we have Pr [breakSound ] = 0, due to perfect correctness,

and Pr [breakUnique ] ≤ (µℓ)2 /p, since all oracles output group elements that are
uniformly distribute. Hence, we get

AdvAKE 2

ΠTwin (A) ≤ max (µℓ) /p, |Pr [breakKE ] − 1/2|

Again remains to bound Pr [breakKE ].

Theorem 3. Consider the protocol ΠTwin defined in Figure 2 and an adversary

A against AKE security of ΠTwin . Then there exists adversaries B1 and B3
against twin Diffie-Hellman, and B2 against Decision Diffie-Hellman such that

1 DDH ℓ2 + 3tℓ
Pr [breakKE ] ≤ +µ·Succ2-CDH 2-CDH
G,g (B1 )+AdvG,g (B2 )+µ·SuccG,g (B3 )+ .
2 p
The adversaries all run in essentially the same time as A, and the twin Diffie-
Hellman adversaries make at most as many queries to their DDH oracle as A
makes to its hash oracle H.

Note that by Theorem 1, we can tightly replace the twin Diffie-Hellman terms in
the theorem statement by ordinary computational Diffie-Hellman terms.
Since this protocol is a twinned version of Π, the proof and its ideas follow the
proof of Theorem 2 closely. However, there is one essential difference, because the

16
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Table 1. The number of group exponentiations in Π and Twin-Π compared to other

protocols in the literature. All security proofs are in the random oracle model. The
security loss is in terms of the number of users (µ) and the number of protocol instances
per user (ℓ).

Protocol #Exponentiations Assumption Security loss

HMQV [23] 2.5 CDH µ2 ℓ2†
NAXOS [26] 3 Gap-DH µ2 ℓ 2
UM [30] 3 Gap-DH µ2 ℓ 2
Kudla-Paterson [25] 3 Gap-DH µ2 ℓ
KEA+ [27] 3 Gap-DH µℓ
Π (Fig. 1) 4 Strong-DH µ
Twin-Π (Fig. 2) 6 CDH + DDH µ
GJ [16] 17 DDH 1
†
The loss is most likely even higher.

ephemeral-ephemeral part is not twinned. For this part of the proof, we instead
rely on the commitment trick [16] which allows us to do a fairly straight-forward
Decision Diffie-Hellman reduction.
We give the proof in Appendix A.

6 Efficiency Analysis
In this section we argue that our protocols are more efficient than any other
comparable protocol in the literature when instantiated with theoretically sound
parameter choices. There are two reasons. First, the most efficient key protocols
do not have tight proofs. This means that in realistic deployment scenarios
they must use larger parameters to compensate for the proof’s security loss.
Larger parameters translate into more expensive operations, with the result
being that although some protocols require fewer operations than Π and Twin-Π
(typically group exponentiations), the increase in computational cost per operation
dominates whatever advantage they might have over our protocols in terms of
number of operations.
Second, the few known key exchange protocols which do have tight proofs,
require a large number of operations or heavy cryptographic machinery. Thus,
even though they can use small parameters, such as the P-256 elliptic curve, here
the sheer number of operations dominates their advantage over our protocols.
To illustrate the first point in more detail, here are some examples of very effi-
cient key exchange protocols having non-tight security proofs: UM [30], KEA+ [27],
HMQV [23], CMQV [36], T S1/2/3 [21], Kudla-Paterson [25], NAXOS [26]. Typ-
ically, these proofs have a tightness loss between Q = µℓ and Q = µ2 ℓ2 as
illustrated for a few of the protocols in Table 1.
Suppose we now want to compare the efficiency of Π, Twin-Π, and HMQV,
aiming for around 110-bits of security. Following [16], let us imagine two different
scenarios: a small-to-medium-scale setting with µ = 216 users and ℓ = 216 sessions

17
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

per user, and a large-scale setting with µ = 232 and ℓ = 232 . To instantiate the
protocols in a theoretically sound manner we need to select a group large enough
so that the underlying DH-assumption is still hard even when accounting for
the security loss. For simplicity, we only consider selecting among elliptic curve
groups based on the NIST curves P-256, P-384, and P-521, and assume that the
CDH, DDH, and Gap-DH problems are equally hard in each group.
HMQV. Supposing HMQV has a tightness loss of Q = µ2 ℓ2 , this translates
into a loss of 264 in the small-to-medium-scale setting, and a loss of 2128
large-scale setting. To compensate we have to increase the group size by a
factor of Q2 = 2128 and Q2 = 2256 , respectively. With a target of 110-bits
security, this means we have to instantiate HMQV with curve P-384 and
P-521, respectively.
Π and Twin-Π. Both protocols’ security proofs have a tightness loss of Q = µ,
which translates into 216 in the small-to-medium-scale setting and 232 in the
large-scale setting. In the first setting P-256 is still sufficient, but in the later
setting P-384 must be used instead.

Table 2. OpenSSL Benchmark Results for NIST Curves [16, Table 1].

Curve Exp. / Sec. Time / Exp.

NIST P-256 476.9 2.1 ms
NIST P-384 179.7 5.6 ms
NIST P-521 62.0 16.1 ms

We can now compare these instantiations by multiplying the number of

exponentiations required with the cost of an exponentiation in the relevant
group. For the latter values we use the OpenSSL benchmark numbers from [16]
(reproduced in Table 2).
Despite needing more exponentiations, we observe by calculating the numbers
that Π and Twin-Π are more efficient than HMQV in both the small-to-medium-
scale setting (4 × 2.1 = 8.4 vs. 6 × 2.1 = 12.6 vs. 2.5 × 5.6 = 14), as well as in the
large-scale setting (4 × 5.6 = 22.4 vs. 6 × 5.6 = 33.6 vs. 2.5 × 16.1 = 40.3). This
is because they can soundly use smaller curves than HMQV due to the relative
tightness of their reductions.
To illustrate the second point—that Π and Twin-Π are also more efficient
than protocols with fully tight proofs—we repeat the previous exercise with the
recent protocol of Gjøsteen and Jager (GJ) which is currently the most efficient
key exchange protocol with a fully tight proof. Here we observe that although
GJ has a fully tight proof, which means that it can use P-256 independent of
the number of users and sessions, the large number of exponentiations dominates
the advantage. Concretely, in the small-to-medium-scale setting the cost of GJ is

18
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

roughly 3–4 times that of Π and Twin-Π; while in the large-scale setting it is as
efficient as Twin-Π, and marginally less efficient than Π.
Thus, absent a fully tight proof, it appears that our protocols have hit a
metaphorical “sweet spot” between security loss and computational complexity:
they can be instantiated soundly on relatively small curves, and with only a few
exponentiations.

Communication complexity. For completeness we also briefly mention communi-

cation complexity. Since in most implicitly-authenticated DH-based protocols
the user only sends a single group element, there is in practice little difference
between Π, Twin-Π, and protocols like HMQV when it comes to communication
cost. Especially if elliptic curve groups are used.
On the other hand, this is in contrast to the fully tight signature-based GJ
protocol, which in total needs to exchange: two group elements for the Diffie-
Hellman key exchange, two signatures (each consisting of a random 256-bit nonce,
two group elements, and four 256-bit exponents), and one hash value. Altogether,
this gives a total of ≈ 545 bytes communicated when instantiated for a security
level of 110–128 bits (see Section 5 of [16] for these calculations). In comparison,
Π and Twin-Π would only need to exchange around 160 to 190 bytes for the same
security level—this includes the addition of two 256-bit key-confirmation messages
for explicit entity authentication (which is needed to make the comparison fair).

7 Optimality of our Security Proofs

In this section we will show that the tightness loss of L ≈ µ in Theorem 2 and
Theorem 3 is essentially optimal—at least for “simple” reductions. Basically, a
“simple” reduction runs a single copy of the adversary only once. To the best of
our knowledge, all known security reductions for AKE protocols are of this type.
Hence, in order to give a tighter security proof, one would have to develop a
completely new approach to prove security.
Tightness bounds for different cryptographic primitives were given in [4, 12,
14, 15, 18, 20, 22, 28, 33, 35, 37], for instance. Bader et al. [4] describe a generic
framework that makes it possible to easily derive tightness lower bounds for many
different primitives, but only for reductions from non-interactive assumptions.
By adopting the techniques of [4, Section 5.1] to authenticated key exchange
protocols one can immediately prove a lower bound of L = µ for the AKE
protocols considered in this paper. However, these techniques are only able
to consider tight reductions from non-interactive assumptions, while our first
protocol is based on the interactive strong-CDH assumption. Morgan and Pass [32]
showed how to additionally capture bounded-round interactive assumptions, but
the strong-DH assumption does not bound the number of possible oracle queries,
such that we cannot user their approach directly, either.
Therefore we develop a new variant of the approach from [4], which makes
it possible to capture the sCDH-like assumption with an unbounded number
of oracle queries. For simplicity, we formulate this specifically for the class of

19
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

assumptions and protocols that we consider, but we discuss possible extensions

below.

Considered class of protocols. In the following we consider protocols where public

keys are group elements of the form pk = g x and the corresponding secret key is
sk = x. We denote the set of all protocols with this property with ΠDH .
We remark that one can generalize our results easily to unique and verifiable
secret keys, which essentially requires that for each value pk there exists only one
matching secret key sk , and that there exists an efficiently computable relation
R such that R(pk , sk ) = 1 if and only if (pk , sk ) is a valid key pair. Following [4],
one can generalize this further to so-called efficiently re-randomizable keys. We
are not aware of concrete examples of protocols that would require this generality,
and thus omit it here. All protocols considered in the present paper have keys of
the form (pk , sk ) = (g x , x), so we leave such extensions for future work.

Simple reductions from (strong) CDH. Intuitively, a simple reduction R = RO

from (strong) CDH takes as input a CDH instance (g x , g y ) and may query an
oracle O that, on input Ŷ , Ẑ, returns 1 if and only if Ŷ x = Ẑ (cf. Definition 3).
More formally:
Definition 10. A simple reduction R interacts with an adversary A as follows.
1. R receives as input a CDH instance (g x , g y ).
2. It generates µ public keys and starts A(pk 1 , . . . , pk µ ). R provides A with
access to all queries provided in the security model described in Section 3.
3. R outputs a value h.
We say that R is a (tR , ǫR , ǫA )-reduction, if it runs in time at most tR and for
any adversary A with ǫA = AdvAKE Π (A) holds that

Pr [h = g xy ] ≥ ǫR .

We say that R = RO is a reduction from the strong CDH problem if it makes at

least one query to its oracle O, and a reduction from the CDH problem if not.
Remark 1. The formalization in this section very specifically considers the compu-
tational problems CDH and sCDH, as concrete examples of reasonable hardness
assumptions that a typical security proof for the protocols considerd in this work
may be based on. We will later discuss how our results can be extended to other
interactive and non-interactive problems.
Theorem 4. Let Π be an AKE protocol such that Π ∈ ΠDH . Let |K| denote the
size of the key space of Π. For any simple (tR , ǫR , 1 − 1/|K|)-reduction RO from
(strong) CDH to breaking Π in the sense of Definition 9 there exists an algorithm
MO , the meta-reduction, that solves the (strong) CDH problem in time tM and
with success probability ǫM such that tM ≈ n · tR and
1
ǫM ≥ ǫR − .
µ

20
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Remark 2. Note that the lower bound ǫM ≥ ǫR − 1/µ implies that the success
probability ǫR cannot significantly exceed 1/µ, as otherwise there exists an
efficient algorithm M for a computationally hard problem. Note also that this
implies that the reduction cannot be tight, as it “loses” a factor of at least 1/µ,
even if the running time of R is not significantly larger than that of the adversary.

In the sequel we write [µ \ i] as a shorthand for [1 . . . i − 1, i + 1 . . . µ].

Proof. We describe a meta-reduction M that uses R as a subroutine to solve
the (strong) CDH problem. Following [4, 18], we will first describe a hypothetical
inefficient adversary A. Then we explain how this adversary is efficiently simulated
by M. Finally, we bound the success probability of M, which yields the claim.

Hypothetical adversary. The hypothetical adversary A proceeds as follows.

1. Given µ public keys pk 1 = g x1 , . . . , pk µ = g xµ , A samples a uniformly random

$
index j ∗ ← [µ]. Then it queries RevLTK(i) for all i ∈ [µ \ j ∗ ] to obtain all
secret keys except for sk j ∗ .
2. Next, A computes sk j ∗ = xj ∗ from pk j ∗ = g xj∗ , e.g., by exhaustive search.1
3. Then A picks an arbitrary oracle, say πs1 for s = (j ∗ mod µ) + 1, and executes
the protocol with πs1 , impersonating user j ∗ . That is, A proceeds exactly as
in the protocol specification, but on behalf of user j ∗ . Note that A it is able
to compute all messages and the resulting session key on behalf of user j ∗ ,
because it “knows” sk j ∗ .
4. Finally, A asks Test(s, 1). Note that this is a valid Test-query, as A has never
asked any RevSessKey-query or RevLTK(j ∗ ) to the the peer j ∗ of oracle πs1 .
If the experiment returns the “real” key, then A outputs “1”. Otherwise it
outputs “0”.

Note that A wins the security experiment with optimal success probability
1 − 1/|K|, where |K| is the size of the key space. The loss of 1/|K| is due to the
fact that the random key chosen by the Test-query may be equal to the actual
session key.

Description of the meta-reduction. Meta-reduction M interacts with reduction

R by simulating the hypothetical adversary A as follows.

1. M receives as input a CDH instance (g x , g y ). It starts R on input (g x , g y ).

2. Whenever R issues a query to oracle O, M forwards it to its own oracle.
Note that both oracles are equivalent, because M has simply forwarded the
CDH instance.
3. When R outputs public keys pk 1 = g x1 , . . . , pk µ = g xµ to A, M makes a
snapshot of the current state stR of R.
4. For j ∈ [1 . . . µ], M now proceeds as follows.
1
Note that we are considering an inefficient adversary here. As usual for meta-
reductions, we will later describe how A can be simulated efficiently.

21
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

(a) It lets A query RevLTK(i) for all i ∈ [µ \ j], in order to obtain all secret
keys except for sk j . Note that the reduction may or may not respond to
all RevLTK(i). For instance, R may abort for certain queries.
(b) Then it resets R to state stR .
5. Now M proceeds to simulate the hypothetical adversary. That is:
$
(a) It picks a uniformly random index j ∗ ← [1 . . . µ] and queries RevLTK(i)
∗
for all i ∈ [µ \ j ].
(b) Then it executes the protocol with πs1 , impersonating user j ∗ . Note that
this works only if M was able to obtain sk j ∗ in Step (4.).
(c) Finally, M lets A ask Test(s, 1). If the experiment returns the “real” key,
then A outputs “1”. Otherwise it outputs “0”.
6. If R outputs some value h throughout the experiment, then M outputs the
same value.
Note that M provides a perfect simulation of the hypothetical adversary, provided
that it “learns” sk j ∗ in the loop in Step (4.).

Analysis of the meta-reduction. M essentially runs redution R at most µ times.

Apart from that, it performs only minor additional operations, such that we have
tM ≈ n · tR .
In order to analyse the success probability of M, let us say that bad occurs, if
j ∗ is the only index for which R did not abort in Step (4.) of the metareduction.
Note that in this case M learns all secret keys, except for sk j ∗ , in which is the
only case where the simulation of A in Step (5.b) fails. Since we may assume
without loss of generality that the reduction R works for at least one index
$
j ∈ [n] and we chose j ∗ ← [µ] uniformly random, we have
1
Pr [bad] ≤ .
µ

Let win(R, A) denote the event that R outputs h = g xy when interacting

with A, and win(R, M) the corresponding event with M. Since M simulates A
perfectly unless bad occurs, we have

|Pr [win(R, A)] − Pr [win(R, M)]| ≤ Pr [bad] .

Furthermore, note that by definition we have ǫR = Pr [win(R, A)] and ǫM =

Pr [win(R, M)]. Hence we get |ǫR − ǫM | ≤ 1/µ, which in turn yields the lower
bound ǫM ≥ ǫR − 1/µ.

Generalizations. The tightness lower bound proven above makes several very
specific assumptions about the considered protocols, hardness assumptions, and
security models. The main purpose of this is to keep the formalization and proof
focused on the type of protocols that we are considering in this paper. However,
a natural question is to which extent the results also apply to more general
protocols, models, and assumptions, and whether and how the tightness bound
can be evaded by tweaking the considered setting.

22
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

First of all, we consider only protocols where long-term secrets are of the form
(pk , sk ) = (g x , x). As already briefly discussed above, one can easily generalize
this to other protocols, as long as the simulation of the hypothetical adversary by
the metareduction is able to recover properly distributed secret keys. Therefore
one can easily generalise this to arbitrary efficiently re-randomizable long-term
keys, as defined in [4]. Note that AKE protocols with tight security proof [3, 16]
therefore do not have efficiently rerandomizable keys.
In order to obtain a tighter security proof one may try to make different
complexity assumptions. These can be either non-interactive (i.e., the reduction
does not have access to an oracle O, such as e.g. DDH), or stronger interactive
assumptions. Let us first consider non-interactive assumptions. A very general
class of such assumptions was defined abstractly in [4], and it is easy to verify
that our proof works exactly the same way with such an abstract non-interactive
assumption instead of CDH.
Some stronger assumptions may easily yield tight security proofs, but not all
of them do. Consider for instance the Gap-CDH assumption, which is identical
to sCDH, except that the first input to the provided DDH-oracle is not fixed,
but can instead be arbitrary. It is easy to verify that our proof also works for
this assumption, in exactly the same way. More generally, our proof works imme-
diately for any assumption for which the “winning condition” of the reduction
is independent of the sequence of oracle queries issued by the reduction. An
example of an interactive assumptions where this does not hold is, for instance,
the trivial interactive assumption that the protocol is secure (which, of course,
immediately yields a tight security proof).
Finally, we note that our impossibility result holds also for many weaker
or stronger AKE security models. We only require that the model allows for
active attacks and provides a RevLTK query. Thus, the result immediately applies
also to weaker models that, e.g., do not provide a RevSessKey-query or only
a single Test-query, and trivially also for stronger models, such as eCK-style
ephemeral key reveals [7, 9]. It remains an interesting open question whether
stronger impossibility results (e.g., with quadratic lower bound) can be proven
for such eCK-style definitions.

8 Conclusion

We have shown that it is possible to achieve highly efficient AKE protocols which
can be instantiated with theoretically-sound parameters. Specifically, we gave
two protocol constructions which have only a linear tightness loss in the number
of users, while using only a handful of exponentiations. These constructions are
as efficient as or even more efficient than the best known AKE protocols in this
setting.
Our proofs have a linear loss, so we also showed that this is optimal: any
reduction from a protocol in our class to a wide class of hardness assumptions
must lose a factor of at least µ. Thus, our reduction is as good as can be expected.

23
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

References
1. Abdalla, M., Benhamouda, F., MacKenzie, P.: Security of the J-PAKE password-
authenticated key exchange protocol. In: 2015 IEEE Symposium on Security and
Privacy. pp. 571–587. IEEE Computer Society Press (May 2015) 5
2. Abdalla, M., Fouque, P.A., Pointcheval, D.: Password-based authenticated key
exchange in the three-party setting. In: Vaudenay, S. (ed.) PKC 2005. LNCS, vol.
3386, pp. 65–84. Springer, Heidelberg (Jan 2005) 5
3. Bader, C., Hofheinz, D., Jager, T., Kiltz, E., Li, Y.: Tightly-secure authenticated
key exchange. In: Dodis, Y., Nielsen, J.B. (eds.) TCC 2015, Part I. LNCS, vol.
9014, pp. 629–658. Springer, Heidelberg (Mar 2015) 1, 3, 5, 23
4. Bader, C., Jager, T., Li, Y., Schäge, S.: On the impossibility of tight cryptographic
reductions. In: Fischlin, M., Coron, J.S. (eds.) EUROCRYPT 2016, Part II. LNCS,
vol. 9666, pp. 273–304. Springer, Heidelberg (May 2016) 3, 19, 20, 21, 23
5. Bellare, M., Boldyreva, A., Micali, S.: Public-key encryption in a multi-user setting:
Security proofs and improvements. In: Preneel, B. (ed.) EUROCRYPT 2000. LNCS,
vol. 1807, pp. 259–274. Springer, Heidelberg (May 2000) 4
6. Bellare, M., Rogaway, P.: Random oracles are practical: A paradigm for designing
efficient protocols. In: Ashby, V. (ed.) ACM CCS 93. pp. 62–73. ACM Press (Nov
1993) 3
7. Bergsma, F., Jager, T., Schwenk, J.: One-round key exchange with strong security:
An efficient and generic construction in the standard model. In: Katz, J. (ed.)
PKC 2015. LNCS, vol. 9020, pp. 477–494. Springer, Heidelberg (Mar / Apr 2015)
6, 23
8. Bhargavan, K., Fournet, C., Kohlweiss, M., Pironti, A., Strub, P.Y., Zanella Béguelin,
S.: Proving the TLS handshake secure (as it is). In: Garay, J.A., Gennaro, R. (eds.)
CRYPTO 2014, Part II. LNCS, vol. 8617, pp. 235–255. Springer, Heidelberg (Aug
2014) 1
9. Canetti, R., Krawczyk, H.: Analysis of key-exchange protocols and their use for
building secure channels. In: Pfitzmann, B. (ed.) EUROCRYPT 2001. LNCS, vol.
2045, pp. 453–474. Springer, Heidelberg (May 2001) 6, 23
10. Cash, D., Kiltz, E., Shoup, V.: The twin Diffie-Hellman problem and applications.
In: Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 127–145. Springer,
Heidelberg (Apr 2008) 4, 15
11. Cohn-Gordon, K., Cremers, C.J.F., Garratt, L.: On Post-Compromise Security.
In: IEEE 29th Computer Security Foundations Symposium, CSF 2016, Lisbon,
Portugal, June 27 - July 1, 2016. pp. 164–178. IEEE Computer Society 8
12. Coron, J.S.: Optimal security proofs for PSS and other signature schemes. In:
Knudsen, L.R. (ed.) EUROCRYPT 2002. LNCS, vol. 2332, pp. 272–287. Springer,
Heidelberg (Apr / May 2002) 19
13. Donenfeld, J.A.: WireGuard: Next generation kernel network tunnel. In: NDSS 2017.
The Internet Society (Feb / Mar 2017) 2
14. Fleischhacker, N., Jager, T., Schröder, D.: On tight security proofs for Schnorr
signatures. In: Sarkar, P., Iwata, T. (eds.) ASIACRYPT 2014, Part I. LNCS, vol.
8873, pp. 512–531. Springer, Heidelberg (Dec 2014) 19
15. Garg, S., Bhaskar, R., Lokam, S.V.: Improved bounds on security reductions for
discrete log based signatures. In: Wagner, D. (ed.) CRYPTO 2008. LNCS, vol. 5157,
pp. 93–107. Springer, Heidelberg (Aug 2008) 19
16. Gjøsteen, K., Jager, T.: Practical and tightly-secure digital signatures and authenti-
cated key exchange. In: Shacham, H., Boldyreva, A. (eds.) CRYPTO 2018, Part II.

24
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

LNCS, vol. 10992, pp. 95–125. Springer, Heidelberg (Aug 2018) 1, 2, 3, 5, 15, 17,
18, 19, 23, 26
17. Groth, J., Sahai, A.: Efficient non-interactive proof systems for bilinear groups. In:
Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 415–432. Springer,
Heidelberg (Apr 2008) 3
18. Hofheinz, D., Jager, T., Knapp, E.: Waters signatures with optimal security re-
duction. In: Fischlin, M., Buchmann, J., Manulis, M. (eds.) PKC 2012. LNCS, vol.
7293, pp. 66–83. Springer, Heidelberg (May 2012) 19, 21
19. Jager, T., Kohlar, F., Schäge, S., Schwenk, J.: On the security of TLS-DHE in the
standard model. In: Safavi-Naini, R., Canetti, R. (eds.) CRYPTO 2012. LNCS, vol.
7417, pp. 273–293. Springer, Heidelberg (Aug 2012) 1
20. Jager, T., Stam, M., Stanley-Oakes, R., Warinschi, B.: Multi-key authenticated
encryption with corruptions: Reductions are lossy. In: Kalai, Y., Reyzin, L. (eds.)
TCC 2017, Part I. LNCS, vol. 10677, pp. 409–441. Springer, Heidelberg (Nov 2017)
19
21. Jeong, I.R., Katz, J., Lee, D.H.: One-round protocols for two-party authenticated
key exchange. In: Jakobsson, M., Yung, M., Zhou, J. (eds.) ACNS 04. LNCS, vol.
3089, pp. 220–232. Springer, Heidelberg (Jun 2004) 2, 17
22. Kakvi, S.A., Kiltz, E.: Optimal security proofs for full domain hash, revisited. In:
Pointcheval, D., Johansson, T. (eds.) EUROCRYPT 2012. LNCS, vol. 7237, pp.
537–553. Springer, Heidelberg (Apr 2012) 19
23. Krawczyk, H.: HMQV: A high-performance secure Diffie-Hellman protocol. In:
Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 546–566. Springer, Heidelberg
(Aug 2005) 8, 17
24. Krawczyk, H., Paterson, K.G., Wee, H.: On the security of the TLS protocol: A
systematic analysis. In: Canetti, R., Garay, J.A. (eds.) CRYPTO 2013, Part I.
LNCS, vol. 8042, pp. 429–448. Springer, Heidelberg (Aug 2013) 1
25. Kudla, C., Paterson, K.G.: Modular security proofs for key agreement protocols.
In: Roy, B.K. (ed.) ASIACRYPT 2005. LNCS, vol. 3788, pp. 549–565. Springer,
Heidelberg (Dec 2005) 17
26. LaMacchia, B.A., Lauter, K., Mityagin, A.: Stronger security of authenticated key
exchange. In: Susilo, W., Liu, J.K., Mu, Y. (eds.) ProvSec 2007. LNCS, vol. 4784,
pp. 1–16. Springer, Heidelberg (Nov 2007) 17
27. Lauter, K., Mityagin, A.: Security analysis of KEA authenticated key exchange
protocol. In: Yung, M., Dodis, Y., Kiayias, A., Malkin, T. (eds.) PKC 2006. LNCS,
vol. 3958, pp. 378–394. Springer, Heidelberg (Apr 2006) 2, 3, 17
28. Lewko, A.B., Waters, B.: Why proving HIBE systems secure is difficult. In: Nguyen,
P.Q., Oswald, E. (eds.) EUROCRYPT 2014. LNCS, vol. 8441, pp. 58–76. Springer,
Heidelberg (May 2014) 19
29. Li, Y., Schäge, S.: No-match attacks and robust partnering definitions: Defining
trivial attacks for security protocols is not trivial. In: Thuraisingham, B.M., Evans,
D., Malkin, T., Xu, D. (eds.) ACM CCS 17. pp. 1343–1360. ACM Press (Oct / Nov
2017) 5
30. Menezes, A., Ustaoglu, B.: Security arguments for the UM key agreement protocol
in the NIST SP 800-56A standard. In: Abe, M., Gligor, V. (eds.) ASIACCS 08. pp.
261–270. ACM Press (Mar 2008) 17
31. Messenger, S.: Technical information, https://signal.org/docs/ 2
32. Morgan, A., Pass, R.: On the security loss of unique signatures. Cryptology ePrint
Archive, Report 2018/905 (2018), https://eprint.iacr.org/2018/905, to appear
at TCC 2018 19

25
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

33. Paillier, P., Vergnaud, D.: Discrete-log-based signatures may not be equivalent to
discrete log. In: Roy, B.K. (ed.) ASIACRYPT 2005. LNCS, vol. 3788, pp. 1–20.
Springer, Heidelberg (Dec 2005) 19
34. Perrin, T.: Noise protocol framework, http://noiseprotocol.org// 2
35. Seurin, Y.: On the exact security of Schnorr-type signatures in the random oracle
model. In: Pointcheval, D., Johansson, T. (eds.) EUROCRYPT 2012. LNCS, vol.
7237, pp. 554–571. Springer, Heidelberg (Apr 2012) 19
36. Ustaoglu, B.: Obtaining a secure and efficient key agreement protocol from (H)MQV
and NAXOS. Des. Codes Cryptography 46(3), 329–342 (2008), https://doi.org/
10.1007/s10623-007-9159-1 17
37. Wang, Y., Matsuda, T., Hanaoka, G., Tanaka, K.: Memory lower bounds of re-
ductions revisited. In: Nielsen, J.B., Rijmen, V. (eds.) EUROCRYPT 2018, Part I.
LNCS, vol. 10820, pp. 61–90. Springer, Heidelberg (Apr / May 2018) 19
38. Yang, Z.: Modelling simultaneous mutual authentication for authenticated key
exchange. In: Danger, J., Debbabi, M., Marion, J., Garcı́a-Alfaro, J., Zincir-Heywood,
A.N. (eds.) Foundations and Practice of Security - 6th International Symposium,
FPS 2013, La Rochelle, France, October 21-22, 2013, Revised Selected Papers.
Lecture Notes in Computer Science, vol. 8352, pp. 46–62. Springer (2013), https:
//doi.org/10.1007/978-3-319-05302-8_4 5

A Supplemental material: Proof of Theorem 3

We shall now prove Theorem 3. As noted, this proof is very similar to the proof
of Theorem 2.
The biggest difference between the two proofs is in Game 5. While we can use
the strong DH oracle in the previous game to recognize when the adversary has
computed the correct value, in this game that would not work. However, once we
use the commitment trick [16], we are able to embed rerandomised DDH tuples.
When this same embedding is done using random tuples, the adversary is unable
to query the hash function at a point connected to the session key.
The general technique we use is to have our oracles refrain from computing
the input to the key derivation hash oracle, but instead check to see if the
adversary somehow computes it. The idea is that computing the hash input is
hard to simulate in the twin Diffie-Hellman game, but checking if someone else
has computed the hash input is easy using the twin DH oracle provided in the
twin Diffie-Hellman game.
There are five types of honest oracles (oracles whose long-term key has not
been revealed): (I) initiator oracles whose response message comes from an honest
responder oracle with the same blob; (II) other initiator oracles whose intended
peer is honest; (III) responder oracles whose initial message comes from an honest
initiator with the same blob, up to the responder message; (IV) other responder
oracles whose intended peer is honest; and (V) oracles whose intended peer is
corrupted.
Note that at the time an initiator oracle starts, we cannot know if it will
be of type I or II. However, because of the commitment trick [16] we can defer
computing the group element in the initiator’s second message until we do know
what type it is.

26
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

In the following, let Xj denote the event that the adversary wins the experi-
ment in Game j.

Game 0. Our starting point Game 0 is the security experiment defining AKE
security. We have that
Pr [breakKE ] = Pr[X0 ]. (13)
We begin with an administrative step to avoid pathologies where honest
players choose the same random nonces.

Game 1. In this game, we abort if two honest initiator oracles or two honest
responder oracles ever arrive at the same blobA,B . The probability of this hap-
pening can be upperbounded by the probability of two oracles choosing the same
nonce, and we get that
ℓ2
| Pr[X1 ] − Pr[X0 ]| ≤ . (14)
p

Game 2. In this game, an initiator oracle chooses h at random. After it receives

the message v, it chooses u as usual and reprograms G such that G(u) = h. Also,
any responder oracle that receives h and then receives another message before
the initiator oracle has reprogrammed G rejects this message.
This change is observable only if G has been queried with u earlier in the
game, or a preimage of h has been found. The probability of both events for
a single initiator oracle is upper-bounded by the number of G queries made,
showing that
tℓ
| Pr[X2 ] − Pr[X1 ]| ≤ 2 . (15)
p

A.1 Preparing Oracles

Our goal in this game is to change every honest oracle so that it no longer
computes the input to the key derivation hash H, but instead checks if the
adversary computes this input and adapts accordingly. This is essential for later
games, since it allows us to replace every use of the secret key with queries to a
twin DH oracle.

Game 3. In this game, we modify how our oracles determine their session keys.
A type III, IV or V responder oracle with blob ikjkpk i kpk j kukv, secret key
(b0 , b1 ) and nonce s does the following to determine its session key k: First, it
checks to see if any oracle queries ikjkpk i kpk j kukvkz1 kz2 kz3 kz4 kz5 have been
made satisfying
z1 = xsi0 z3 = ub0 z5 = us
(16)
z2 = xsi1 z4 = ub1 .
If any such query is found (which is exceedingly unlikely), k is set to the corre-
sponding hash value. Otherwise, the session key is chosen at random. And if such
a hash query happens later, the hash value is set to the chosen session key.

27
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

A type I initiator oracle will simply use the key from the corresponding
responder oracle.
A type II or V initiator oracle with blob ikjkpk i kpk j kukv, secret key (a0 , a1 )
and nonce r does the following to determine its session key k: First, it checks
to see if any oracle queries ikjkpk i kpk j kukvkz1 kz2 kz3 kz4 kz5 have been made
satisfying
z1 = v a0 z3 = xrj0 z5 = v r
(17)
z2 = v a1 z4 = xrj1 .
If any such query is found, k is set to the corresponding hash value. Otherwise,
the session key is chosen at random. And if such a hash query happens later, the
hash value is set to the chosen session key.
The only potential change in this game is at which point in time the key
derivation hash oracle value is first defined, which is unobservable. It follows that

Pr[X3 ] = Pr[X2 ]. (18)

A.2 Type IV Responder Oracles

Game 4. In this game type IV oracles choose their session key at random, but do
not modify the hash oracle unless the intended peer is corrupted. If the adversary
corrupts the intended peer i of a type IV oracle running as user j with secret
key (b0 , b1 ), nonce s and chosen key k, then from that point in time, any query
of the form
ikjkpk i kpk j kukvkxsi0 kxsi1 kub0 kub1 kus
to the key derivation hash oracle H will result in the hash value k.
Unless one of these queries happen before user i is corrupted, the only change
is at which point in time the key derivation hash oracle value is first defined,
which is unobservable. Let F be the event that a query as above happens before
the corresponding long-term key is corrupted. Then

| Pr[X4 ] − Pr[X3 ]| ≤ Pr[F ].

Let Fi be the same event

P as F , but with the intended peer being user i. We
then have that Pr[F ] = i Pr[Fi ].
Next, consider the event Ei which is that for some type IV oracle as above,
any query of the form

ikjkpk i kpk j kukvkz1 kz2 kz3 kz4 kz5 z1 = xsi0 = v b0 z2 = xsi1 = v b1 (19)

to the key derivation hash oracle H happens before user i is corrupted. Then
Pr[Fi ] ≤ Pr[Ei ].
We shall now bound the probability of the event Ei by constructing an
adversary against twin Diffie-Hellman. This adversary will embed its twin DH
challenge in some user i’s public key and type IV oracle responses for oracles
whose intended peer is user i, and recover the solution to its twin DH challenge
from the hash query in event Ei .

28
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

Twin Diffie-Hellman adversary B1 . The algorithm B1 takes as input a twin

DH challenge (x0 , x1 , y) and outputs a pair of group elements (z0 , z1 ). It has
access to a twin DH oracle that accepts tuples of the form (g, x0 , x1 , z1 , z2 , z3 ).
(That is, queries with the generator g, x0 and x1 fixed.)
Our reduction B1 runs Game 3 with the following changes: It chooses i
uniformly at random and sets user i’s public key pk i = (x0 , x1 ). For type IV
oracles whose intended peer is user i, B1 sets v = g ρ0 y, with ρ0 random. If the
adversary corrupts user i, the reduction B1 aborts. (For other users, the reduction
simply returns the secret key, as in Game 3.)
We need to recognise hash queries of the form (16) and (17) that involve user
i, as well as queries of the form (19).
For (16), where user i is the responder, we know the oracle’s nonce s, so we
only need to recognise if (z3 , z4 ) is u raised to user i’s secret key, which can be
done by submitting (g, x0 , x1 , u, z3 , z4 ) to the DDH oracle.
For (17), where user i is the initiator, we know the oracle’s nonce r, so we
only need to recognise if (z1 , z2 ) is v raised to user i’s secret key, which can be
done by submitting (g, x0 , x1 , v, z1 , z2 ) to the DDH oracle.
Finally, for (19), we need to recognise if a group element (z1 , z2 ) is v raised
to user i’s secret key, which can be done by submitting (g, x0 , x1 , v, z1 , z2 ) to the
DDH oracle.
When we recognise a query like (19) where v = g ρ0 y, we know that z1 = v a0
and z2 = v a1 , where a0 = logg x0 and a1 = logg x1 , and we output

z0 = z1 x0−ρ0 = v a0 x0−ρ0 = g ρ0 a0 y a0 x0−ρ0 = y a0 z1 = z2 x1−ρ0 = y a1 .

In other words, our adversary B1 succeeds whenever Ei would happen in Game 3.

Furthermore, Ei in Game 3 can only happen before user i is corrupted, so
whenever Ei would happen in Game 3, B1 would not have aborted.
We get that
1X 1X 1
Succ2-CDH
G,g (B1 ) ≥ Pr[Ei ] ≥ Pr[Fi ] = Pr[F ],
µ i µ i µ

from which it follows that

| Pr[X4 ] − Pr[X3 ]| ≤ Pr[F ] ≤ µSucc2-CDH

G,g (B1 ). (20)

A.3 Type III Responder Oracles

Game 5. In this game type III responder oracles choose their session key at
random, and do not modify the key derivation hash oracle.
Consider a type III responder oracle for user j with secret key (b0 , b1 ), nonce
s and intended peer i, who has secret key (a0 , a1 ). Unless the adversary ever
makes a hash query of the form

ikjkpk i kpk j kukvkz1 kz2 kz3 kz4 kz5 z5 = u s , (21)

29
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

this change is unobservable.

Let F be the event that a hash query of this form is ever made. We shall bound
the probability of F by constructing an adversary against Decision Diffie-Hellman.
This adversary will embed its challenge in type I initiator oracles’ message, as
well as in type III responder oracles’ message. It will construct its algorithm for
detecting F such that if its input is a DDH tuple, it will detect F correctly, while
if its input is a random tuple F will never happen.
Decision Diffie-Hellman adversary B2 . The algorithm B2 takes as input a
DDH tuple (x, y, z) and outputs a bit.
Our reduction will create many rerandomised samples of (x, y, z), many of
them with the same first coordinate. We index these by the first coordinate and
the two last coordinates: (xk , yl , zl ).
Our reduction B2 runs Game 4 with the following changes:
For the first type III responder oracle that receives a hash h (sent by an
honest initiator oracle), we choose a rerandomised DDH tuple (xk , yl , zl ) and set
v = yl . For any subsequent type III responder oracle that receives the same hash
h, we choose another rerandomised DDH tuple (xk , yl′ , zl′ ) with the same xk and
set v = DDHl .
For a initiator oracle that output a hash h and receives a message v from
a responder oracle with the same blob (which means that the initiator oracle
will be a type I oracle) that used a rerandomised DDH tuple (xk , yl , zl ), we let
v = xk .
Note that in this game, the reduction knows all secret keys, so user corruption
is handled exactly as in Game 4.
Our algorithm will recognize hash queries of the form (21), by looking for
queries where u = xk , v = yl and z5 = zl , where (xk , yl , zl ) is the rerandomised
tuple used by the relevant type III oracle.
If the input (x, y, z) is a real DDH tuple (logg x = logy z), the rerandomised
tuples will also be real DDH tuples, in which case our algorithm simulates Game 4
perfectly.
If the input (x, y, z) is a random tuple, the rerandomised tuples will also be
random tuples, in which case our algorithm simulates a game that is close to
Game 5. The difference is that our algorithm simulates a game where the key
derivation hash oracle is very slightly more likely to choose the agreed session
keys than other keys. However, this is only noticable if the adversary queries the
hash oracle at one of at most ℓ group elements chosen at random. The likelyhood
of this is at most ℓ/p times the number of hash queries.
We get that
tℓ
| Pr[X5 ] − Pr[X4 ]| ≤ AdvDDH
G,g (B2 ) + . (22)
p

A.4 Type II Initiator Oracles

Game 6. In this game type II initiator oracles choose their session key at random,
but do not modify the hash oracle unless the intended peer is corrupted. If the
adversary corrupts the intended peer j of a type II oracle running as user i with

30
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

secret key (a0 , a1 ), nonce r and chosen key k, then from that point in time, any
query of the form

ikjkpk i kpk j kukvkv a0 kv a1 kxrj0 kxrj1 kv r

to the key derivation hash oracle H will result in the hash value k.
Unless one of these queries happen before the user j is corrupted, the only
change is at which point in time the key derivation hash oracle value is first
defined, which is unobservable. Let F be the event that a query as above happens
before the corresponding long-term key is corrupted. Then

| Pr[X6 ] − Pr[X5 ]| ≤ Pr[F ].

Let Fj be the same event

P as F , but with the intended peer being user j. We
then have that Pr[F ] = j Pr[Fj ].
Next, consider the event Ej which is that for some type II oracle as above,
any query of the form

ikjkpk i kpk j kukvkz1 kz2 kz3 kz4 kz5 z3 = xrj0 = ub0 z4 = xrj1 = ub1 (23)

to the key derivation hash oracle H happens before user j is corrupted. Then
Pr[Fj ] ≤ Pr[Ej ].
We shall now bound the probability of the event Ej by constructing an
adversary against twin Diffie-Hellman. This adversary will embed its DH challenge
in some user j’s public key and type II oracle messages for oracles whose intended
peer is user j, and recover the solution to its DH challenge from the hash query
in event Ej .
Twin Diffie-Hellman adversary B3 . The algorithm B3 takes as input a DH
challenge (x0 , x1 , y) and outputs a pair of group elements (z0 , z1 ). It has access
to a twin DH oracle that accepts tuples of the form (g, x0 , x1 , z1 , z2 , z3 ). (That
is, queries with the generator g, x0 and x1 fixed.)
Our reduction B3 runs Game 5 with the following changes: It chooses j
uniformly at random and sets user j’s public key pk j = (x0 , x1 ). For type II
initiator oracles whose intended peer is user j, B3 sets u = g ρ0 y, with ρ0 random.
If the adversary corrupts user j, the reduction B3 aborts. (For other users, the
reduction simply returns the secret key, as in Game 5.)
We need to recognise hash queries of the form (16) and (17) that involve user
j, as well as queries of the form (23).
For (16), where user j is the responder, we know the oracle’s nonce s, so we
only need to recognise if (z3 , z4 ) is u raised to user j’s secret key, which can be
done by submitting (g, x0 , x1 , u, z3 , z4 ) to the twin DH oracle.
For (17), where user j is the initiator, we know the oracle’s nonce r, so we
only need to recognise if (z1 , z2 ) is v raised to user j’s secret key, which can be
done by submitting (g, x0 , x1 , v, z1 , z2 ) to the twin DH oracle.
Finally, for (23), we need to recognise if a group element (z3 , z4 ) is u raised
to user j’s secret key, which can be done by submitting (g, x0 , x1 , u, z3 , z4 ) to the
DDH oracle.

31
Submission number 408 to Eurocrypt 2019: DO NOT DISTRIBUTE!

When we recognise a query like (23) where u = g ρ0 y, we know that z3 = v b0

and z4 = v b1 , where b0 = logg x0 and b1 = logg x1 , and we output

z0 = z3 x0−ρ0 = ub0 x0−ρ0 = g ρ0 b0 y b0 x−ρ

0
0
= y b0 z1 = z4 x−ρ
1
1
= y b1 .

In other words, our adversary B3 succeeds whenever Ej would happen in Game 5.

Furthermore, Ej in Game 5 can only happen before user j is corrupted, so
whenever Ej would happen in Game 5, B3 would not have aborted.
We get that
1X 1X 1
Succ2-CDH
G,g (B3 ) ≥ Pr[Ej ] ≥ Pr[Fj ] = Pr[F ],
µ j µ j µ

from which it follows that

| Pr[X6 ] − Pr[X5 ]| ≤ Pr[F ] ≤ µSucc2-CDH

G,g (B3 ). (24)

A.5 Summary
Note that in Game 6, every session key is chosen at random independent of every
key and sent message.
For type V oracles, the key derivation hash oracle is immediately programmed
so that the session key is available to the adversary. But type V oracles have no
expectation of security, hence they are never fresh and therefore never subject to
a Test query.
For type II and IV oracles, the key derivation hash oracle is programmed
to make the session key available to the adversary only after the intended peer
is corrupted. But if the intended peer is corrupted, a type II or IV oracle will
become non-fresh, which means that it should never have been subject to a Test
query.
For type I and III oracles, the key derivation hash oracle will never make the
session key available to the adversary.
This means that for any oracle subject to a Test query, the session key is and
will remain independent of every key and sent message. Which means that the
adversary cannot distinguish the session key from a random key.
It follows that
1
Pr[X6 ] = . (25)
2
It is now easy to see that Theorem 2 follows from the construction of B1 , B2
and B3 as well as equations (13), (14), (15), (18), (20), (22), (24) and (25).

32