Simple Security Definitions for and Constructions of 0-RTT Key Exchange

Abstract

Zero Round-Trip Time (0-RTT) key exchange protocols allow for the transmission of cryptographically protected payload data without requiring the prior exchange of messages of a cryptographic key exchange protocol. The 0-RTT KE concept was first realized by Google in the QUIC Crypto protocol, and a 0-RTT mode has been intensively discussed for inclusion in TLS 1.3.

In 0-RTT KE two keys are generated, typically using a Diffie-Hellman key exchange. The first key is a combination of an ephemeral client share and a long-lived server share. The second key is computed using an ephemeral server share and the same ephemeral client share.

In this paper, we propose simple security models, which catch the intuition behind known 0-RTT KE protocols; namely that the first (resp. second) key should remain indistinguishable from a random value, even if the second (resp. first) key is revealed. We call this property strong key independence. We also give the first constructions of 0-RTT KE which are provably secure in these models, based on the generic assumption that secure non-interactive key exchange (NIKE) exists (This work was partially supported by a STSM Grant from COST Action IC1306).

1 Introduction

Efficiency, in terms of messages to be exchanged before a key is established, is a growing consideration for internet protocols today. Basically, the first generation of internet key exchange protocols did not care too much about efficiency, since secure connections were considered to be the exception rather than the rule: SSL (versions 2.0 and 3.0) and TLS (versions 1.0, 1.1, and 1.2) require 2 round-trip times (RTT) for key establishment before the first cryptographically-protected payload data can be sent. With the increased use of encryption,¹ efficiency is of escalating importance for protocols like TLS. Similarly, the older IPSec IKE version v1 needs between 3 RTT (aggressive mode + quick mode) and 4.5 RTT (main mode + quick mode). This was soon realized to be problematic, and in IKEv2 the number of RTTs was reduced to 2.

The QUIC Protocol. Fundamentally, the discussion on low-latency key exchange (aka. LLKE, zero-RTT or 0-RTT key exchange) was opened when Google proposed the QUIC protocol.² QUIC (cf. Fig. 1) achieves low-latency by caching a signed server configuration file on the client side, which contains a medium-lived Diffie-Hellman (DH) share $Y_0=g^{y_0}$.³

Fig. 1.

Google’s QUIC protocol (simplified) with cached server key configuration file $(Y_0,\sigma _S)$. AE denotes a symmetric authenticated encryption algorithm (e.g., AES-GCM), $(sk^{sig}_S,pk^{sig}_S)$ denotes the server’s long-term signing keys, and $\pi _S^t$ (resp. $\pi _C^s$) denotes the oracle at server S executing the single t-th instance of the protocol (resp. for client).

When a client wishes to establish a connection with a server and possesses a valid configuration file of that server, it chooses a fresh ephemeral DH share $X=g^x$ and computes a temporal key $k_1$ from $g^{y_0x}$. Using this key $k_1$, the client can encrypt and authenticate data to be sent to the server, together with X. In response, the server sends a fresh DH share $Y=g^y$ and computes a session key $k_2$ from $g^{xy}$, which is used for all subsequent data exchanges.

TLS 1.3. Early TLS 1.3 drafts, e.g. draft-ietf-tls-tls13-08 [25], contained a 0-RTT key exchange mode where a QUIC-like ServerConfiguration message is cached by the client. The current version draft-ietf-tls-tls13-18 [26] follows a different approach, where the initial key establishment between a client and a server is never 0-RTT. Instead, it defines a method to establish a new session based on the secret key of a previous session. Even though this is also called “0-RTT” in the current TLS 1.3 specification, it is rather a “0-RTT session resumption” protocol, but does not allow for 0-RTT key establishment. Most importantly, the major difference between the approach of the current TLS 1.3 draft in comparison to a “real” 0-RTT key exchange protocol is that the former requires storing of secret key information on the client between sessions. In contrast, a 0-RTT key establishment protocol does not require secret information to be stored between sessions.

Facebook’s Zero Protocol. Very recently, the social network Facebook announced that it is currently experimenting with a 0-RTT KE protocol called Zero.⁴ Zero is very similar to QUIC, except that it uses another nonce and encryption of the ServerHello message. It is noteworthy that the main difference between Zero and QUIC was introduced in order to prevent an attack discovered by Facebook, which has been reported to Google and meanwhile been fixed in QUIC, too. We believe that this is a good example that shows the demand of simple security definitions and provably-secure constructions for such protocols.

Security Goals. 0-RTT KE protocols like QUIC have ad-hoc designs that aim at achieving three goals: (1) 0-RTT encryption, where ciphertext data can already be sent together with the first handshake message; (2) perfect forward secrecy (PFS), where all ciphertexts exchanged after the second handshake message will remain secure even after the (static or semi-static) private keys of the server have been leaked, and (3) key independence, where “knowledge” about one of the two symmetric keys generated should not endanger the security of the other key.

Strong Key Independence. Intuitively, a 0-RTT KE protocol should achieve strong key independence between $k_1$ and $k_2$; if any one of the two keys is leaked at any time, the other key should still be indistinguishable from a random value. In all known security models, this intuition would be formalized as follows: if the adversary $\mathcal {A}$ asks a $\mathsf {Reveal}$ query for $k_1$, he is still allowed to ask a $\mathsf {Test}$ query for $k_2$, and vice versa. If the two keys are computationally independent from each other (which also includes computations on the different protocol messages), then the adversary should have only a negligible advantage in answering the $\mathsf {Test}$ query correctly.

Ultimately this leads to the following research questions: Do existing examples of 0-RTT KE protocols have strong key independence? Can we describe a generic way to construct 0-RTT KE protocols that provably achieve strong key independence?

QUIC Does Not Provide Strong Key Independence. If an attacker $\mathcal {A}$ is allowed to learn $k_1$ by a $\mathsf {Reveal}$-query, then he is able to decrypt $AE(k_1;Y)$ and re-encrypt its own value $Y^*:=g^{y^*}$ as $AE(k_1;Y^*)$. Furthermore, he can then compute the same $k_2=X^{y^*}$ as the client oracle, and can thus distinguish between the “real” key and a “random” key chosen by the $\mathsf {Test}$ query. See [11] for more details on key dependency in QUIC.

Note that this theoretical attack does not imply that QUIC is insecure. It only shows that the authenticity of the server’s Diffie-Hellman share, which is sent in QUIC to establish $k_2$, depends strongly on the security of key $k_1$. Therefore QUIC does not provide strong key independence in the sense sketched above.

Previous Work on 0-RTT Key Exchange. The concept of 0-RTT key exchange was not developed in academia, but in industry – motivated by concrete practical demands of distributed applications. All previous works on 0-RTT KE [11, 23] conducted a-posteriori security analyses of the QUIC protocol, with tailored models. There are no foundational constructions as yet, and the relation to other cryptographic protocols and primitives is not yet well-understood.

At ACM CCS 2014, Fischlin and Günther [11] provided a formal definition of multi-stage key exchange protocols and used it to analyze the security of QUIC. Lychev et al.  [23] gave an alternate analysis of QUIC, which considers both efficiency and security. They describe a security model which is bespoke to QUIC, adopting the complex, monolithic security model of [17] to the protocol’s requirements. Zhao [31] considers identity-concealed 0-RTT protocols, where user privacy is protected by hiding identities of users in a setting with mutual cryptographic authentication of both communicating parties. Günther et al.  [14] extended the “puncturable encryption”-approach of Green and Miers [13] to show that even 0-RTT KE with full forward secrecy is possible, by evolving the secret key after each decryption. However, their construction is currently mainly of conceptual interest, as it is not yet efficient enough to be deployed at large scale in practice.

Security Model. In this paper, we use a variant of the Canetti-Krawczyk [7] security model. This family of security models is especially suited to protocols with only two message exchanges, with one-round key exchange protocols constituting the most important subclass. Popular examples of such protocols are MQV [22], HMQV [18], SMQV [27], KEA [21, 24], and NAXOS [20]. A comparison of different variants of the Canetti-Krawczyk model can be found in [9, 29].

The Importance of Simplicity of Security Models. Security models for key exchange protocols have to consider active adversaries that may modify, replay, inject, drop, etc., any message transmitted between communicating parties. They also need to capture parallel executions of multiple protocol sessions, potential reveals of earlier session keys, and adaptive corruptions of long-term secrets of parties. This makes even standard security models for key exchange extremely complex (in comparison to most other standard cryptographic primitives, like digital signatures or public-key encryption, for example).

Naturally, the novel primitive of 0-RTT KE requires formal security definitions. There are different ways to create such a model. One approach is to focus on generality of the model. Fischlin and Günther [11] followed this path, by defining multi-stage key exchange protocols, a generalization of 0-RTT KE. This approach has the advantage that it lays the foundation for the study of a very general class of interesting and novel primitives. However, its drawback is that this generality inherently also brings a huge complexity to the model. Clearly, the more complex the security model, the more difficult it becomes to devise new, simple, efficient, and provably-secure constructions. Moreover, proofs in complex models tend to be error-prone and less intuitive, because central technical ideas may be concealed in formal details that are required to handle the generality of the model.

Another approach is to devise a model which is tailored to the analysis of one specific protocol. For example, the complex, monolithic ACCE security model was developed in [17] to provide an a posteriori security analysis of TLS.⁵ A similar approach was followed by Lychev et al.  [23], who adopted this model for an a posteriori analysis of QUIC, by defining the so-called Q-ACCE model. The notable drawback of this approach is that such tailor-made models tend to capture only the properties achieved by existing protocols, but not necessarily all properties that we would expect from a “good” 0-RTT KE protocol. In general, such tailor-made models do not, therefore, form a useful foundation for the creation of new protocols.

In this paper, we follow a different approach. We propose novel “bare-bone” security models for 0-RTT KE, which aim at capturing all (strong key independence and forward secrecy), but also only the properties intuitively expected from “good” 0-RTT KE protocols. We propose two different models. One considers the practically-relevant case of server-only authentication (where the client may or may not authenticate later over the established communication channel, similar in spirit to the server-only-authenticated ACCE model of [19]). The other considers traditional mutual cryptographic authentication of a client and server.

The reduced generality of our definitions – in comparison to the very general multi-stage security model of [11] – is intended. A model which captures only, but also all the properties expected from a “good” 0-RTT KE protocol allows us to devise relatively simple, foundational, and generic constructions of 0-RTT KE protocols with as-clean-as-possible security analyses.

Importance of Foundational Generic Constructions. Following [3], we use non-interactive key exchange (NIKE) [8, 12] in combination with digital signatures as a main building block.⁶ This yields the first examples of 0-RTT KE protocols with strong key independence, as well as the first constructions of 0-RTT KE from generic complexity assumptions. There are many advantages of such generic constructions:

• 1. Generic constructions provide a better understanding of the structure of protocols. Since the primitives we use have abstract security properties, we can see precisely which abstract security requirements are needed to implement 0-RTT KE protocols.

• 2. They clarify the relations and implications between different types of cryptographic primitives.

• 3. They can be generically instantiated with building blocks based on different complexity assumptions. For example, if “post-quantum” security is needed, one can directly obtain a concrete protocol by using only post-quantum secure building blocks in the generic construction.

Usually generic constructions tend to involve more computational overhead than ad-hoc constructions. However, we note that our 0-RTT KE protocols can be instantiated relatively efficiently, given the efficient NIKE schemes of [12], for example.

Contributions. Contributions in this paper can be summarized as follows:

• Simple security models. We provide simple security models, which capture all properties that we expect from a “good” 0-RTT KE protocol, but only these properties. We consider both the “practical” setting with server-only authentication and the classical setting with mutual authentication.

• First generic constructions. We give intuitive, relatively simple, and efficient constructions of 0-RTT KE protocols in both settings.

• First Non-DH instantiation. Both QUIC and TLS 1.3 are based on DH key exchange. Our generic construction yields the first 0-RTT KE protocol which is not based on Diffie-Hellman (e.g., by instantiating the generic construction with the factoring-based NIKE scheme of Freire et al. [12]).

• First 0-RTT KE with strong key independence. Our 0-RTT KE protocols are the first to achieve strong key independence in the sense described above.

• Well-established, general assumptions. The construction is based on general assumptions, namely the existence of secure NIKE and digital signature schemes. For all building blocks we require only standard security properties.

• Security in the Standard Model. The security analysis is completely in the standard model, i.e. it is performed without resorting to the Random Oracle heuristic [1] and without relying on non-standard complexity assumptions.

• Efficient instantiability. Despite the fact that our constructions are generic, the resulting protocols can be instantiated relatively efficiently.

Full Version of this Paper. Due to space limitations, we have to defer several results to the full version of this paper [15]. This includes the full proof of Theorem 1, the Definition and Security Model for a 0-RTT protocol under mutual authentication ($\mathsf {0\text {-}RTT\text {-}M}$), a construction of a $\mathsf {0\text {-}RTT\text {-}M}$ protocol along with its security model and its security proof.

2 Preliminaries

For our construction in Sect. 4, we need signature schemes and non-interactive key exchange (NIKE) protocols. Here we summarize the definitions of these two primitives and their security from the literature.

2.1 Digital Signatures

A digital signature scheme consists of three polynomial-time algorithm $\mathsf {SIG}= (\mathsf {SIG.Gen},\mathsf {SIG.Sign},\mathsf {SIG.Vfy})$. The key generation algorithm $(sk,pk) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {SIG.Gen}(1^\lambda )$ generates a public verification key pk and a secret signing key sk on input of security parameter $\lambda$. Signing algorithm $\sigma \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {SIG.Sign}(sk,m)$ generates a signature for message m. Verification algorithm $\mathsf {SIG.Vfy}(pk,\sigma , m)$ returns 1 if $\sigma$ is a valid signature for m under key pk, and 0 otherwise.

Consider the following security experiment played between a challenger $\mathcal {C}$ and an adversary $\mathcal {A}$.

• 1. The challenger generates a public/secret key pair $(sk,pk) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {SIG.Gen}(1^\lambda )$, the adversary receives pk as input.

• 2. The adversary may query arbitrary messages $m_i$ to the challenger. The challenger replies to each query with a signature $\sigma _i = \mathsf {SIG.Sign}(sk,m_i)$. Here i is an index, ranging between $1 \le i \le q$ for some $q \in \mathbb {N}$. Queries can be made adaptively.

• 3. Eventually, the adversary outputs a message/signature pair $(m,\sigma )$.

Definition 1

We define the advantage on an adversary $\mathcal {A}$ in this game as

$$\begin{aligned} \mathtt {Adv} _{\mathsf {SIG},\mathcal {A}}^{ sEUF \text {-} CMA }(\lambda ) := \Pr \left[ (m,\sigma ) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathcal {A} ^{\mathcal {C}(\lambda )}(pk) : \begin{array}{l} \mathsf {SIG.Vfy}(pk,\sigma ,m) = 1,\\ (m,\sigma ) \ne (m_i,\sigma _i) \ \forall i \end{array} \right] \ . \end{aligned}$$

$\mathsf {SIG}$ is strongly secure against existential forgeries under adaptive chosen-message attacks (sEUF-CMA), if $\mathtt {Adv} _{\mathsf {SIG},\mathcal {A}}^{ sEUF \text {-} CMA }(\lambda )$ is a negligible function in $\lambda$ for all probabilistic polynomial-time adversaries $\mathcal {A}$.

Remark 1

Signatures with sEUF-CMA security can be constructed generically from any EUF-CMA-secure signature scheme and chameleon hash functions [6, 28].

2.2 Secure Non-interactive Key Exchange

Definition 2

A non-interactive key exchange (NIKE) scheme consists of two deterministic algorithms $(\mathsf {NIKE.Gen},\mathsf {NIKE.Key})$.  

$\mathsf {NIKE.Gen} (1^\lambda ,r)$ :

takes a security parameter $\lambda$ and randomness $r \in \{0,1\}^\lambda$. It outputs a key pair $( pk , sk )$. We write $( pk , sk ) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {NIKE.Gen} (1^\lambda )$ to denote that $\mathsf {NIKE.Gen} (1^\lambda ,r)$ is executed with uniformly random $r \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\{0,1\}^\lambda$.

$\mathsf {NIKE.Key} ( sk _i, pk _j)$ :

is a deterministic algorithm which takes as input a secret key $sk _i$ and a public key $pk _j$, and outputs a key $k_{i,j}$.

  We say that a NIKE scheme is correct, if for all $( pk _i, sk _i) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {NIKE.Gen} (1^\lambda )$ and $( pk _j, sk _j) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {NIKE.Gen} (1^\lambda )$ holds that $\mathsf {NIKE.Key} ( sk _i, pk _j) = \mathsf {NIKE.Key} ( sk _j, pk _i)$.

A NIKE scheme is used by d parties $P_1,\ldots ,P_d$ as follows. Each party $P_i$ generates a key pair $( pk _i, sk _i) \leftarrow \mathsf {NIKE.Gen} (1^\lambda )$ and publishes $pk _i$. In order to compute the key shared by $P_i$ and $P_j$, party $P_i$ computes $k_{i,j} = \mathsf {NIKE.Key} ( sk _i, pk _j)$. Similarly, party $P_j$ computes $k_{j,i} = \mathsf {NIKE.Key} ( sk _j, pk _i)$. Correctness of the NIKE scheme guarantees that $k_{i,j} = k_{j,i}$.

CKS-Light Security. The $\textit{CKS}\text {-}{} \textit{light}$ security model for NIKE protocols is relatively simplistic and compact. We choose this model because other (more complex) NIKE security models like $CKS$, $\textit{CKS}\text {-}{} \textit{heavy}$, and $\textit{m}\text {-}{} \textit{CKS}\text {-}{} \textit{heavy}$ are polynomial-time equivalent to $\textit{CKS}\text {-}{} \textit{light}$. See [12] for more details.

Security of a NIKE protocol $\mathsf {NIKE}$ is defined by a game $\mathbf {NIKE}$ played between an adversary $\mathcal {A}$ and a challenger. The challenger takes a security parameter $\lambda$ and a random bit b as input and answers all queries of $\mathcal {A}$ until she outputs a bit $b'$. The challenger answers the following queries for $\mathcal {A}$:

• $\mathsf {RegisterHonest}(i)$. $\mathcal {A}$ supplies an index i. The challenger runs $\mathsf {NIKE.Gen} (1^\lambda )$ to generate a key pair $(pk_i,sk_i)$ and records the tuple $(\mathtt {honest},pk_i,sk_i)$ for later and returns $pk_i$ to $\mathcal {A}$. This query may be asked at most twice by $\mathcal {A}$.

• $\mathsf {RegisterCorrupt}(pk_i)$. With this query $\mathcal {A}$ supplies a public key $pk_i$. The challenger records the tuple $(\mathtt {Corrupt},pk_i)$ for later.

• $\mathsf {GetCorruptKey}(i,j)$. $\mathcal {A}$ supplies two indices i and j where $pk_i$ was registered as corrupt and $pk_j$ as honest. The challenger runs $k \leftarrow \mathsf {NIKE.Key} (sk_j,pk_i)$ and returns k to $\mathcal {A}$.

• $\mathsf {Test}(i,j)$. The adversary supplies two indices i and j that were registered honestly. Now the challenger uses bit b: if $b=0$, then the challenger runs $k_{i,j} \leftarrow \mathsf {NIKE.Key} (pk_i,sk_j)$ and returns the key $k_{i,j}$. If $b=1$, then the challenger samples a random element from the key space, records it for later, and returns the key to $\mathcal {A}$.

The game $\mathbf {NIKE}$ outputs 1, denoted by $\mathbf {NIKE} _{\mathsf {NIKE}}^{\mathcal {A}}(\lambda )=1$, if $b = b'$ and 0 otherwise. We say $\mathcal {A}$ wins the game if $\mathbf {NIKE} _{\mathsf {NIKE}}^{\mathcal {A}}(\lambda )=1$.

Definition 3

For any adversary $\mathcal {A}$ playing the above $\mathbf {NIKE}$ game against a NIKE scheme $\mathsf {NIKE}$, we define the advantage of winning the game $\mathbf {NIKE}$ as

Let $\lambda$ be a security parameter, $\mathsf {NIKE}$ be a NIKE protocol and $\mathcal {A}$ an adversary. We say $\mathsf {NIKE}$ is a CKS-light-secure NIKE protocol, if for all probabilistic polynomial-time adversaries $\mathcal {A}$, the function $\mathtt {Adv} _{\mathsf {NIKE},\mathcal {A}}^{\textit{CKS}\text {-}{} \textit{light}}(\lambda )$ is a negligible function in $\lambda$.

3 0-RTT Key Exchange Protocols: Syntax and Security with Server-Only Authentication

In the model presented in this section, we give formal definitions for 0-RTT KE with strong key independence and main-key forward secrecy. We start with the case of server-only authentication, as it is the more important case in practice (in particular, server-only authentication will be the main operating mode of both QUIC and TLS 1.3).

3.1 Syntax and Correctness

Definition 4

A 0-RTT key exchange scheme with server-only authentication consists of deterministic algorithms $(\mathsf {Gen^{server}}, \mathsf {KE^{client}_{init}}, \mathsf {KE^{client}_{refresh}}, \mathsf {KE^{server}_{refresh}})$.

• $\mathsf {Gen^{server}} (1^\lambda , r) \rightarrow ( pk , sk )$: A key generation algorithm that takes as input a security parameter $\lambda$ and randomness $r \in \{0,1\}^\lambda$ and outputs a key pair $( pk , sk )$. We write $( pk , sk ) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {Gen^{server}} (1^\lambda )$ to denote that a pair $( pk , sk )$ is the output of $\mathsf {Gen^{server}}$ when executed with uniformly random $r \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\{0,1\}^\lambda$.

• $\mathsf {KE^{client}_{init}} ( pk _j, r_i) \rightarrow (k_{\mathtt {tmp}}^{{i},{j}}, m_i)$: An algorithm that takes as input a public key $pk _j$ and randomness $r_i \in \{0,1\}^\lambda$, and outputs a temporary key $k_{\mathtt {tmp}}^{{i},{j}}$ and a message $m_i$.

• $\mathsf {KE^{server}_{refresh}} ( sk _j, r_j, m_i) \rightarrow (k_{\mathtt {main}}^{{j},{i}}, k_{\mathtt {tmp}}^{{j},{i}}, m_j)$: An algorithm that takes as input a secret key $sk _j$, randomness $r_j$ and a message $m_i$, and outputs a key $k_{\mathtt {main}}^{{j},{i}}$, a temporary key $k_{\mathtt {tmp}}^{{j},{i}}$ and a message $m_j$.

• $\mathsf {KE^{client}_{refresh}} ( pk _j, r_i, m_j) \rightarrow k_{\mathtt {main}}^{{i},{j}}$: An algorithm that takes as input a public key $pk _j$, randomness $r_i$, and message $m_j$, and outputs a key $k_{\mathtt {main}}^{{i},{j}}$.

We say that a 0-RTT key exchange scheme is correct, if for all $( pk _j, sk _j), \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {Gen^{server}} (1^\lambda )$ and for all $r_i, r_j \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\{0,1\}^\lambda$ holds that

$$\begin{aligned} \Pr [k_{\mathtt {tmp}}^{{i},{j}}\ne k_{\mathtt {tmp}}^{{j},{i}} \text { or } k_{\mathtt {main}}^{{i},{j}}\ne k_{\mathtt {main}}^{{j},{i}}]\le \mathsf {negl} (\lambda ) \ , \end{aligned}$$

where $(k_{\mathtt {tmp}}^{{j},{i}}, m_i )\leftarrow \mathsf {KE^{client}_{init}} ( pk _j, r_i)$, $(k_{\mathtt {main}}^{{i},{j}},k_{\mathtt {tmp}}^{{i},{j}},m_j)\leftarrow \mathsf {KE^{server}_{refresh}} ( sk _j, r_j, m_i)$, and $k_{\mathtt {main}}^{{j},{i}} \leftarrow \mathsf {KE^{client}_{refresh}} ( pk _j, r_i, m_j)$.

A 0-RTT KE scheme is used by a set parties which are either clients C or servers S (cf. Fig. 2). Each server $\mathsf {S}_p$ has a generated key pair $( sk _p, pk _p) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {Gen^{server}} (1^\lambda ,j)$ with published $pk _p$. The protocol is executed as follows:

• 1. The client oracle $\mathsf {C}_{i}$ chooses $r_i \in \{0,1\}^\lambda$ and selects the public key of the intended partner $S_j$ (which must be a server, otherwise this value is undefined). Then it computes $(k_{\mathtt {tmp}}^{{i},{j}},m_i)\leftarrow \mathsf {KE^{client}_{init}} ( pk _j, r_i)$, and sends $m_i$ to $S_j$. Additionally, $\mathsf {C}_{i}$ can use $k_{\mathtt {tmp}}^{{i},{j}}$ to encrypt some data $M_i$.

• 2. Upon reception of message $m_i$, $S_j$ initializes a new oracle $\mathsf {S}_{{j},{t}}$. This oracle chooses $r_j \in \{0,1\}^\lambda$ and computes $(k_{\mathtt {main}}^{{j},{i}}, k_{\mathtt {tmp}}^{{j},{i}}, m_j) \leftarrow \mathsf {KE^{server}_{refresh}} ( sk _j, r_j, m_i)$. The server may use the ephemeral key $k_{\mathtt {tmp}}^{{j},{i}}$ to decrypt $D_i$. Then, the server sends $m_j$ and optionally some data $M_j$ encrypted with the key $k_{\mathtt {main}}^{{j},{i}}$ to the client.

• 3. $\mathsf {C}_{i}$ computes $k_{\mathtt {main}}^{{i},{j}}\leftarrow \mathsf {KE^{client}_{refresh}} ( pk _j, r_i, m_j)$ and can optionally decrypt $D_j$. Correctness of the 0-RTT KE scheme guarantees that $k_{\mathtt {main}}^{{i},{j}}=k_{\mathtt {main}}^{{j},{i}}$.

Fig. 2.

Execution of a 0-RTT KE Protocol with Server-Only Authentication in Parallel to . Note that the messages and correspond to the symmetric encryption protocol used to encrypt payload data, and are therefore not part of the 0-RTT KE protocol, but a separate protocol. These messages are only displayed here only to illustrate the basic, parallel application message flow to that of a 0-RTT KE protocol. While it would in principle be possible to define the symmetric encryption directly as part of the protocol, this would require a significantly more complex “ACCE-style” [17] security model, which we avoid for sake of simplicity.

3.2 Execution Environment

We provide an adversary $\mathcal {A}$ against a 0-RTT KE protocol with the following execution environment. Clients, which are not in possession of a long-term secret are represented by oracles $\mathsf {C}_{1},\ldots ,\mathsf {C}_{d}$ (without any particular “identity”). We consider $\ell$ servers, each server has a long-term key pair $( sk _j, pk _j)$ ⁷, $j \in \{1,\ldots ,\ell \}$, and each client has access to all public keys $pk _1,\ldots , pk _\ell$. Each server is represented by a collection of k oracles $\mathsf {S}_{{j},{1}},\ldots ,\mathsf {S}_{{j},{k}}$, where each oracle represents a process that executes one single instance of the protocol.

We use the following variables to maintain the internal state of oracles.

• Clients. Each client oracle $\mathsf {C}_{i}$, $i \in [d]$, maintains

  • – two variables $\mathsf {k}_{i}^\mathsf {tmp}$ and $\mathsf {k}_{i}^\mathsf {main}$ to store the temporal and main keys of a session,

  • – a variable $\mathsf {Partner}_{i}^{}$, which contains the identity of the intended communication partner, and

  • – variables $\mathcal {M}_{i}^\mathbf{in }$ and $\mathcal {M}_{i}^\mathbf{out }$ containing messages sent and received by the oracle.

  The internal state of a client oracle is initialized to $(\mathsf {k}_{i}^\mathsf {tmp},\mathsf {k}_{i}^\mathsf {main}, \mathsf {Partner}_{i}^{}, \mathcal {M}_{i}^\mathbf{in }, \mathcal {M}_{i}^\mathbf{out }):=(\emptyset , \emptyset ,\emptyset ,\emptyset ,\emptyset )$.

• Servers. Each server oracle $\mathsf {S}_{{j},{t}}$, $(j,t) \in [\ell ] \times [k]$, maintains:

  • – two variables $\mathsf {k}_{i}^\mathsf {tmp}$ and $\mathsf {k}_{i}^\mathsf {main}$ to store the temporal and main keys of a session, and

  • – variables $\mathcal {M}_{j,t}^\mathbf{in }$ and $\mathcal {M}_{j,t}^\mathbf{out }$ containing messages sent and received by the server.

  The internal state of a server oracle is initialized to $(\mathsf {k}_{j,t}^\mathsf {tmp},\mathsf {k}_{j,t}^\mathsf {main}, \mathcal {M}_{j,t}^\mathbf{in }, \mathcal {M}_{j,t}^\mathbf{out }):=(\emptyset ,\emptyset ,\emptyset ,\emptyset )$.

We say that an oracle has accepted the temporal key if $\mathsf {k}_{}^\mathsf {tmp}\ne \emptyset$, and accepted the main key if $\mathsf {k}_{}^\mathsf {main}\ne \emptyset$.

In the security experiment, the adversary is able to interact with the oracles by issuing the following queries.

• $\mathtt {Send}$($\mathsf {C}_{i}/\mathsf {S}_{{j},{t}},m$). The adversary sends a message m to the requested oracle. The oracle processes m according to the protocol specification. Any response generated by the oracle according to the protocol specification is returned to the adversary.

  If a client oracle $\mathsf {C}_{i}$ receives m as the first message, then the oracle checks if m consists of a special initialization message ($m=(\mathtt {init}, j)$). If true, then the oracle responds with the first protocol message generated for intended partner $\mathsf {S}_{{j},{}}$, else it outputs $\bot$.

• $\mathtt {Reveal}$($\mathsf {C}_{i}/\mathsf {S}_{{j},{t}}, \mathtt {tmp}/\mathtt {main}$). This query returns the key of the given stage if it already has been computed, or $\bot$ otherwise.

• $\mathtt {Corrupt}$(j). On input of a server identity j, this query returns the long-term private key of the server. If $\mathtt {Corrupt}(j)$ is the $\tau$-th query issued by $\mathcal {A}$, we say a party is $\tau$ -corrupted. For parties that are not corrupted we define $\tau :=\infty$.

• $\mathtt {Test}$($\mathsf {C}_{i}/\mathsf {S}_{{j},{t}}, \mathtt {tmp}/\mathtt {main}$). This query is used to test a key and is only asked once. It is answered as follows: If the variable of the requested key is not empty, a random $b\mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\{0,1\}$ is selected, and

  • – if $b=0$ then the requested key is returned, else

  • – if $b=1$ then a random key, according to the probability distribution of keys generated by the protocol, is returned.

  Otherwise $\bot$ is returned.

Security Model Security Game $\mathcal {G}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}$ . After receiving a security parameter $\lambda$ the challenger $\mathcal {C}$ simulates the protocol and keeps track of all variables of the execution environment: he generates the long-lived key pairs of all server parties and answers faithfully to all queries by the adversary.

The adversary receives all public keys $pk _1,\ldots , pk _\ell$ and can interact with the challenger by issuing any combination of the queries $\mathtt {Send}$(), $\mathtt {Corrupt}$(), and $\mathtt {Reveal}$(). At some point the adversary queries $\mathtt {Test}$() to an oracle and receives a key, which is either the requested key or a random value. The adversary may continue asking $\mathtt {Send}$(), $\mathtt {Corrupt}$(), and $\mathtt {Reveal}$()-queries after receiving the key and finally outputs some bit $b'$.

Definition 5

(0-RTT KE-Security with Server-Only Authentication). Let an adversary $\mathcal {A}$ interact with the challenger in game $\mathcal {G}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}$ as it is described above. We say the challenger outputs 1, denoted by $\mathcal {G}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}(\lambda )=1$, if $b=b'$ and the following conditions hold:

• if $\mathcal {A}$ issues $\mathtt {Test}$ $(\mathsf {C}_{i}, \mathtt {tmp})$ all of the following hold:

  • $\mathtt {Reveal}$ $(\mathsf {C}_{i}, \mathtt {tmp})$ was never queried by $\mathcal {A}$

  • $\mathtt {Reveal}$ $(\mathsf {S}_{{j},{t}}, \mathtt {tmp})$ was never queried by $\mathcal {A}$ for any oracle $\mathsf {S}_{{j},{t}}$ such that $\mathsf {Partner}_{i}^{}=j$ and $\mathcal {M}_{j,t}^\mathbf{in }=\mathcal {M}_{i}^\mathbf{out }$

  • the communication partner $\mathsf {Partner}_{i}^{}=j$, if it exists, is not $\tau$ -corrupted with $\tau <\infty$

• if $\mathcal {A}$ issues $\mathtt {Test}$ $(\mathsf {C}_{i}, \mathtt {main})$ all of the following hold:

  • $\mathtt {Reveal}$ $(\mathsf {C}_{i}, \mathtt {main})$ was never queried by $\mathcal {A}$

  • $\mathtt {Reveal}$ $(\mathsf {S}_{{j},{t}}, \mathtt {main})$ was never queried by $\mathcal {A}$, where $\mathsf {Partner}_{i}^{}=j$, $\mathcal {M}_{j,t}^\mathbf{in }=\mathcal {M}_{i}^\mathbf{out }$, and $\mathcal {M}_{i}^\mathbf{in }=\mathcal {M}_{j,t}^\mathbf{out }$

  • the communication $\mathsf {Partner}_{i}^{}=j$ is not $\tau$ -corrupted with $\tau < \tau _0$, where $\mathtt {Test}$ $(\mathsf {C}_{i}, \mathtt {main})$ is the $\tau _0$-th query issued by $\mathcal {A}$

• if $\mathcal {A}$ issues $\mathtt {Test}$ $(\mathsf {S}_{{j},{t}}, \mathtt {tmp})$ all of the following hold:

  • $\mathtt {Reveal}$ $(\mathsf {S}_{{j},{t}}, \mathtt {tmp})$ was never queried by $\mathcal {A}$

  • there exists an oracle $\mathsf {C}_{i}$ with $\mathcal {M}_{i}^\mathbf{out }=\mathcal {M}_{j,t}^\mathbf{in }$

  • $\mathtt {Reveal}$ $(\mathsf {C}_{i}, \mathtt {tmp})$ was never queried by $\mathcal {A}$ to any oracle $\mathsf {C}_{i}$ with $\mathcal {M}_{i}^\mathbf{out }=\mathcal {M}_{j,t}^\mathbf{in }$

  • $\mathtt {Reveal}$ $(\mathsf {S}_{{j},{t'}}, \mathtt {tmp})$ was never queried by $\mathcal {A}$ for any oracle $\mathsf {S}_{{j},{t'}}$ with $\mathcal {M}_{j,t}^\mathbf{in }=\mathcal {M}_{j,t'}^\mathbf{in }$

  • j is not $\tau$ -corrupted with $\tau <\infty$

• if $\mathcal {A}$ issues $\mathtt {Test}$ $(\mathsf {S}_{{j},{t}}, \mathtt {main})$ all of the following hold:

  • $\mathtt {Reveal}$ $(\mathsf {S}_{{j},{t}}, \mathtt {main})$ was never queried by $\mathcal {A}$

  • there exists an oracle $\mathsf {C}_{i}$ with $\mathcal {M}_{i}^\mathbf{out }=\mathcal {M}_{j,t}^\mathbf{in }$

  • $\mathtt {Reveal}$ $(\mathsf {C}_{i}, \mathtt {main})$ was never queried by $\mathcal {A}$, if $\mathcal {M}_{i}^\mathbf{in }=\mathcal {M}_{j,t}^\mathbf{out }$

else the game outputs a random bit. We define the advantage of $\mathcal {A}$ in the game $\mathcal {G}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}(\lambda )$ by

$$\begin{aligned} \mathtt {Adv}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}(\lambda ):=\left| 2\cdot \Pr [\mathcal {G}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}(\lambda )=1]-1 \right| . \end{aligned}$$

Definition 6

We say that a 0-RTT key exchange protocol is $\mathtt {test}$-secure, if there exists a negligible function $\mathsf {negl} (\lambda )$ such that for all PPT adversaries $\mathcal {A}$ interacting according to the security game $\mathcal {G}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}(\lambda )$ it holds that

$$\begin{aligned} \mathtt {Adv}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}(\lambda )\le \mathsf {negl} (\lambda ). \end{aligned}$$

Remark 2

Our security model captures forward secrecy for the $\mathtt {main}$-key, because key indistinguishability is required to hold even if the adversary is able to corrupt the communication partner of the $\mathtt {test}$-oracle (but only after the $\mathtt {test}$-oracle has accepted, of course, in order to avoid trivial attacks).

Moreover, strong key independence is modeled by the fact that an adversary which attempts to distinguish a $\mathtt {tmp}$-key from random (i.e., an adversary which asks $\mathsf {Test}(X,\mathtt {tmp})$ for $X \in \{\mathsf {C}_{i}, \mathsf {S}_{{j},{t}}$ for some $i,j,t\}$) is allowed to learn the $\mathtt {main}$-key of X. Similarly, an adversary which tries to distinguish a $\mathtt {main}$-key from random by asking $\mathsf {Test}(X,\mathtt {main})$ is allowed to learn the $\mathtt {tmp}$-key of X as well. Security in this sense guarantees that the $\mathtt {tmp}$-key and the $\mathtt {main}$-key look independent to a computationally-bounded adversary.

Remark 3

Note that the requirements of $\mathcal {M}_{i}^\mathbf{out }=\mathcal {M}_{j,t}^\mathbf{in }$ etc. in the above security model essentially adopt the notion of matching conversations, defined by Bellare and Rogaway [2] for general, multi-message key exchange protocols, to the special case of 0-RTT KE.

3.3 Composing a 0-RTT KE Protocol with Symmetric Encryption

The security model described above considers only the 0-RTT KE protocol, without symmetric encryption of payload data (that is, without the messages $D_i$ and $D_j$ displayed in Fig. 2). A protocol secure in this sense guarantees the indistinguishability of keys in a hypothetical setting, where the key is not used for symmetric encryption of payload messages potentially known to the adversary. One may think that this is not sufficient for 0-RTT KE, because the key will be used to encrypt payload data, and this will enable an adversary to trivially distinguish a “real” key from a “random” key (this holds for both the “temporal” key $k_{\mathtt {tmp}}^{{i},{j}}$ and the actual “main” session key $k_{\mathtt {main}}^{{i},{j}}$). Note that this argument applies not only to the above 0-RTT KE security model, but actually to any security model for (authenticated) key exchange which is based on the indistinguishability of keys, such as the classical model of Bellare and Rogaway and many similar models [2, 5, 7, 10, 20, 27]. In practice, this key will usually be used in a cryptographic protocol, e.g. to encrypt messages, and therefore trivially allow for distinguishing “real” from “random” keys. The security of the composition of a protocol secure in the sense of [2, 5, 7, 10, 20, 27] with a symmetric encryption protocol follows from a standard two-step hybrid argument, which essentially proceeds as follows:

• 1. In the original security experiment, the adversary interacts with a composed protocol, where the KE protocol is first used to derive a key k, which is then used to encrypt payload data with the symmetric encryption protocol.

• 2. In the next hybrid experiment, the adversary interacts with a composed protocol, where the symmetric encryption does not use the key k computed by the KE protocol, but an independent random key. Note that an adversary that distinguishes this hybrid from the original game can be used to distinguish a “real” key of the KE protocol from a “random” one.

  Now the adversary interacts with an encryption protocol that uses a key which is independent of the KE protocol. This allows for a reduction of the security of the composed protocol to the security of the symmetric protocol.

A similarly straightforward hybrid argument applies to the composition of 0-RTT KE with symmetric encryption, which works as follows:

• 1. In the original security experiment, the adversary interacts with a composed protocol, where the 0-RTT KE protocol is first used to derive a key $k_{\mathtt {tmp}}^{{i},{j}}$, which is then used to encrypt the payload data sent along with the first protocol message. Then the 0-RTT KE protocol is used to derive the main key $k_{\mathtt {main}}^{{i},{j}}$, which in turn is used to encrypt all further payload data.

• 2. In the first hybrid experiment, the adversary interacts with a composed protocol, where only $k_{\mathtt {tmp}}^{{i},{j}}$ is replaced with an independent random value. An adversary that distinguishes this hybrid from the original game can be used to distinguish a “real” $k_{\mathtt {tmp}}^{{i},{j}}$ from a “random” one.

  Now the adversary interacts with an encryption protocol that encrypts the first payload message with a key which is independent of the 0-RTT KE protocol. This allows for a reduction of the security of the first payload message to the security of the symmetric protocol.

• 3. In the second hybrid experiment, the adversary interacts with a composed protocol, where $k_{\mathtt {main}}^{{i},{j}}$ is now also replaced with an independent random value. An adversary that distinguishes this hybrid from the previous one can be used to distinguish a “real” $k_{\mathtt {main}}^{{i},{j}}$ from a “random” one. This allows for a reduction of the security of all further payload messages to the security of the symmetric protocol.

Following the long tradition of previous works on indistinguishability-based key exchange security models [2, 5, 7, 10, 20, 27], we can thus consider an indistinguishability-based security model for 0-RTT KE even though in practice key exchange messages will be interleaved with messages of the symmetric encryption protocol. This allows for simple security models, and enables a modular analysis of the building blocks of a composed protocol.

4 Generic Construction of 0-RTT KE from NIKE

Now we are ready to describe our generic NIKE-based 0-RTT KE protocol and its security analysis.

4.1 Generic Construction

Let $\mathsf {NIKE} =(\mathsf {NIKE.Gen}, \mathsf {NIKE.Key})$ be a NIKE scheme according to Definition 2 and let $\mathsf {SIG} = (\mathsf {SIG.Gen}, \mathsf {SIG.Sign}, \mathsf {SIG.Vfy})$ be a signature scheme. Then we construct a 0-RTT KE scheme $\mathsf {0\text {-}RTT} =(\mathsf {Gen^{server}}, \mathsf {KE^{client}_{init}}, \mathsf {KE^{client}_{refresh}}, \mathsf {KE^{server}_{refresh}})$, per Definition 4, in the following way (cf. Fig. 3).

Fig. 3.

0-RTT KE from NIKE. Again, it is possible to include the parallel execution of a symmetric encryption protocol which would behave as in Fig. 2 for encrypted application data. As such a protocol is not part of the 0-RTT KE protocol, we omit it here for simplicity.

• $\mathsf {Gen^{server}} (1^\lambda ,r)$ computes key pairs using the $\mathsf {NIKE}$ key generation algorithm $( pk ^\mathsf {nike-static}, sk ^\mathsf {nike-static}) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {NIKE.Gen} (1^\lambda )$ and signature keys using the $\mathsf {SIG}$ algorithm $( pk ^\mathsf {sg}, sk ^\mathsf {sg}) \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\mathsf {SIG.Gen}$, and outputs

  $$\begin{aligned} ( pk , sk ) := (( pk ^\mathsf {nike-static}, pk ^\mathsf {sg}), ( sk ^\mathsf {nike-static}, sk ^\mathsf {sg})). \end{aligned}$$

• $\mathsf {KE^{client}_{init}} ( pk _j,r_i)$ samples $r_i \mathop {\leftarrow }\limits ^{{\scriptscriptstyle \$}}\{0,1\}^\lambda$, parses $pk _j=( pk ^\mathsf {nike-static} _j, pk ^\mathsf {sg} _j)$, runs $( pk ^\mathsf {nike} _i, sk ^\mathsf {nike} _i) \leftarrow \mathsf {NIKE.Gen} (1^\lambda , r_i)$ and $k^\mathsf {nike} _{i, j} \leftarrow \mathsf {NIKE.Key} ( sk ^\mathsf {nike} _i, pk ^\mathsf {nike-static} _j)$, and outputs

  $$\begin{aligned} (k_{\mathtt {tmp}}^{{i},{j}}, m_i):=(k^\mathsf {nike} _{i, j}, pk ^\mathsf {nike} _i). \end{aligned}$$

• $\mathsf {KE^{server}_{refresh}} ( sk _j,r_j,m_i)$ takes in $m_i= pk ^\mathsf {nike} _i$, parses $sk _j=( sk ^\mathsf {nike-static} _j, sk ^\mathsf {sg} _j)$, and samples $r_j \mathop {\leftarrow }\limits ^{\$}\{0,1\}^\lambda$. It then computes $k^\mathsf {nike} _{i, j} \leftarrow \mathsf {NIKE.Key} ( sk ^\mathsf {nike-static} _j, pk ^\mathsf {nike} _i)$, $( pk ^\mathsf {nike} _{j}, sk ^\mathsf {nike} _{j}) \leftarrow \mathsf {NIKE.Gen} (1^\lambda ,r_j)$, and $\sigma _j\leftarrow \mathsf {SIG.Sign} ( sk ^\mathsf {sg} _j, pk ^\mathsf {nike} _{j} )$. If $m_i= pk ^\mathsf {nike-static} _j$ then it samples $k^\mathsf {nike}_\mathtt {main}$ uniformly random, else it computes $k^\mathsf {nike}_\mathtt {main} \leftarrow \mathsf {NIKE.Key} ( sk ^\mathsf {nike} _j, pk ^\mathsf {nike} _i)$, outputting

  $$\begin{aligned} (k_{\mathtt {main}}^{{j},{i}}, k_{\mathtt {tmp}}^{{j},{i}},m_j):=(k^\mathsf {nike}_\mathtt {main} , k^\mathsf {nike} _{i, j}, ( pk ^\mathsf {nike} _j, \sigma _j)). \end{aligned}$$

• $\mathsf {KE^{client}_{refresh}} ( pk _j,r_i,m_j)$ parses $pk _j=( pk ^\mathsf {nike-static} _j, pk ^\mathsf {sg} _j)$ and $m_j=( pk ^\mathsf {nike} _j, \sigma _j)$. It then checks $\mathtt {true}\leftarrow \mathsf {SIG.Vfy} ( pk ^\mathsf {sg} _j,\sigma _j, pk ^\mathsf {nike} _j)$ and computes $k^\mathsf {nike}_\mathtt {main} \leftarrow \mathsf {NIKE.Key} ( sk ^\mathsf {nike} _i, pk ^\mathsf {nike} _j)$, outputting $k_{\mathtt {main}}^{{i},{j}}:= k^\mathsf {nike}_\mathtt {main}$.

Ultimately, the construction follows by applying the NIKE $\mathsf {NIKE.Gen}$ algorithm and the signature $\mathsf {SIG.Gen}$ algorithm to generate a server configuration file which is comprised of the server public key and a server public signature key which a client can then employ for generating the first protocol flow. In order for the 0-RTT KE construction to abstract the security guarantees of the underlying NIKE, the appropriate client $( pk ^\mathsf {nike} _i, sk ^\mathsf {nike} _i)$ must be available for use in the $\mathsf {NIKE.Key}$ algorithm. Consequently, the $( pk ^\mathsf {nike} _i, sk ^\mathsf {nike} _i)$ values are generated locally by the client, with $pk ^\mathsf {nike} _i$ passed to the server as a message. Note that this construction naturally forgoes client-side authentication. Figure 3 demonstrates the construction.

Remark 4

One may wonder why we define $\mathsf {KE^{server}_{refresh}} ( sk _j,r_j,m_i)$ such that it samples a random key when it takes as input a client message $m_i$ which is equal to its own static NIKE key, that is, if $m_i = pk ^\mathsf {nike-static} _j$. We note that this is necessary for the security the constructed 0-RTT KE scheme to be reducible to that of the NIKE scheme, because in some cases we will not be able to simulate the key computed by a server oracle that receives as input a message which is equal to the “static” NIKE public key contained in its 0-RTT KE public key. Note that this incurs a negligible correctness error. However, it is straightforward to verify the correctness of the protocol according to Definition 4.

Theorem 1

Let $\mathsf {0\text {-}RTT}$ be executed with d clients, $\ell$ servers with long-term keys, and k server oracles modeling each server. From each attacker $\mathcal {A}$, we can construct attackers $\mathcal {B}_{sig}$, according to Definition 1, and $\mathcal {B}_{nike}$, according to Definition 3, such that

$$\begin{aligned} \mathtt {Adv}^{\mathcal {\text {0}RTT}-sa}_{\mathcal {A}}&(\lambda ) \le 2kd\ell \cdot \left( \mathtt {Adv} _{\mathsf {NIKE},\mathcal {B}_{nike}}^{\textit{CKS}\text {-}{} \textit{light}}(\lambda ) +\mathtt {Adv} _{\mathsf {SIG},\mathcal {B}_{sig}}^{ sEUF \text {-} CMA }(\lambda )\right) \\&+ d\ell \cdot \left( k \cdot \mathtt {Adv} _{\mathsf {NIKE},\mathcal {B}_{nike}}^{\textit{CKS}\text {-}{} \textit{light}}(\lambda ) +\mathtt {Adv} _{\mathsf {SIG},\mathcal {B}_{sig}}^{ sEUF \text {-} CMA }(\lambda )\right) \\&+ d \ell \cdot \left( \mathtt {Adv} _{\mathsf {NIKE},\mathcal {B}_{nike}}^{\textit{CKS}\text {-}{} \textit{light}}(\lambda ) +\mathtt {Adv} _{\mathsf {SIG},\mathcal {B}_{sig}}^{ sEUF \text {-} CMA }(\lambda )\right) + 4\cdot \mathtt {Adv} _{\mathsf {NIKE},\mathcal {B}_{nike}}^{\textit{CKS}\text {-}{} \textit{light}}(\lambda ) \ .\\ \end{aligned}$$

The running time of $\mathcal {B}_{sig}$ and $\mathcal {B}_{nike}$ is approximately equal to the time required to execute the security experiment with $\mathcal {A}$ once.

Intuition for the Proof of Theorem 1 . In order to prove Theorem 1, we distinguish between four types of attackers:

• adversary $\mathcal {A} _1$ asks $\mathtt {Test}()$ to a client oracle and the temporary key (CT-attacker)

• adversary $\mathcal {A} _2$ asks $\mathtt {Test}()$ to a client oracle and the main key (CM-attacker)

• adversary $\mathcal {A} _3$ asks $\mathtt {Test}()$ to a server oracle and the temporary key (ST-attacker)

• adversary $\mathcal {A} _4$ asks $\mathtt {Test}()$ to a server oracle and the main key (SM-attacker).

Let us give some intuition why this classification of attackers will be useful for the security proof. In the 0-RTT KE scheme $\mathsf {0\text {-}RTT}$ each party computes 2 different keys $k_{\mathtt {tmp}}^{{},{}}$ and $k_{\mathtt {main}}^{{},{}}$, where $k_{\mathtt {tmp}}^{{},{}}$ depends on the ephemeral keys of the client and the static keys of the server, and $k_{\mathtt {main}}^{{},{}}$ depends on the ephemeral keys of both parties. In our proof we want to be able to reduce the indistinguishability of the 0-RTT-key to the indistinguishability of the NIKE-key.

In the NIKE security experiment the attacker receives two challenge public keys $\{ pk ^\mathsf {nike} _i, pk ^\mathsf {nike} _j\}$. In the reduction, we want to embed these keys in the 0-RTT security experiment, according to Sect. 3.2, and still be able to answer all $\mathtt {Reveal}()$- and $\mathtt {Corrupt}()$-queries correctly. In the case of adversaries that test the temporary key of the client or the server we can embed the NIKE-keys as $pk ^\mathsf {nike-static} _j= pk ^\mathsf {nike} _j$ and $m_i= pk ^\mathsf {nike} _i$. However, this does not work for adversaries against the main key, because $k_{\mathtt {main}}^{{},{}}$ depends on the ephemeral keys of the parties. In this case we have to embed the keys as $m_i= pk ^\mathsf {nike} _i$ and $m_j= pk ^\mathsf {nike} _j$. The $\mathtt {Test}()$-query of the attacker in the 0-RTT experiment can then be answered with the challenge the attacker in the NIKE experiment receives.