Implementing and Proving the TLS 1.3 Record Layer

Antoine Delignat-Lavaud, Cédric Fournet,Markulf Kohlweiss, Jonathan Protzenko, Aseem Rastogi,

Nikhil Swamy, Santiago Zanella-BéguelinMicrosoft Research

{antdl,fournet,markulf,protz,aseemr,

nswamy,santiago}@microsoft.com

Karthikeyan Bhargavan, Jianyang Pan,Jean Karim ZinzindohouéINRIA Paris-Rocquencourt

karthikeyan.bhargavan@inria.fr,panyang314@gmail.com,

jean-karim.zinzindohoue@inria.fr

Abstract—The record layer is the main bridge between TLSapplications and internal sub-protocols. Its core functionalityis an elaborate form of authenticated encryption: streamsof messages for each sub-protocol (handshake, alert, andapplication data) are fragmented, multiplexed, and encryptedwith optional padding to hide their lengths. Conversely, the sub-protocols may provide fresh keys or signal stream terminationto the record layer.

Compared to prior versions, TLS 1.3 discards obsoleteschemes in favor of a common construction for AuthenticatedEncryption with Associated Data (AEAD), instantiated withalgorithms such as AES-GCM and ChaCha20-Poly1305. Itdiffers from TLS 1.2 in its use of padding, associated dataand nonces. It also encrypts the content-type used to multiplexbetween sub-protocols. New protocol features such as earlyapplication data (0-RTT and 0.5-RTT) and late handshakemessages require additional keys and a more general modelof stateful encryption.

We build and verify a reference implementation of theTLS record layer and its cryptographic algorithms in F?,a dependently typed language where security and functionalguarantees can be specified as pre- and post-conditions. Wereduce the high-level security of the record layer to crypto-graphic assumptions on its ciphers. Each step in the reductionis verified by typing an F? module; for each step that involvesa cryptographic assumption, this module precisely captures thecorresponding game.

We first verify the functional correctness and injectivityproperties of our implementations of one-time MAC algorithms(Poly1305 and GHASH) and provide a generic proof of theirsecurity given these two properties. We show the security ofa generic AEAD construction built from any secure one-timeMAC and PRF. We extend AEAD, first to stream encryption,then to length-hiding, multiplexed encryption. Finally, we builda security model of the record layer against an adversarythat controls the TLS sub-protocols. We compute concretesecurity bounds for the AES_128_GCM, AES_256_GCM,and CHACHA20_POLY1305 ciphersuites, and derive recom-mended limits on sent data before re-keying.

We plug our implementation of the record layer into themiTLS library, confirm that they interoperate with Chromeand Firefox, and report initial performance results. Combiningour functional correctness, security, and experimental results,we conclude that the new TLS record layer (as described inRFCs and cryptographic standards) is provably secure, andwe provide its first verified implementation.

I. INTRODUCTION

Transport Layer Security (TLS) is the main protocolfor secure communications over the Internet. With the fastgrowth of TLS traffic (now most of the Web [48]), numerousconcerns have been raised about its security, privacy, andperformance. These concerns are justified by a history ofattacks against deployed versions of TLS, often originatingin the record layer.

History and Attacks Wagner and Schneier [49] reportmany weaknesses in SSL 2.0. The MAC construction offersvery weak security regardless of the encryption strength. Thepadding length is unauthenticated, allowing an attacker totruncate fragments. Stream closure is also unauthenticated;although an end-of-stream alert was added in SSL 3.0,truncation attacks persist in newer TLS versions [12, 44].

The original MAC-pad-encrypt mode is not genericallysecure [31] and is brittle in practice, despite encouragingformal results for specific algorithms [2, 11, 39]. Manypadding oracle attacks have surfaced over the years, rangingfrom attacks exploiting straightforward issues (such as im-plementations sending padding error alerts after decryption)to more advanced attacks using side channels [1, 37].Although well understood, padding oracle attacks remaindifficult to prevent in TLS implementations [45]. The CBCmode of operation is also not secure against chosen-plaintextattacks when the IV is predictable (as in TLS 1.0), whichis exploited in the BEAST attack [20]. Random explicitIVs [15] and CBC mode for 64-bit block ciphers [10]are also vulnerable to birthday attacks. Finally, fragmentcompression can be exploited in adaptive chosen-plaintextattacks to recover secrets [40].

Even with provably-secure algorithms, functional cor-rectness and memory safety are essential, inasmuch asimplementation bugs can easily nullify security guarantees.For instance, the OpenSSL implementation of ChaCha20-Poly1305 has been found to contain arithmetic flaws [14]and more recently, a high severity buffer overflow vulnera-bility [47].

Changes in TLS 1.3 The IETF aims to robustly fix the

Key 2 Key 3

Key 3Key 1Key 0 (1 sided)

Handshake

AppData

Alert

Plaintext

Handshake

AppData

Alert

Plaintext Key 1

Write channel

Read channel

Key 2

Figure 1. Multiplexing of sub-protocol streams by the record layer,depicting a TLS 1.3 draft-19 0-RTT handshake with re-keying.

weaknesses of the record layer by adopting a single AEADmode for all ciphersuites, thus deprecating all legacy modes(MAC-only, MAC-pad-encrypt, RFC 7366 [26] encrypt-then-MAC, compress-then-encrypt). The new AEAD modeis designed to be provably-secure and modular, supportingalgorithms such as AES-GCM, AES-CCM, and ChaCha20-Poly1305 within the same framework. The usage of AEADhas also been improved: authentication no longer relieson associated data, whereas implicit nonces derived frominitialization vectors (IV) and sequence numbers yield bettersecurity and performance.

What is the Record Layer? TLS involves establishingand using many encryption keys. In the key exchangeliterature, a common viewpoint is to treat each key generatedin the handshake as belonging to a specific, independentapplication. Under this model, the handshake encryption keyis used only by the handshake to encrypt its own messages,and must be separate from the application data key usedonly to encrypt application data fragments. This model doesnot fit the actual use of keys in TLS: it fails to capture TLS1.2 renegotiation (where handshake messages are interleavedwith the application data stream), TLS 1.3 post-handshakeauthentication and re-keying, or even alerts in any TLSversion. In our modularization of TLS, following Bhargavanet al. [11], we consider that each sub-protocol of TLS—handshake, change cipher spec (CCS), alert and applicationdata (AppData)—defines its own data stream. The role ofthe record is to multiplex all of these streams into one,corresponding to network messages after fragmentation,formatting, padding, and optional record-layer encryption.Under this model, the record layer is the exclusive user forall non-exported keys generated by the handshake, and thereis no need to assign keys to any given sub-protocol stream.

Figure 1 illustrates the stream multiplexing for a TLS1.3 connection with 0-RTT data and one re-keying from thepoint of view of the client. Separate channels are used forwriting and reading. Within each channel, a band in thefigure represents a stream, and arrows represent message

Record

LHSE

StAE

AEAD

PRF MAC VerifiedCrypto library

GenericAEADconstruction

StreamEncryption withsequencenumbers

Length-Hiding (padded)Multiplexed Streams

Sequence ofstreamskeyedbyHandshake

ChaCha20AES Poly1305GHASH

Handshake/Alert Application

fragments: d0,d1,d2keys:k0,k1,…

TLSspecific

Generic

Figure 2. Modular structure of our proof. Green arrows denote securityreductions proved by typing.

fragments (incoming for left arrows, outgoing for rightarrows) over time (flowing from left to right). Dashed arrowsrepresent fragments used to signal key changes to the recordlayer. In TLS 1.2, CCS messages signal key changes; in TLS1.3 this function is taken over by handshake messages.

Related Work Since the first draft of TLS 1.3 in April2014, the handshake and key schedule have undergonesignificant analysis efforts [17, 18, 23, 28, 29, 32] as theirdesign evolved over 19 iterations (at the time of writing). Incontrast, few authors have analyzed changes to the recordlayer: Fischlin et al. [22] and Badertscher et al. [3] analyzean early draft that did not feature many of the currentchanges (for instance, it still relied on associated data toauthenticate record meta-data), and Bellare and Tackmann[7] specifically focus on the way nonces are derived fromIVs. This focus on the handshake protocol may be explainedby the difficulty of analyzing the record independently of thehandshake, and more generally, of defining the precise scopeof its functionality. Authenticated and Confidential ChannelEstablishment (ACCE) [27, 33] is a game-based model thatcombines the handshake and the record protocols. WhileACCE models capture complex features of TLS 1.2 such asrenegotiation [25], its focus is primarily on the handshake,and it is unclear how to capture features such as post-handshake authentication [19]. Other limits of ACCE modelsare discussed in [3].

Our contributions We provide a reference implementationof the TLS record layer and its underlying cryptographicalgorithms using the F? programming language. We definesecurity as an indistinguishability game and show a reduc-tion with concrete bounds (Table I) for any distinguisherto standard, low-level cryptographic assumptions. Our proofstructure is depicted in Figure 2; from the bottom up:

1) We build a generic library for one-time message au-thentication codes (MAC) based on the Wegman-Carter-Shoup construction. We implement the GHASH andPoly1305 algorithms, and we prove the functional correct-ness (with regards to mathematical specifications), memorysafety, and encoding injectivity of the resulting low-levelcode (§III). Similarly, we build a library for pseudo-randomfunctions (PRF), and provide functionally-correct, memory-safe implementations for AES and ChaCha20 (§IV). Weexpress the security guarantees of these libraries using cryp-tographic idealizations backed by game-based assumptions.

2) We describe a generic AEAD construction thatcaptures both RFC 5288 [41] for AES-GCM (as de-scribed in NIST SP800-38D [21]) and RFC 7539 [38] forChaCha20-Poly1305 through an interface compatible withRFC 5116 [36]. We show that this construction satisfies astandard notion of AEAD security (§V) that combines in-distinguishability under chosen-plaintext attacks (IND-CPA)with ciphertext integrity (INT-CTXT). Our proof applies toour F? implementation and, based on the idealizations ofour two libraries, is verified by typing—as are the followingthree steps:

3) From AEAD, we build and verify stream encryption,which uses AEAD nonces and record sequence numbersaccording to the TLS version-specific format (§VI).

4) From stream encryption, we build a length-hidingencryption interface by adding padding, the TLS-specificcontent type multiplexing, and version-specific associateddata (§VII).

5) From length-hiding stream encryption with multiplex-ing, we implement the TLS record layer by adding interfacesto the handshake and alert sub-protocols that extend streamsto sequences of streams by installing and enabling keys(§VIII). This captures novel protocol features of TLS 1.3such as early application data (0-RTT and 0.5 RTT), latehandshake messages, and re-keying. Based on our securitybound, we propose a re-keying strategy that compensates forpotential weaknesses in AES-GCM.

6) We evaluate our implementation of the TLS recordlayer (§IX) by linking our AES-GCM and ChaCha20-Poly1305 ciphersuites to the handshake implementation ofmiTLS [11]. We confirm network interoperability with otherTLS libraries both for TLS 1.2 and TLS 1.3 draft-14 anddraft-18. Our code and formal development maximize reusebetween TLS 1.2 and 1.3.

Additional Materials An extended version of this pa-per with additional details and proofs of the results in§III, §IV, and §V is available from a companion websitehttps://project-everest.github.io/record/. This website alsoprovides links to online repositories that include all verifiedcode we report on in the paper, as well as instructions onhow to verify, extract and run the code.

II. COMPOSITIONAL VERIFICATION BY TYPING

To implement and verify the record layer, we adopt a compo-sitional approach to functional correctness and cryptographicsecurity based on F? [46], a dependently-typed program-ming language. This section explains our approach on twoexamples: arithmetic in a prime field for the Poly1305algorithm, and basic authenticated encryption. We refer thereader to Fournet et al. [24] for a general presentation of ourapproach and Barthe et al. [4] for a probabilistic semanticsof F? and additional cryptographic examples.

We use F? not only to implement cryptographic con-structions, but also as the formal syntax for their game-based security definitions. This is akin to the approachtaken by Bhargavan et al. [13] in their proof of a TLS1.2 handshake implementation using F7, an ancestor of F?.In contrast to F7, F? supports an imperative programmingstyle that is closer to pseudo-code used by cryptographers incode-based games [5]. For most of the paper, we use suchpseudo-code instead of more precise and verbose F? code.We do not assume familiarity with F? and elide details ofits syntax, such as type annotations, that are not relevant forthe developments in this paper.

Functional Correctness of Poly1305 As a first example inF? syntax, we specify arithmetic in the field GF (2130 − 5)for the Poly1305 MAC algorithm as follows:

let p = 2^130 − 5 (∗ the prime order of the field ∗)type elem = n:nat {n < p} (∗ the type of field elements ∗)let x +@ y : Tot elem = (x + y) % p (∗ field addition ∗)let x ∗@ y : Tot elem = (x ∗ y) % p (∗ field multiplication ∗)

This code uses F? mathematical (unbounded) natural num-bers to define the prime order p of the field and the typeof field elements. (The formula {n < p} line 2 states thatthis type is inhabited by natural numbers n smaller than p.)The code also defines two infix operators +@ and ∗@ foraddition and multiplication in the field, relying on primitive,unbounded integer arithmetic. Their result is annotated withtypes Tot elem, to indicate that these operations are puretotal functions that return field elements. Hence, the F?

typechecker automatically checks that their result is in thefield; it would report an error if e.g. we omitted the reduc-tion modulo p. These operations are convenient to specifypolynomial computations (see §III-B) but highly inefficient.

Instead, typical 32-bit implementations of Poly1305 rep-resent field elements as mutable arrays of 5 unsigned 32-bitintegers, each holding 26 bits. This low-level representationevenly spreads out the bits across the integers, so thatcarry-overs during arithmetic operations can be delayed. Italso enables an efficient modulo operation for p. We showbelow an excerpt of the interface of our lower level verifiedimplementation, relying on the definitions above to specifyits correctness.

abstract type repr = buffer UInt32.t 5 (∗ 5-limb representation ∗)val select: memory → r:repr → Tot elem (∗ current value held in r ∗)val multiply: e0:repr → e1:repr → ST unit

(requires live e0 ∧ live e1 ∧ disjoint e0 e1)(modifies e0)(ensures select e0′ = select e0 ∗@ select e1)

The type repr defines the representation of field elementsas F? buffers (i.e., mutable arrays) of 5 32-bit integers. Itis marked as abstract, to hide this representation from therest of the code. Functions are declared with a series ofargument types (separated by → ) ending with a return typeand an effect (e.g. Tot or ST). Functions may have logical pre-and post-conditions that refer to their arguments, their result,and their effects on the memory. If they access buffers, theytypically have a pre-condition requiring their caller to provethat the buffers are ‘live’ in the current memory (that is, theyhave been allocated and haven’t been de-allocated yet) andthey also explicitly state which buffers they modify.

The total function select is used only in specifications; itreads the value of an element from the program memory. Weuse it, for example, in the stateful specification of multiply.In the types above, we keep the memory argument implicit,writing select e0 and select e0′ for the values of e0 in initialand final memories, respectively. (In real F? code, pre- andpost-conditions take these memories as explicit arguments.)

The multiply function is marked as ST, to indicate a statefulcomputation that may use temporary stack-based allocations.It requires that its arguments e0 and e1 be live and disjoint;it computes the product of its two arguments and overwritese0 with the result. Its post-condition specifies the result interms of the abstract field multiplication of the arguments.

Implementing and proving that multiply meets its mathe-matical specification involves hundreds of lines of sourcecode, relying on a custom Bignum library with lemmas oninteger representations and field arithmetic (see §IX). Suchcode is easy to get wrong, but once F? typechecks it, weare guaranteed that our low-level code is safe (e.g. it neveraccesses buffers out of bound, or de-allocated buffers) andfunctionally correct (since their results are fully specified).All F? types and specifications are then erased, so that thecompiled code only performs efficient low-level operations.

Authenticated Encryption: Real Interface Let us considera simplified version of the authenticated encryption (AE)functionality at the core of the TLS record layer. In F?, wemay write an AE module with the following interface:

val `p: natval `c: nattype lbytes (`:nat) = b:bytes{length b = `}type bbytes (`:nat) = b:bytes{length b ≤ `}type plain = lbytes `ptype cipher = lbytes `cabstract type keyval keygen: unit → ST keyval decrypt: key → cipher → Tot (option plain)val encrypt: k:key → p:plain → ST (c:cipher{decrypt k c = Some p})

Plaintexts and ciphertexts are represented here as im-mutable bytestrings of fixed lengths `p and `c. We frequentlyrely on type abbreviations to statically enforce length checksfor fixed-length bytestrings using lbytes `, and for bounded-length bytestrings using bbytes `. (Our presentation usesimmutable bytestrings for simplicity, whereas our record-layer implementation also uses mutable buffers of bytes.)

Next, our interface defines an abstract type key; valuesof this type can only be generated via keygen and accessedvia encrypt and decrypt. The internal representation of keys ishidden from all other modules to protect their integrity andsecrecy. The function keygen needs to generate randomnessby calling an effectful external function; so we give thisfunction the ST effect to indicate that the computation isimpure and stateful (even though it does not explicitlymodify the memory). In particular, two calls to keygen mayyield different results. The function encrypt would typicallygenerate a nonce for use in the underlying AE construction,and hence is also marked as stateful. In contrast, decrypt isdeterministic, so is marked with the Tot effect. Its result isan optional plain value: either Some p if decryption succeeds,or None otherwise. In pseudo-code we write ⊥ for brevity.

Our interface does not express any security guaranteesyet, but it does require a functional correctness guarantee,namely that decryption undoes encryption.

Authenticated Encryption: Security Given an AE scheme,one usually measures its concrete security as the advantageof an adversary A that attempts to guess the value of b inthe following game:

Game Ae(A,AE)b

$← {0, 1}; L← ∅; k$← AE.keygen()

b′ ← AEncrypt,Decrypt(); return (b ?= b′)

Oracle Encrypt(p)

if b then c$← byte`c ; L[c]← p

else c← AE.encrypt k preturn c

Oracle Decrypt(c)

if b then p← L[c]else p← AE.decrypt k creturn p

The adversary A is a program that can call the two oraclefunctions to encrypt and decrypt using a secret key k. In thereal case (b = 0) they just call the real AE implementation.In the ideal case (b = 1), Encrypt returns a randomlysampled ciphertext and stores the associated plaintext in alog L, while Decrypt performs decryption by looking up theplaintext in the log, returning ⊥ when there is no plaintextassociated with the ciphertext. Ideal AE is perfectly secure,inasmuch as the ciphertext does not depend on the plaintext.Thus, we define AE security by saying that the attackercannot easily distinguish between the real and ideal cases.

For this game, we define A’s advantage probabilisticallyas |2Pr[Ae(A,AE)]− 1|, e.g. an adversary flipping a coin toguess b will succeed with probability 1

2 and has 0 advantage.In this paper, we adopt a more flexible notation for

indistinguishability games: we keep the sampling of b andthe call to the adversary implicit, and instead indicate theoracles available to this adversary. Hence, we write the gameabove (with the same oracles) equivalently as

Game Aeb(AE)

L← ∅ ; k$← AE.keygen(); return {Encrypt,Decrypt}

This notation facilitates the re-use of oracles for build-ing other games, much like F? modules. In general, wewrite Gb to refer to an indistinguishability game G wherethe adversary A tries to guess the value of the ran-dom bit b by calling the oracles returned by G. Forall such games, we equivalently define the advantage as∣∣∣Pr[AG1

= 1]− Pr[AG0

= 1]∣∣∣.

Embedding games in F? modules Although we wrotethe game Aeb above in pseudo-code, each game in thispaper reflects a verified F? module, written e.g. AEb, thatuses a boolean flag b to select between real and idealimplementations of the underlying cryptographic moduleAE. For example, AEb may define the key type and encryptfunction as

abstract type key = {key: AE.key; log: encryption_log}let encrypt (k:key) (p:plain) =

if b thenlet c = random_bytes `c ink.log ← k.log ++ (c,p);c

else AE.encrypt k.key p

where the (private) key representation now includes both thereal key and the ideal encryption log. The encrypt functionuses k.log to access the current log, and ++ to append a newentry, much as the Encrypt oracle.

Idealization Interfaces The idealized module AEb canbe shown to implement the following typed interface thatreflects the security guarantee of the Aeb game:

abstract type keyval log: memory → key → Spec (seq (cipher × plain))val keygen: unit → ST k:key

(ensures b ⇒ log k′ = ∅)val encrypt: k:key → p:plain → ST (c:cipher)

(ensures b ⇒ log k′ = log k ++ (c,p))val decrypt: k:key → c:cipher → ST (o:option plain)

(ensures b ⇒ o = lookup c (log k) ∧ log k’ = log k)

The interface declares keys as abstract, hiding both thereal key value and the ideal log, and relies on the log tospecify the effects of encryption and decryption. To this end,it provides a log function that reads the current content of thelog—a sequence of ciphertexts and plaintexts. This functionis marked as Spec, indicating that it may be used only inspecification and will be discarded by the compiler aftertypechecking.

Each of the 3 ensures clauses above uses this proof-onlyfunction to specify the state of the log before (log k) and afterthe call (log k′). Hence, the interface states that, in the ideal

case, the function keygen creates a key with an empty log;encrypt k p returns a ciphertext c and extends the log for kwith an entry mapping c to p; and decrypt k c returns exactlythe result of looking up for c in the current log. This post-condition formally guarantees that decrypt succeeds if andonly if it is passed a ciphertext that was generated by encrypt;in other words it guarantees both functional correctness andauthentication (a notion similar to INT-CTXT).

AEb is also parametrized by a module Plainb that definesabstract plaintexts, with an interface that allows access totheir concrete byte representation only when b = 0 (for realencryption). By typing AEb, we verify that, when b = 1,our idealized functionality is independent (information-theoretically) from the values of the plaintexts it processes.

From the viewpoint of the application, the plaintext ab-straction guarantees that AE1 preserves the confidentialityand integrity of encrypted data (as in classic informationflow type systems). An application can rely on this fact toprove application-level guarantees. For instance, an applica-tion may prove, as an invariant, that only well-formed mes-sages are encrypted under a given key, and thus that parsingand processing a decrypted message always succeeds.

Probabilistic Semantics We model randomness (e.g.random_bytes) using primitive sampling functions. TwoBoolean terminating F? programs A0 and A1 are equivalent,written A0 ≈ A1, when they return true with the sameprobability. They are ε-equivalent, noted A0 ≈ε A1, when|Pr[A1⇓ true]−Pr[A0⇓ true]| ≤ ε where Pr[A⇓v] denotesthe probability that program A evaluates to value v accordingto the probabilistic semantics of F?. These definitions extendto program evaluation contexts, written Ab[_], in whichcase ε depends on the program plugged into the context,which intuitively stands for the adversary. Equipped withthese definitions, we can develop code-based game-playingproofs following the well-established approach of Bellareand Rogaway [5] directly applied to F? programs rather thanpseudo-code. For example, we can reformulate AE securityas AE1[A] ≈ε AE0[A], where A now ranges over well-typed Boolean programs parameterized by the two functionsencrypt and decrypt defined by AEb. Our definition of ε-equivalence between real and ideal implementations of AEb

matches the definition of A’s advantage in the Aeb game.

Concrete security definitions and reductions As illus-trated for AE below, our security definitions will consistof a game and a notation for the adversary advantage,parameterized by a measure of oracle use (e.g. how manytimes an adversary calls an oracle is called). We intend toprovide concrete bounds on those advantages, as a functionof their parameters. To this end, our reduction theoremswill relate the advantage for a given construction to theadvantages of its building blocks.

Definition 1 (AE-security): Given AE, let εAe(A[qe, qd])be the advantage of an adversary A that makes qe queriesto Encrypt and qd queries to Decrypt in the Aeb(AE) game.

Equipped with this definition and our idealized interfacefor AE, we can prove the security of programs using idealAE (b = 1), say with advantage ε, and then bound theadvantage of the same programs using real AE (b = 0) toε+ εAe(A[qe, qd]).

We can either assume that this definition holds for our realAE module with an εAe that is small for realistic adversaries(possibly relying on functional correctness and some priorproof of security), or we can prove that our AES-GCMmodule (say) achieves some bound on εAe by reduction toa simpler assumptions on the AES cipher module. In latersections, we will show how we can precisely compute theadversary A’s advantage in the game above from a relatedadversary B’s advantage in winning the PRF game on theunderlying cipher (e.g. AES). The proof relies on standardcryptographic game transformations that are applied, onpaper, at the level of F? code, combined with functionalcorrectness proofs about the real and ideal code, verifiedautomatically by F?.

Games vs Idealized Modules We conclude this presenta-tion of our approach by discussing differences between thegames on paper and the modules of our implementation.

Standard-compliant modules include many details elidedin informal games; they also use lower level representationsto yield more efficient code, and require additional typeannotations to keep track of memory management.

These modules are part of a general-purpose verifiedcryptographic libraries, providing real functionality (whenidealizations flags are off) so they always support multipleinstances of their functionality. Here for instance, AEb has afunction to generate keys, passed as parameters to the encryptfunction, whereas the game oracle uses a single, implicitkey. (This difference can usually be handled by a standardhybrid-argument reduction.)

Modules rely on the F? type system to enforce the rulesof the games. Hence, dynamic checks in games (say, to testwhether a nonce has already been used) are often replacedwith static pre-conditions on typed adversaries. Similarly,types enforce many important but trivial conditions, such asthe length of oracle arguments, and are often kept implicitin the paper.

III. ONE-TIME MACS

Anticipating on §V, the AEAD construction uses freshkey materials for each message, so we consider authentica-tion when keys are used to compute at most one MAC.

We treat two main constructions, GHASH and Poly1305,using the same definitions, code, and proofs, inasmuch as

possible. We initially suppose that the whole key is freshlygenerated for each MAC (as in ChaCha20-Poly1305) beforepresenting the general case where a part of the key is sharedbetween multiple MACs (as in AES-GCM).

A. One-time MAC functionality and security

We outline below our interface for message authenticationcode (MAC), omitting its functional specification (see §IX).val `k0

: nat (∗ static key length, may be 0 ∗)val `k: n:nat {`k0

≤ `k} (∗ total key length ∗)val `t: nat (∗ tag length ∗)val `m: nat (∗ maximal message length ∗)type key0 = lbytes `k0

(∗ static key shared between MACs ∗)type key = lbytes `k (∗ one−time key (including static key) ∗)type tag = lbytes `t (∗ authentication tag ∗)type message = b:bbytes `b {wellformed b}val keygen0: unit → ST key0val keygen: key0 → ST keyval verify: key → message → tag → Tot boolval mac: k:key → m:message → Tot (t:tag{verify k m t})

This interface defines concrete byte formats for keys, tags,and messages. Authenticated messages are strings of atmost `m bytes that comply with an implementation-specificwell-formedness condition. (We need such a condition forGHASH.) We let m range over well-formed messages.

Key-generation functions are marked as stateful (ST) toreflect their use of random sampling. Static keys of type key0may be used to generate multiple one-time keys of type key.(For example, keygen may concatenate the static key with`k − `k0 random bytes.) To begin with, we assume `k0 = 0so that k0 is the empty string ε.

The two main functions produce and verify MACs. Theircorrectness is captured in the verify post-condition of mac:verification succeeds at least on the tags correctly producedusing mac with matching key and message.

One-Time Security MAC security is usually defined usingcomputational unforgeability, as in the following game:

Game UF-1CMA(A,MAC)

k$← MAC.keygen(ε); log← ⊥

(m?, t?)← AMac

return MAC.verify(k,m?, t?)∧ log 6= (m?, t?)

Oracle Mac(m)if log 6= ⊥ return ⊥t← MAC.mac(k,m)log← (m, t)return t

The oracle permits the adversary a single chosen-messagequery (recorded in log) before trying to produce a forgery.The advantage of A playing the UF-1CMA game is definedas εUF-1CMA(A[`m]) , Pr[UF-1CMA(A,MAC) = 1].

We seek a stronger property for AEAD—the whole ci-phertext must be indistinguishable from random bytes—and we need a decisional game for type-based composition,so we introduce a variant of unforgeability that capturesindistinguishability from a random tag (when r is set).

Definition 2 (IND-UF-1CMA): Let εMac1(A[`m, qv]) bethe advantage of an adversaryA that makes qv Verify querieson messages of length at most `m in the following game:

Game Mac1b(MAC)

k$← MAC.keygen(ε); log← ⊥

return {Mac,Verify}

Oracle Verify(m?, t?)if b return log = (m?, t?)return MAC.verify(k,m?, t?)

Oracle Mac(m)if log 6= ⊥ return ⊥t← MAC.mac(k,m)if b ∧ rt

$← byteMAC.`t

log← (m, t)return t

In this game, the MAC oracle is called at most once, onsome chosen message m; it returns a tag t and logs (m, t).Conversely, Verify is called qv times before and after callingMAC. When b is set, the game idealizes MAC in two ways:verification is replaced by a comparison with the log; and(when r is also set) the tag is replaced with random bytes.

We show (in the full paper) that our definition implies UF-1CMA when qv ≥ 1 and that random tags are neither nec-essary nor sufficient for unforgeability. We are not aware ofmuch prior work on Mac1 with r set; a pairwise independenthash function would satisfy our IND-UF-1CMA definitionbut may require longer keys [42].

Multi-Instance Security with a Shared Key In the AEADconstruction, we instantiate a one-time MAC for everyencryption and decryption. AES-GCM uses a static MACkey derived from the AEAD key and shared between allMAC instances. This state sharing is not captured by thegames above. To this end, we extend the Mac1b game intoa multi-instance version MMac1b with a setup that invokesthe keygen0 function to generate any key materials reusedacross instances.

In the multi-instance case it is convenient to supporttwo kinds of instances: honest instances are created withKeygen and idealized as in Mac1b; dishonest instancesare created with Coerce and use the real implementationregardless of b. (Formally Coerce does not make the modelstronger, as an adversary can run all algorithms on his own.However, the finer model is useful in hybrid arguments andfor composition with a PRF in §IV.)

Definition 3 (m-IND-UF-1CMA):Let εMMac1(A[`m, qv, qi]) be the advantage of an adversaryA that creates qi instances and makes qv Verify queriesoverall on messages of length at most `m in the game:

Game MMac1b(MAC)log← ∅; k ← ∅; H ← ∅k0

$← MAC.keygen0()return {MAC,Verify,

Coerce,Keygen}

Oracle Mac(n,m)if k[n] = ⊥ return ⊥if log[n] 6= ⊥ return ⊥t← MAC.mac(k[n],m)if b ∧ n ∈ Ht

$← byteMAC.`t

log[n]← (m, t)return t

Oracle Keygen(n)if k[n] 6= ⊥ return ⊥k[n]← MAC.keygen(k0)H ← H ∪ nOracle Coerce(n, k)if k[n] 6= ⊥ return ⊥k[n]← k

Oracle Verify(n,m, t)if k[n] = ⊥ return ⊥v ← MAC.verify(k[n],m, t)if b ∧ n ∈ Hv ← log[n] = (m, t)

return v

We confirm that Mac1 is a special case of MMac1 securityand that, even with a static key, it suffices to consider a singleverification query. (The proofs are in the full paper.)

Lemma 1 (MMac1 reduces to Mac1): Given A againstMMac1b, when `k0 = 0, we construct B againstMac1b (linearly in qi) such that: εMMac1(A[`m, qv, qi]) ≤qi εMac1(B[`m, qv]).

Lemma 2: Given A against MMac1b we construct B suchthat: εMMac1(A[`m, qv, qi]) ≤ qv εMMac1(B[`m, 1, qi]).

Verified Implementation m-IND-UF-1CMA security re-flects the type-based security specification of our idealizedmodule MMac1b, which has an interface of the formval log: memory → key → Spec (option (message × tag))val mac: k:key → m:message → ST (t:tag)

(requires log k = None)(ensures log k′ = Some(m,t))

val verify: k:key → m:message → t:tag → ST (v:bool)(ensures b ⇒ v = (log k′ = Some(m,t)))

The types of mac and verify express the gist of our securityproperty: the specification function log gives access to thecurrent content of the log associated with a one-time key;mac requires that the log be empty (None in F?) therebyenforcing our one-time MAC discipline; verify ensures that,when b is set, verification succeeds if and only if mac loggedexactly the same message and tag. Their implementation isautomatically verified by typing MMac1b. However, recallthat typing says nothing about the security loss incurred byswitching b—this is the subject of the next subsection.

Our verified implementation of MMac1b supports the twoconstructions described next, including code and functionalcorrectness proofs for their algorithms. It also provides amore efficient interface for computing MACs incrementally.Instead of actually concatenating all authenticated materialsin a message, the user creates a stateful hash, then repeatedlyappends 16-byte words to the hash, and finally calls mac orverify on this hash, with a type that binds the message tothe final hash contents in their security specifications. Ourcode further relies on indexed abstract types to separate keysand hashes for different instances of the functionality, andto support static key compromise.

B. Wegman-Carter-Shoup (WCS) Constructions

Next, we set up notations so that our presentation appliesto multiple constructions, including GHASH and Poly1305;we factor out the encodings to have a core security as-sumption on sequences of field elements; we verify theirinjectivity; we finally prove concrete bounds in general, andin particular for GHASH and Poly1305.

From bytes to polynomials and back In addition to fixedlengths for keys and tags, the construction is parameter-ized by

• a field F;

• an encoding function · from messages to polynomialsin F, represented as sequences of coefficients m ∈ F∗.

• a truncation function from e ∈ F to tag(e) ∈ byte`t ;

The key consists of two parts: an element r ∈ F and a one-time pad s ∈ byte`t . We assume that r and s are sampleduniformly at random, from some R ⊆ F and from byte`t ,respectively. We write r‖s ← k for the parsing of keymaterials into r and s, including the encoding of r into R.

Generic Construction Given a message m encoded into thesequence of d coefficients m0, . . . ,md−1 of a polynomialm(x) =

∑i=1..dmd−ix

i in F, the tag is computed as:

hashr(m)← tag(m(r)) in F before truncationmac(r‖s,m)← hashr(m)� s in byte`t

where the blinding operation � is related to addition in F(see specific details below). We refer to hashr(m), the partof the construction before blinding, as the hash.

Next, we describe the two instantiations employed in TLS.

GHASH [21] uses the Galois field GF (2128), defined as theextension GF (2)[x]/x128+x7+x2+x+1, that is, the fieldof polynomials with Boolean coefficients modulo the irre-ducible polynomial x128+x7+x2+x+1. Such polynomialsare represented as 128-bit vectors. Conveniently, polynomialaddition, the blinding operation �, and its inverse � simplycorrespond to 128-bit XOR. Polynomial multiplication isalso efficiently supported on modern processors. The mes-sage encoding · splits the input message into 16-byte words,seen as integers in 0..2128− 1; and the tag truncation is theidentity. For AES-GCM, GHASH has a keygen0 functionthat samples a single r $← GF (2128) shared across all MACinstances.

Poly1305 [8] uses the field GF (p) for p = 2130 − 5, thatis, the prime field of integer addition and multiplicationmodulo p, whose elements can all be represented as 130-bitsintegers. Its message encoding · similarly splits the inputmessage into 16-byte words, seen as integers in 0..2128− 1,then adds 2` to each of these integers, where ` is the wordlength in bits. (Hence, the encoding precisely keeps track ofthe length of the last word; this feature is unused for AEAD,which applies its own padding to ensure ` = 128.) Thetruncation function is tag(e) = e mod 2128. The blindingoperation � and its inverse � are addition and subtractionmodulo 2128. For ChaCha20-Poly1305, both r and s aresingle-use (`k0 = 0) but our proof also applies to the originalPoly1305-AES construction [8] where r is shared.

Injectivity Properties We intend to authenticate messages,not just polynomial coefficients. To this end, we instantiateour wellformed predicate on messages and show (in F?) that

∀ (m0: bytes) (m1: bytes).( wellformed m0 ∧ wellformed m1 ∧

Poly.equals m0 m1 ) ⇒ m0 = m1

where Poly.equals specifies the equality of two formal polyno-mials by comparing their sequences of coefficients, extend-ing the shorter sequence with zero coefficients if necessary.This enables the (conditional) composition of MACs withsuitable well-formedness predicates for AEAD in TLS. Thisis required for GHASH as it is otherwise subject to 0-message truncations.

We verify that the property above suffices to prove thatboth encodings are secure, and also that it holds in particularonce we define wellformed as the range of formatted messagesfor AEAD (which are 16-byte aligned and embed their ownlengths; see §V). We also confirm by typing that, withPoly1305, there is no need to restrict messages: its encodingis injective for all bytestrings [8, Theorem 3.2].

Security We give a theorem similar to those in priorwork [8, 30, 43] but parameterized by the underlying fieldF, encoding · , truncation tag, and blinding operation �.The theorem covers all uses of AES-GCM and ChaCha20-Poly1305 in TLS.

Consider the MMac1 definition, covering both shared andfresh values for r. Let qv be the number of oracle calls toVerify (for which log[n] 6= (m?, t?)) and d a bound on thesize (expressed in number of field elements) of the messagesin calls to Mac and Verify.

Theorem 1: The Wegman-Carter-Shoup construction formessages in Fd−1 is m-IND-UF-1CMA secure with concretebound εMMac1(A[`m, qv, qi]) = d.τ.qv

|R| with d = `m/16, andτ = 1 for GHASH and τ = 8 for Poly1305.

The proof (in the full paper) uses Lemma 2 and establishesa bound d·τ

|R| for an adversary that makes a single Verify

query. This bound follows from an d·τ|R| -almost-�-universal

property, which has been separately proved for GHASH [35]and Poly1305 [8]; the full paperalso includes its proof forall instantiations of hashr for TLS.

Concrete bounds for GHASH: The range size for r is 2128

and there is no tag truncation, hence by Lemma 2 we get astraight ε = d·qv

2128 , so for TLS the main risk is a failure ofour PRF assumption on AES, discussed in §VII.

Concrete bound for Poly1305: The effective range R of ris reduced, first by uniformly sampling in 0..2128 − 1, thenby clamping 22 bits, to uniformly sampling one element outof | R |= 2106 potential values. We lose another 3 bits ofsecurity from the truncation of F to byte`t and by applyingLemma 2 we arrive at ε = d·qv

2103 .

IV. PSEUDO-RANDOM FUNCTIONS FOR AEAD

We now consider the use of symmetric ciphers in countermode, both for keying one-time MACs and for generatingone-time pads for encryption. We model ciphers as PRFs.For TLS, we will use AES or ChaCha20, and discussPRF/PRP issues in §VII. A pseudo-random function family

PRF implements the following interface:type keyval keygen: unit → ST keyval `d : nat (∗ fixed domain length ∗)val `b : nat (∗ fixed block length ∗)type domain = lbytes `dtype block = lbytes `bval eval: key → domain → Tot block (∗ functional specification ∗)

This interface specifies an abstract type for keys and a key-generation algorithm. (Type abstraction ensures that thesekeys are used only for PRF computations.) It also specifiesconcrete, fixed-length bytestrings for the domain and rangeof the PRF, and a function to compute the PRF. We refer tothe PRF outputs as blocks. As usual, we define security asindistinguishability from a uniformly random function withlazy sampling.

Definition 4 (PRF security): Let εPrf(A[qb]) be the ad-vantage of an adversary A that makes qb Eval queries inthe game:

Game Prfb(PRF)T ← ∅k

$← PRF.keygen()return {Eval}

Oracle Eval(m)if T [m] = ⊥if b then T [m]

$← byte`b

else T [m]← PRF.eval(k,m)return T [m]

The AEAD constructions we consider use PRFs both togenerate keys for the one-time MAC used to authenticate theciphertext and to generate a one-time pad for encryption anddecryption. Accordingly, we partition the domain and use aspecialized security definition, with a separate eval functionfor each usage of the PRF. (This will enable us to give moreprecise types to each of these functions.)

We assume the PRF domain consists of concatenationsof a fixed-sized counter j and a nonce n, written j‖n. Thisnotation hides minor differences between AEAD algorithmspecifications, e.g. AES-GCM uses n‖j instead j‖n. Ourimplementation handles these details, and verifies that j‖nis injective for all admissible values of j and n.

For key generation, AES-GCM uses the PRF to deriveboth a static MAC key k0 generated from the PRF (withnonce and counter 0) and a 1-time MAC key for eachnonce (with counter 1) whereas Poly1305 uses a pure 1-time MAC key for each nonce (with counter 0). To handleboth cases uniformly, we introduce a parameter j0 ∈ {0, 1}to shift the counter before concatenation with the nonce. Inthe following, we assume a compatible MAC, meaning thateither j0 = 0 ∧ `k0 = 0 ∧ `k ≤ `b or j0 = 1 ∧ `k0 ≤ `b ∧`k − `k0 ≤ `b.

For pad generation, counter mode encrypts plaintextblocks as p⊕ eval(j‖n) and decrypts by applying the samepad to the ciphertext. In the PrfCtr game below, we separateencryption and decryption, and we fuse the block generationand the XOR, so that we can give separate types to plaintextsand ciphertexts. (We truncate the block in case it is smaller

than the input, as required for the last block in counter-mode.)

Definition 5 (PrfCtr security): Given PRF and MAC, letεPrfCtr(A[qb, qg]) be the advantage of an adversary A thatmakes qb queries to either EvalEnx or EvalDex and qg queriesto EvalKey in the following game:

Game PrfCtrb(PRF,MAC)T ← ∅; R← ∅k

$← PRF.keygen()

k0$← MAC.keygen0()

if j0 ∧ ¬bo← PRF.eval(k, 0`b)k0 ← truncate(o,MAC.`k0)

return {EvalKey,EvalEnx,EvalDex}

Oracle EvalKey(j‖n)if j 6= j0 return ⊥if T [j‖n] = ⊥

if b

km$← MAC.keygen(k0)

elseo← PRF.eval(k, j‖n)km ← truncate(k0‖o, `k)

T [j‖n]← kmreturn T [j‖n]

Oracle EvalEnx(j‖n, p)if j ≤ j0 return ⊥o

$← Eval(j‖n)c← p⊕ truncate(o, |p|)return c

Oracle EvalDex(j‖n, c)if j ≤ j0 return ⊥o

$← Eval(j‖n)p← c⊕ truncate(o, |c|)return p

Lemma 3 (PrfCtrb reduces to Prfb): Given PRF, MAC,and A against PrfCtrb(PRF,MAC), we construct B againstPrfb(PRF) such that:

εPrfCtr(A[qb, qg]) = εPrf(B[qb + qg + j0]).

The proof is in the full paper. Intuitively, we have aperfect reduction because, in all cases, the specialized gamestill samples a single fresh block for each j‖n for a singlepurpose, and returns a value computed from that block.

In the next section, once b holds and the MAC hasbeen idealized, we will use two oracles that further idealizeencryption and decryption:

Oracle EvalEnx′(j‖n, p)if j ≤ j0 return ⊥if T [j‖n] 6= ⊥ return ⊥if b′ c

$← byte|p|

else c$← EvalEnx(j‖n, p)

T [j‖n]← (p, c)return c

Oracle EvalDex′(j‖n, c)if j ≤ j0 return ⊥if T [j‖n] = (p, c) for some p

return pelse return ⊥

When b′ holds, encryption samples c instead of o = p ⊕ c,and records the pair (p, c) instead of just p ⊕ c; anddecryption simply performs a table lookup. This step is validprovided the block at j‖n is used for encrypting a single pand decrypting the resulting c. The oracles enforce thisrestriction dynamically (on their second lines) whereas ourcode enforces it statically, using type-based preconditions onEvalEnx or EvalDex implied by the AEAD invariant of §V.

Verified Implementation Lemma 3 and the subsequent stepare not currently verified by typing. (Still, note that thesampling of c instead of o is justified by F?’s probabilisticsemantic and could be verified using the relational typingrule for sample in RF? [4])

We use an idealized PRF module with two idealizationflags (for b and for b′) that directly corresponds to thespecialized game PrfCtrb,b

′parametrized by a Cipher mod-

ule that implements real AES128, AES256, and ChaCha20(depending on an algorithmic parameter alg) and by a MACmodule. The separation of the PRF domain is enforced bytyping: depending on alg , j0, j, b, and b′, its range includeskeys, blocks, and pairs (p, c).

V. FROM MAC AND PRF TO AEAD

We implement the two main AEAD constructions usedby TLS 1.3 and modern ciphersuites of TLS 1.2. We showthat their composition of a PRF and a one-time MAC yieldsa standard notion of AEAD security. Our proof is genericand carefully designed to be modular and TLS-agnostic: weshare our AEAD code between TLS 1.2 and 1.3, and planto generalize it for other protocols such as QUIC.

AEAD functionality Our authenticated encryption withassociated data (AEAD) has a real interface of the formval `n: nat (∗ fixed nonce length ∗)val `a: n:nat{n < 232} (∗ maximal AD length ∗)val `p: n:nat{n < 232} (∗ maximal plaintext length ∗)val cipherlen: n:nat{n ≤ `p} → Tot nattype nonce = lbytes `ntype ad = bbytes `atype plain = bbytes `ptype cipher = bytes

val decrypt: key → nonce → ad → c:cipher →ST (option (p:plain{length c = cipherlen (length p)}))

val encrypt: k:key → n:nonce → a:ad → p:plain →ST (c:cipher{length c = cipherlen (length p))

with two functions to encrypt and decrypt messages withassociated data of variable lengths, and types that specifythe cipher length as a function of the plain length. (We omitdeclarations for keys, similar to those for PRFs in §IV.)

Definition 6 (Aead security): Let εAead(A[qe, qd, `p, `a])be the advantage of an adversary that makes at most qeEncrypt and qd Decrypt queries on messages and associateddata of lengths at most `p and `a in the game:

Game Aeadb(AEAD)C ← ∅k

$← AEAD.keygen()return {Encrypt,Decrypt}

Oracle Encrypt(n, a, p)if C[n] 6= ⊥ return ⊥if b c

$← bytecipherlen(|p|)

else c← AEAD.encrypt(k, n, a, p)C[n]← (a, p, c)return c

Oracle Decrypt(n, a, c)if b

if C[n] = (a, p, c) for some preturn p

return ⊥elsep← AEAD.decrypt(k, n, a, c)return p

Our definition generalizes AE in §II; it has a richer do-main with plaintext and associated data of variable lengths;a function cipherlen from plaintext lengths to ciphertextlengths; and nonces n. It similarly maintains a log of

encryptions, indexed by nonces. Crucially, Encrypt uses thelog to ensure that each nonce is used at most once forencryption.

Generic AEAD Construction Given a PRF and a compat-ible MAC, AEAD splits plaintexts into blocks which arethen blinded by pseudo-random one-time pads generatedby calling PRF on increasing counter values, as shownin §IV. (Blocks for MAC keys and the last mask may requiretruncation.)

To authenticate the ciphertext and associated data, theconstruction formats them into a single 16-byte-alignedbuffer (ready to be hashed as polynomial coefficients asdescribed in §III) using an encoding function declaredas val encode: bbytes `p × bbytes `a → Tot bbytes (`p + `a + 46)and implemented (in pseudo-code) as

Function encode(c, a)return pad16(a) ‖ pad16(c)‖ length8(a) ‖ length8(c)

Function pad16(b)r, b1, . . . , br ← split16(b)return b ‖ zeros(16− |br|)

where the auxiliary function split`(b) splits the bytestring binto a sequence of r non-empty bytestrings, all of size `,except for the last one which may be shorter. (that is,if r, b1, . . . br ← splitb(`), then b = b1 ‖ · · · ‖ br.); wherezeros(`) is the bytestring of ` zero bytes; and wherelength8(n) is the 8-byte representation of the length of n.Thus, our encoding adds minimal zero-padding to a and c,so that they are both 16-bytes aligned, and appends a final16-byte encoding of their lengths.

Recall that the domain of MAC messages is re-stricted by the wellformed predicate. We now definewellformed b = ∃ (c:cipher) (a:ad). b = encode c a and typecheckthe property listed in §III that ensures injectivity of thepolynomial encoding.

The rest of the AEAD construction is defined below,using an operator otp⊕ p that abbreviates the expressiontruncate(otp, |p|)⊕p, and a function untag16 that separatesthe ciphertext from the tag.

Function keygen()

k$← PRF.keygen(); k0 ← ε

if j0o← PRF.eval(k, 0`b )k0 ← truncate(o,MAC.`k0

)return k0‖k

Function encrypt(K,n, a, p)(k0, k)← split`k0

(K); c← ε

k1 ← PRF.eval(k, j0‖n)km ← truncate(k0‖k1,MAC.`k)r, p1, . . . , pr ← split`b (p);for j = 1..r

otp← PRF.eval(k, j0 + j‖n)c← c ‖(otp⊕ pj)

t← MAC.mac(km, encode(c, a))return c‖t

Function decrypt(K,n, a, c)(k0, k)← split`k0

(K); p← ε

k1 ← PRF.eval(k, j0‖n)km ← truncate(k0‖k1,MAC.`k)(c, t)← untag16(c)m← encode(c, a)if ¬MAC.verify(km,m, t)

return ⊥r, c1, . . . , cr ← split`b (c);for j = 1..r

otp← PRF.eval(k, j0 + j‖n)p← p ‖(otp⊕ cj)

return p

The main result of this section is that it is Aead-securewhen PRF is Prf-secure and MAC is MMac1-secure:

Theorem 2 (AEAD construction): Given A against Aead,we construct B against Prf and C against MMac1, with:

εAead(AEAD)(A[qe, qd, `p, `a]) ≤ εPrf(PRF)(B[qb])+ εMMac1(MAC)(C[`p + `a + 46, qd, qe + qd])

where qb (the number of distinct queries to the PRF)satisfies:

qb ≤ j0 + qe

(1 +

⌈`p`b

⌉)+ qd

Proof sketch: The proof is in the full paper; it relieson the PrfCtrb,b

′and MMac1b idealizations; it involves a

sequence of transformations from Aead0 to Aead1 that inlinesuccessively more idealizations. Therefore, we introduce aparametric game AeadCtr(X) for any game X that returnsEvalKey, EvalEnx, EvalDex, Mac, and Verify oracles:

Game AeadCtr(X)(EvalKey,EvalEnx,EvalDex,Mac,Verify)← X()return {Encrypt,Decrypt}

Oracle Encrypt(n, a, p)if C[n] 6= ⊥ return ⊥EvalKey(n); c← εr, p1, . . . , pr ← split`b (p)for j = 1..r

c← c ‖EvalEnx(j0 + j‖n, pj)c← c ‖Mac(n, encode(c, a))C[n]← (a, p, c)return c

Oracle Decrypt(n, a, c)c, t← untag16(c)EvalKey(n)if ¬Verify(n, encode(c, a), t)

return ⊥r, c1, . . . , cr ← split`b (c); p←εfor j = 1 . . . r

p← p ‖EvalDex(j0 + j‖n, cj)return p

When X is obtained from PrfCtr0 and MMac10 we have agame that is equivalent to Aead0. We first switch to PrfCtr1

to get random MAC keys and then idealize MMac11. WhenX is obtained from PrfCtr1 and MMac11 ciphertexts areauthenticated and we can switch to PrfCtr1,0 and then toPrfCtr1,1. At this stage the PRF table contains randomlysampled ciphertext blocks and decryption corresponds totable lookup in this table. This is ensured on the code byour AEAD invariant.

Verified Implementation We outline below the idealizedinterface of our main AEADb module built on top of (theidealized interfaces of) PrfCtrb,b

′and MMac1b, both taken

as cryptographic assumption, and documented by the gameswith the same names on paper. We focus on types forencryption and decryption:

abstract type key (∗ stateful key, now containing the log ∗)val log: memory → key →

Spec (seq (nonce × ad × cipher × plain)val keygen : unit → ST (k:key)

(ensures b ⇒ log k = ∅)val encrypt: k:key → n:nonce → a:ad → p:plain → ST (c:cipher)

(requires b ⇒ lookup_nonce n (log k) = None)(ensures (b ⇒ log k′ = log k ++ (n,a,c,p)))

val decrypt: k:key → n:nonce → a:ad → c:cipher →ST (o:option plain)(ensures b ⇒ o = lookup (n,a,c) (log k))

As in §II, we have a multi-instance idealization, with a logfor each instance stored within an abstract, stateful key; andwe provide a proof-only function log to access its currentcontents in logical specifications. Hence, key generationallocates an empty log for the instance; encryption requiresthat the nonce be fresh and records its results; and decryptionbehaves exactly as a table lookup, returning a plaintext if,and only if, it was previously stored in the log by callingencryption with the same nonce and additional data.

This step of the construction is entirely verifiable bytyping. To this end, we supplement its implementation with aprecise invariant that relates the AEAD log to the underlyingPRF table and MAC logs. For each entry in the log, wespecify the corresponding entries in the PRF table (one forthe one-time MAC key, and one for each block requiredfor encryption) and, for each one-time MAC key entry, thecontents of the MAC log (an encoded message and the tagat the end of the ciphertext in the AEAD log entry). Bytyping the AEAD code that implements the construction,we verify that the invariant is preserved as it completes itsseries of calls to the PRF and MAC idealized interfaces.Hence, although our code for decryption does not actuallydecrypt by a log lookup, we prove that (when b holds) itsresults always matches the result of a lookup on the currentlog. As usual, by setting all idealization flags to false, theverified code yields our concrete TLS implementation.

Security bounds Theorem 2 can be specialized to provideprecise security bounds for the various AEAD ciphersuites:

Construction εAead(A[qe, qd, `p, `a]) ≤AES128-GCM,AES256-GCM

εPrf

(B[qe

(1 +

`p16

)+ qd + 1

])+ qd

2128 ·(`p+`a+46

16

)ChaCha20-Poly1305

εPrf

(B[qe

(1 +

`p64

)+ qd

])+ qd

2103 ·(`p+`a+46

16

)VI. FROM AEAD TO STREAM ENCRYPTION (STAE)

TLS requires stream encryption: message fragments mustbe received and processed in the order they were sent,thereby defeating attempts to delete or re-order networktraffic. To this end, encryption and decryption use a localsequence number to generate distinct, ordered nonces forAEAD.

In practice, it is difficult to prevent multiple honest serversfrom decrypting and processing the same 0-RTT encryptedstream. Since decryption is now stateful, we must generalizeour model to support multiple parallel decryptors for eachencryptor. In our security definitions, we thus add a genDoracle to generate new decryptors (with local sequencenumbers set to zero) from a given encryptor.

Otherwise, the stateful construction is quite simple: TLS1.3 combines the sequence number with a static, random‘initialization vector’ (IV) in the key materials to gener-ate pairwise-distinct nonces for encrypting fragments usingAEAD. In contrast, TLS 1.2 nonces concatenate the staticIV with a per-fragment explicit IV that is sent alongsidethe ciphertext on the network (except for ciphersuites basedon ChaCha20-Poly1305 which follow the TLS 1.3 nonceformat). Some TLS 1.2 implementations incorrectly useuniformly random explicit IVs [15]. This is much inferiorto using the sequence number because of the high collisionrisk on 64 bits. Therefore, in our implementation, we usethe following nonce construction:

n =

{bigEndian8(seqn) ‖ iv4 for AES-GCM in TLS 1.2bigEndian12(seqn)⊕ iv12 otherwise

where the indices indicate lengths in bytes. The use oflonger static IVs in TLS 1.3 is a practical improvement, as(informally) it acts as an auxiliary secret input to the PRFand may improve multi-user security [7]. This is particularlyclear for ChaCha20, where the key, nonce, and counter arejust copied side by side to the initial cipher state.

We easily verify (by typing) that both constructions areinjective for 0 ≤ seqn < 264, which is required (also bytyping) to meet the ‘fresh nonce’ pre-condition for callingAEAD encryption. Formally, the state invariant for StAEencryption is that 0 ≤ seqn < 264 and the underlyingAEAD log has an entry for every nonce n computed froma sequence number smaller than seqn.

StAE functionality A stream authenticated encryptionfunctionality StAE implements the following interface:type seqn_t = UInt64.tval qe: seqn_t (∗ maximal number of encryptions ∗)val cipherlen: n:nat{ n ≤ `p } → Tot nat (∗ e.g. `p + MAC.`t ∗)

type role = E | Dabstract type state (r:role)val seqn: mem → state r → Spec seqn_tval gen: unit → ST (s:state E) (ensures seqn s′ = 0)val genD: state E → ST (s:state D) (ensures seqn s′ = 0)val encrypt: s:state E → ad → p:plain →

ST (c:cipher{length c = cipherlen (length p))(requires seqn s < qe) (ensures seqn s′ = seqn s + 1)

val decrypt: s:state D → ad → c:cipher →ST (o:option (p:plain{length c = cipherlen (length p)}))(requires seqn s < qe)(ensures seqn s′ = if o = None then seqn s else seqn s + 1)

We omit type declarations for plain, cipher and ad as theyare similar to AEAD. For TLS, the length of additionaldata `a can be 0 (TLS 1.3) or 13 (TLS 1.2) and the lengthof IVs `iv is 12. Compared to previous functionalities, themain change is that keys are replaced by states that embeda 64-bit sequence number. Accordingly, in this section weassume that at most 264 fragments are encrypted. Thestateful function gen initializes the encryptor state used bythe encryption algorithm, while genD initializes a decryptor

state used by the decryption algorithm. The stateful encryptand decrypt functions require that the sequence number inthe key state does not overflow (seqn s < qe) and ensure that itis incremented (only on success in the case of decryption). Inpseudo-code, authenticated stream encryption is constructedas follows:

Function gen()

k$← AEAD.keygen()

iv$← byte`iv

return {k ← k;iv ← iv; seqn← 0}

Function genD(s)return {k ← s.k;

iv ← s.iv; seqn← 0}

Function encrypt(s, a, p)n← nonce(s.iv, s.seqn)

c$← AEAD.encrypt(s.k, n, a, p)

s.seqn← s.seqn+ 1return c

Function decrypt(s, a, c)n← nonce(s.iv, s.seqn)p← AEAD.decrypt(s.k, n, a, c)if (p = ⊥) return ⊥s.seqn← s.seqn+ 1return p

Definition 7 (Stae): Let εStae(A[qe, qd, `p, `a]) be the ad-vantage of an adversary A that makes qe encryption queriesand qd decryption queries in the game below.

Game Staeb(StAE)

s$← StAE.gen()

D ← ∅ E ← ∅return {GenD,Encrypt,

Decrypt}

Oracle GenD(d)if (D[d] 6= ⊥) return ⊥D[d]← StAE.genD(s)

Oracle Encrypt(a, p)if b

c← bytecipherlen(|p|)

elsec← StAE.encrypt(s, a, p)

E[s.seqn− 1, a, c]← preturn c

Oracle Decrypt(d, a, c)if (D[d] = ⊥) return ⊥if bp← E[D[d].seqn, a, c]if (p 6= ⊥)D[d].seqn← D[d].seqn+ 1

elsep← StAE.decrypt(D[d], a, c)

return p

The game involves a single encryptor, a table of decryp-tors D, and a log of encryptions E. For brevity, it relieson the stateful encryptor and decryptors specified above,e.g. encrypts increments s.seqn and Encrypt records theencryption with sequence number s.seqn−1. (Equivalently,it could keep its own shadow copies of the sequence num-bers.) In contrast with AEAD, decryption only succeeds forthe current sequence number of the decryptor.

Our definition corresponds most closely to level-4 (state-ful) LHAE of [16]. In both definitions the requirement isthat decrypt only successfully decrypted a prefix of what wassent. A difference is that we do not require real decryptionto continue rejecting ciphertexts upon decryption failure. Wealso leave length-hiding and stream termination to §VII.

Theorem 3 (Stae perfectly reduces to Aead): GivenA against Stae, we construct B against Aead with

εStae(A[qe, qd, `p, `a]) = εAead(B[qe, qd, `p, `a]).

Figure 3. Constructing a TLS 1.3 record fragment

VII. TLS CONTENT PROTECTION: LENGTH-HIDINGSTREAM ENCRYPTION

We are now ready to use stream encryption for protectingTLS 1.3 traffic, which consists of a sequence of protocol-message fragments, each tagged with their content type,while hiding their content, their type, and their actual sizebefore padding. The steps taken by the record layer toconstruct encrypted fragments are depicted in Figure 3,with apparent size ` after padding. The last line adds the(unprotected) record header; for backward compatibility, itpretends to be a TLS 1.0 AppData record irrespective of itsactual encrypted content type. On the other hand, TLS doesnot attempt to hide the record boundaries (as e.g. SSH) sowe do not expect indistinguishability from random for theresulting record.

Formatting: Content Type and Length Hiding Encryp-tion and decryption rely on formatting and padding functionsover a type fragment indexed by a length ` indicating thepublic maximal length of its content, specified as follows:

type len = n:nat {n ≤ 214} (∗ valid record length in TLS ∗)type fragment (`:len) = {ct:byte; data:bbytes `}val parse: `:len → lbytes (`+1) → Tot (option (fragment `))val format: `:len → f:fragment ` → Tot (p:lbytes (`+1))

(ensures parse ` p = Some f)

These functions must be carefully implemented to preventany side channel. We also construct and parse records intoheaders and payloads using functions

val parse_record: r:record → Tot (option (n:nat × c:lbytes n))val format_record: n:nat → c:lbytes n → Tot (r:record)

(ensures parse_record r = Some (n,c))

These function specifications suffice to establish our theo-rems below. We now give the concrete format function forTLS 1.3:

Function format(` : len, f : fragment `)f.data ‖[f.ct] ‖ pad0(`− |f.data|)

where pad0 n is the string of n 0x00 bytes. We verify thepost-condition of format by typing. We omit the correspond-ing parse function and the code for processing headers.

The implementation of parse and format, and the conversefunction for parsing a bytestring into a fragment value, requireprecautions to avoid leaking the actual contents length usingside-channels. The code for processing headers does notdepend on the fragment, only on its length after padding.

Stream Closure As explained in §VI, stream integrityensures that decrypted traffic is a prefix of encryptedtraffic. Complementarily, the TLS record layer relieson well-defined final fragments, specified as a predicateval final: fragment ` → Tot bool, to ensure that no further en-cryptions are performed on a stream after sending such afragment.

For LHAE, we extend the stateful key of StAE to recordthe termination status of the stream, which can be queriedwith the predicate val closed: mem → state r → Spec bool.Furthermore, we extend the post-condition of encryption toensure that the state s′ after encrypting fragment f satisfiesclosed s′ = final f. Therefore, upon receiving a final fragment,the decryptor is guaranteed to have received the whole datastream.LHSE Construction and Game The construction is:

Function encrypt(s, `, f)if closed(s) return ⊥p← format(`, f)c← StAE.encrypt(s, [], p)if (final f) s← closedreturn format_record(`, c)

Function decrypt(s, r)if closed(s) return ⊥`, c← parse_record(v)p← StAE.decrypt(s, [], c)f ← parse(`, p)if (f 6= ⊥ ∧ final f) s← closedreturn f

with the same state as StAE—we omit the unmodifiedfunctions for generating encryptors and decryptors. When afinal fragment is sent or received, we erase the StAE state.

The TLS 1.3 construction uses empty associated data,relying on implicit authentication of the underlying key andsequence number. (Our code also supports the older TLS 1.2construction, which uses 13 bytes of associated data in total,obtained by appending the protocol version and the contenttype to the sequence number of stream encryption.)

Definition 8 (Lhse): Given LHSE, let εLhse(A[qe, qd]) bethe advantage of an adversary A that makes qe encryptionqueries and qd decryption queries in the game below.

Game Lhseb(LHSE)

s$← Lhse.gen()

D ← ∅; F ← ∅return {GenD,Encrypt,Decrypt}

Oracle GenD(d)if (D[d] = ⊥)

D[d]← LHSE.genD(s)

Oracle Encrypt(`, f)if b

r ← LHSE.encrypt(s, `, ffinal(f))else

r ← LHSE.encrypt(s, `, f)F [s.seqn− 1, r]← freturn v

Oracle Decrypt(d, v)if (D[d] = ⊥) return ⊥sd ← D[d]if b

if closed(sd) return ⊥f ← F [sd.seqn, r]if (f 6= ⊥) sd.seqn++if (f 6= ⊥ ∧ final f)

sd ← closedelse

f ← LHSE.decrypt(sd, v)return f

where f0 (respectively, f1) is a fragment (respectively, a finalfragment), with fixed content type and data 0`.

The game logs the encryption stream in F , indexed byfragment sequence numbers and ciphertexts. It has an oraclefor creating decryptors; it stores their state in a table D,indexed by some abstract d chosen by the adversary. It doesnot model stream termination, enforced purely by typing thestream content.

Theorem 4 (Lhse perfectly reduces to Stae):Given A against Stae, we construct B against Aead with

εLhse(A[qe, qd]) = εStae(B[qe, qd, 214 + 1, `a])

where `a is 0 for TLS 1.3 and 13 for TLS 1.2.

Multi-Stream LHSE In the next section (as in our interfaceabove), we use a multi-instance Lhse game, defined below.

Game Multi(Lhseb)E ← ∅; return {Gen,GenD,Encrypt,Decrypt}

Oracle Gen(i)

if (E[i] = ⊥) E[i]$← Lhseb()

Oracle GenD(i, d)

if (E[i] = ⊥) E[i]$← Lhseb()

E[i].GenD(d)

Oracle Encrypt(i, `, f)if (E[i] = ⊥) return ⊥return E[i].Encrypt(`, f)

Oracle Decrypt(i, d, v)if (E[i] = ⊥) return ⊥return E[i].Decrypt(d, v)

For every fresh index i passed to Gen, we spawn an instanceof Lhse and we record its state and oracle in table E. Inall other cases, the oracles above now look up the sharedinstance at i and forward the call to the instance oracle.

Security bounds for TLS Table I gives the concrete boundsby ciphersuites, setting `p to 214 + 1 and `a to 0 (or 13for TLS 1.2). ChaCha20 uses a Davies-Meyer constructionand is considered a good PRF. For AES-GCM ciphersuites,blocks are relatively small (16 bytes) so we incur a lossof q2b

2129 by the PRP/PRF switching lemma [6], intuitivelyaccounting for the probability of observing collisions onciphertext blocks and inferring the corresponding plaintextblocks are different. As observed e.g. by Luykx and Paterson[34], this factor limits the amount of data that can be sentsecurely using AES-GCM.

Based on their suggestion to send at most 224.5 fragmentswith the same key (itself based on a proof by [9] for theUF-1CMA security of GHASH that avoids the full PRF-PRP switching loss), our implementation may automaticallytrigger TLS re-keying after sending 224.5 fragments. Thisstrategy results in the bound in the last row, which no longerdepends quadratically on qe and thus achieves a poor man’sform of beyond birthday bound security.

VIII. THE TLS 1.3 RECORD PROTOCOL

Figure 4 presents the TLS 1.3 protocol from draft-19,focusing only on how it drives the record layer. In par-ticular, this presentation ignores most of the details of the

Ciphersuite εLhse(A[qe, qd]) ≤General bound εPrf(B[qe(1 + d(214 + 1)/`be) + qd + j0])

+ εMMac1(C[214 + 1 + 46, qd, qe + qd])

ChaCha20-Poly1305

εPrf(B[qe(1 +

⌈(214+1)

64

⌉)+ qd

]) + qd

293

AES128-GCMAES256-GCM

εPrp(B[qb]) + q2b2129

+ qd2118

where qb = qe(1 + d(214 + 1)/16e) + qd + 1AES128-GCMAES128-GCM

qe224.5

(εPrp(B

[234.5

]) + 1

260+ 1

256

)with re-keying every 224.5 records (countingqe for all streams, and qd ≤ 260 per stream)

Table ISUMMARY OF SECURITY BOUNDS FOR THE TLS AEAD CIPHERSUITES.

handshake. Figure 1 in Section I illustrates the sub-protocolstreams from the point of view of the client.

The client sends the ClientHello message in cleartext,and may then immediately install a fresh 0-RTT key kc0 inthe record layer and use it to encrypt a stream of early data.

The server receives this message and, if it accepts 0-RTT,also installs the 0-RTT key kc0 and decrypts the client’s data.Otherwise, it discards this first stream. In parallel, the serversends a ServerHello message that allows both partiesto derive encryption keys kch and ksh for the handshakemessages, and kc1 and ks1 for application data. The serverinstalls ksh in the record and uses it to encrypt a first streamof handshake messages, ending with a finished message thattriggers the installation of key ks1. If the server supports0.5-RTT, it may immediately start using ks1 for sendingapplication data.

Once 0-RTT stream is complete (signaled by anend-of-early-data message) and after processing theServerHello, the client installs the handshake keys kchand ksh for encryption and decryption. It completes thehandshake by sending its own encrypted stream, ending witha finished message, and installs the application traffic keyskc1 and ks1.

Upon completing the handshake, the server also installskc1 for decryption. After this point, the connection is fullyestablished and both parties use the installed applicationtraffic keys for all content types: AppData, Alert, and evenHandshake messages (such as KeyUpdate).

Later, the client (or the server) can terminate their currentoutput stream by sending either a KeyUpdate handshakemessage or a close-notify alert message. In the first case,it installs and starts using the next application traffic keykc2 (then kc3, etc.). The server (or the client) respondsaccordingly, with a KeyUpdate or a close-notify. In thefirst case, it installs and starts using the next traffic keys kc2and ks2. In the second case, the connection is closed.

In all cases, each party uses a single stream at a time ineach direction, for sending and receiving all content types,and each stream ends with a distinguished message that

ClientC ServerS

Knows skC , psk Knows skS , psk

log0 log0

ClientHello(nC , gx, a0, . . .)

0-RTT Keys (encrypt-only):kc0 = kdf(psk , log0)

0-RTT Keys (decrypt-only):kc0 = kdf(psk , log0)

enckc0(Data(m0))

enckc0(EndOfEarlyData)log1 log1

ServerHello(nS , gy, a1, . . .)

Handshake Keys:kch, k

sh = kdf(psk , gxy, log1)

Handshake Keys:kch, k

sh = kdf(psk , gxy, log1)

log2 log2

encksh(ServerCert-Finished(certS , . . .))

0.5/1-RTT Traffic Keys:kc1, k

s1 = kdf(psk , gxy, log2)

0.5/1-RTT Traffic Keys:kc1, k

s1 = kdf(psk , gxy, log2)

encks1(Data(m0.5))

enckch(ClientCert-Finished(certC , . . .))

Handshake Complete Handshake Completeenck

c1(Data(m1))

encks1(Data(m2))

enckc1(KeyUpdate)

Update Keys (C → S):kc2 = kdf(kc1)

Update Keys (C → S):kc2 = kdf(kc1)

enckc2(Data(m3))

encks1(Data(m4))

enckc2(Alert(close_notify))

encks1(Alert(close_notify))

Duplex Data Stream:C → S : m0,m1,m3

S → C : m0.5,m2,m4

Duplex Data Stream:C → S : m0,m1,m3

S → C : m0.5,m2,m4

Figure 4. TLS 1.3 draft-19 message exchange, seen from the viewpointof the Record Protocol. Dotted arrows represent zero or more (encrypted)application data fragments. Each key stands for an instance of LHSE.

clearly indicates its final fragment. 0-RTT data ends with anend-of-early-data message; encrypted handshake messagesin both directions end with the finished message; 0.5 and1-RTT data streams end with a key update or a close-notifyalert. This precaution ensures that any truncations at theend of a stream will cause a connection failure, rather thancontinuing with the next stream.

Performance/Security Trade-Offs. 0-RTT and 0.5-RTTsignificantly decrease communications latency, but theyyield weaker application security. 0-RTT traffic has weakerforward secrecy and is subject to replays: if multiple serversmay accept the connection and (as usual) do not share ananti-replay cache, then they may all receive and process(prefixes of) the same early traffic data. This motivates ourmodel with multiple decryptors, and also requires the serverapplication to defer some effects of early-data processingtill handshake completion. Also, since data is sent beforeciphersuite negotiation, the client may use relatively weak al-

gorithms (or broken implementations) that the server wouldotherwise have a chance to refuse.

0.5-RTT incurs similar, lesser risks as the server sendsdata before the handshake completes. The server is subjectto 0-RTT truncation attacks if it starts sending data beforereceiving the client’s end of early data. Also, if the serverrelies on a client signature, it should not send sensitivedata before handshake completion. In contrast with 0-RTT,sending 0.5-RTT traffic is a local configuration issue for theserver; the client receives 0.5-RTT data after completing thehandshake and does not distinguish it from 1-RTT data.

TLS 1.2 is routinely deployed with ‘FalseStart’, whichis similar to 0.5-RTT but in the other direction, the clientmay locally decide to start sending encrypted applicationdata as soon as it can compute the keys, before handshakecompletion. This places additional trust in the client’s ci-phersuite whitelist, inasmuch as sensitive data may be sentbefore confirming their correct negotiation with the server.

A Minimal Record Game Next, we present a simplified,more liberal model of the Record that seeks to abstractaway from the details of how the connection evolves.This facilitates the statement of a standalone ‘record-layer’theorem, but our approach similarly applies to our fullF? implementation integrated with miTLS, which carefullykeeps track of the sequence of keys, as outlined at the endof this section.

We abstract the state of the connection by a contextbitstring; as the handshake progresses, we concatenate morerelevant handshake parameters to the context. For instance,after ClientHello, the context consists of the client’snonce nC and its proposed ciphersuites and key exchangevalues; after ServerHello, it additionally contains theserver nonce nS , algorithm choice, key exchange value, etc.

Instead of modeling duplex channels between clients andservers, we consider separate sequences of streams in eachdirection. Our game (Figure 5) models re-keying and contextextension for a sequence of streams (all in the same direc-tion), covering 0-RTT, 0.5-RTT, and 1-RTT traffic, relyingon the multi-instance game SE = Multi(Lhse) (see §VII).

The game has oracles Init and InitD for generating multi-stream encryptors and decryptors in their initial state, in-dexed by n and m, respectively. We assume that their ar-guments determine the record algorithm. Their state consistof a current context, a current stream number j, and a localmap I from stream numbers to the value of the context whenthey were installed. We use variables ctx, j, and I to referto the fields of E[m] and D[n], respectively.

Oracles Extend and ExtendD allow the local context to beextended (concatenated) with new information at any time.

Oracles Install and InstallD install an LHSE instance (al-locating it if it does not exist) for encryption and decryption,

Game Recordb(Lhseb(LHSE))E ← ∅ D ← ∅SE.Gen, SE.GenD, SE.Encrypt,SE.Decrypt

$← Multi(Lhseb)return {Gen,Extend, Install,Encrypt,

GenD,ExtendD, InstallD,Decrypt}

Oracle Init(n)if E[n] = ⊥E[n]← {ctx← n; j ← 0;

I ← ∅}

Oracle InitD(m, ctx0)if D[m] = ⊥D[m]← {ctx← ctx0;

j ← 0; I ← ∅}

Oracle Extend(n, δ)if E[n] existsctx← ctx+ δ

Oracle ExtendD(m, δ)if D[m] existsctx← ctx+ δ

Oracle Install(n)if E[n] exists with I[j] = ⊥I[j]← (ctx, j)SE.Gen(I[j])

Oracle InstallD(m)if D[m] exists with I[j] = ⊥I[j]← (ctx, j)SE.GenD(I[j])

Oracle Encrypt(n, `, f)if E[n] exists with I[j] 6= ⊥v ← SE.Encrypt(I[j], `, f)if (final f) j ← j + 1return v

Oracle Decrypt(m, v)if D[m] exists with I[j] 6= ⊥f ← SE.Decrypt(I[j], d, v)if f 6= ⊥ ∧ final fj ← j + 1

return f

Figure 5. The TLS 1.3 Record Game

respectively. Recall that calls to SE.Gen are memoized, sothat an encryptor and a decryptor share the same stream ifand only if they agree on the stream sequence number andcontext.

Oracles Encrypt and Decrypt apply encryption and de-cryption to the currently-installed stream. Some fragmentsare final: they terminate the stream and signal the need toinstall a new stream before continuing.

Definition 9 (Record): Let εRecord(A[qe, qd, qi]) be theadvantage of an adversary A that makes at most qe encryp-tion queries and qd decryption queries for each of the qiLHSE instances created using install queries in the game ofFigure 5.

Theorem 5 (Record reduces to Lhse):

εRecord(A[qe, qd, qi]) ≤ qi εLhse(B[qe, qd]).

Our game complies with the idealized interface for LHSEand relies on its conditional idealization. If b = 0, thenthe oracles operate purely on local state, and simply im-plement a real sequence of encrypted streams, under thecontrol of the record state machine. If b = 1, then weget perfect authentication of (a prefix of) the whole se-quence of streams of fragments. (This property is verifiedby typing our idealized record implementation.) The ctxfield of encryptors and decryptor represents their implicitlyauthenticated shared context: unless there is an encryptorwith a matching context, the ideal encryption log is emptyhence decryption will fail. In particular, as soon as the

context includes ServerCert-Finished, and thus thefresh TLS nonces nC and nS , we know that there is at mostone encryptor and one decryptor.

More precisely, consider encryptor and decryptor statesE[n] and D[m]. If E[n].I[j] = D[m].I[j] then alsoE[n].I[j′] = D[m].I[j′] for any j′ < j. Thus, for instance,when D[m] receives a final fragment, we know that E[n]and D[m] agree on the whole sequence of communicatedfragment for the first j streams. By Theorem 5 these guaran-tees also hold for the real record for any game adversary A,except with probability εRecord(A).

Application to 0-RTT We briefly show how to controlour game to model 0-RTT and 0.5-RTT. For 0-RTT, theclient is the encryptor and the server is the decryptor. Bothuse the encryptor index n as initial context, representingthe content of ClientHello, notably the fresh clientrandom nC . Conversely, the decryptor index m (includingthe fresh server random nS) is not included in the initialcontext of InitD. As both parties install their first stream(j = 0) for 0-RTT, this reflects that the underlying TLSkey derivation (kc0 in Figure 4) depends only on client-sideinformation. Thus, although 0-RTT traffic is protected, itmay be decrypted by multiple server instances with differentindexes m.

Calls to ExtendD and Extend reflect handshake com-munications in the other direction, as the ServerCert-Finished stream is sent and received, causing ctx to beextended with (at least) m. Afterwards, as the two partiessuccessively install streams for the TLS keys kch, kc1, kc2, . . . ,successful decryption guarantees agreement on a context thatincludes the pair n,m. Thus, in this usage of our Recordgame at most one server will successfully decrypt the firstencrypted handshake fragment from the client, and from thispoint all streams are one-to-one.

Application to 0.5-RTT The server is the encryptor, theclient the decryptor and, since they both have initial accessto the first message exchange, we may select as index nthat includes the client hello and server hello messagesand implicitly authenticate the pair nC , nS . Thus, thereis at most one honest client decryptor for 0.5-RTT and,from the client’s viewpoint, successful decryption of thefirst handshake fragment ensures agreement on this context.Still (at least from the record’s viewpoint) the server is notguaranteed there is a matching decryptor until it receivesClientCert-Finished in the other direction and tran-sitions to 1-RTT.

Verified Implementation for miTLS (Outline) Our TLSRecord implementation supports sequences of streams forthe full protocol described in Figure 4 and its TLS 1.2counterpart.

Stream Sequences As described in the game above, it

maintains a current stream for each direction, and it receives‘extend’ and ‘install’ commands from the handshake proto-col as the connection gets established. Its indexes (ctx inthe game) consist of a summary of the handshake contextavailable at the time of key derivation (always including thealgorithms to use). In contrast with our game, which modelsall communications in a single direction, our code supports‘duplex’ communications. This is necessary, for instance, forsynchronizing key updates and connection closure betweenclients and servers. Our code also maintains a small (type-based) state machine that controls the availability of thecurrent streams for sending application data.

Re-keying and Corruption The state machine enforces alimit on the maximum number of fragments that can besent with one key to prevent sequence number overflows andaccount for the birthday bound weakness of AES-GCM. Onkey updates we delete old keys and model the corruption ofindividual streams using leak and coerce functions for keys.This is in keeping with the static corruption modeling ofMITLS, e.g. to account for insecure handshake runs.

Fragment API Our code for the record is parameterized bya type of abstract application-data plaintexts, indexed by aunique stream identifier and an apparent fragment length.Type abstraction guarantees that, if the stream identifier issafe (a property that depends on the handshake and keyderivation process), the idealized TLS implementation neveractually accesses their actual length and contents, a strongand simple confidentiality property.

Our API has a configuration to control 0-RTT and 0.5-RTT as the connection is created. In particular, 0-RTTplaintexts have their own type, (indexed by an identifier thatdescribe their 0-RTT context) which should help applicationstreat it securely. Conversely, 0.5-RTT is modeled simply byenabling earlier encryption of 1-RTT traffic.

Message API Our code also has a higher-level API withmessages as (potentially large) bytestrings instead of indi-vidual fragments. As usual with TLS, message boundariesare application specific, whereas applications tend to ignorefragment boundaries. Nonetheless, our code preserves ap-parent message boundaries, never caches or fragments smallmessages, and supports message length-hiding by taking asinputs both the apparent (maximal) size `max of the messageand its private (actual) size `m. It has a simple fragmentationloop, apparently sending up to 214 bytes at each iteration,starting with `max − `m bytes of padding follows by theactual data. (This ensures that an application that waitsfor the whole message never responds before receiving thelast fragment.) We do not model de-fragmentation on thereceiving end; our code delivers fragments as they arrivein a buffer provided by the application for reassembling itsmessages.

The correctness and security of this construction on top of

the fragment API is verified by typing, essentially abstract-ing sequences of fragments into sequences of bytes for thebenefit of the application, and turning close-notify alert frag-ments into end-of-files. (See also [22] for a cryptographictreatment of fragmentation issues.)

IX. EXPERIMENTAL EVALUATION

We evaluate our reference implementation of the TLSrecord layer both qualitatively (going over the verified goalsof the various modules and how they relate to the gamespresented in the paper, and checking that our implementationinteroperates with other TLS libraries) and quantitatively(measuring the verification and runtime performance).

Verification evaluation Table II summarizes the modularstructure of our code, and evaluates the verification costs andthe extracted OCaml and C implementations. Since proofsand implementations are tightly interleaved in F? sourcecode, it is difficult to accurately measure a precise sourceoverhead. The reported annotation percentages figure in thetable are rough manual estimates, but they can be comparedto the size of extracted implementations.

Most of the verification burden comes from the securityproof of AEAD (totaling approximately 4,500 lines ofannotation out of a total of about 5,500 lines of F?) and thefunctional correctness proof of the MAC implementations(totaling over 4,000 lines of annotations and lemmas). Forthe latter, we extended F? with a new big number libraryto verify the low-level implementations of various mathe-matical operations (such as point multiplication on ellipticcurves or multiplication over finite fields) using machine-sized integers and buffers. We use it to prove the correctnessof the polynomial computations for Poly1305 and GHASH.

Current limitations Our record layer implementation ispart of miTLS in F?: a larger, partially verified codebasethat intends to provide a secure, efficient implementation forboth TLS 1.2 and TLS 1.3. We leave a complete verificationof the TLS 1.3 handshake and its integration with our codeas future work.

Our implementation also includes the first miTLS com-ponent implemented in a lower level fragment of F? thatenables its extraction to C code. In contrast, the rest ofmiTLS is still extracted to OCaml and, until it is similarlyadapted, relies on an unverified OCaml/C wrapper to call ourextracted C code. Currently, this runtime transition is doneat the level of the AEAD interface, enabling us to switchto other generic cryptographic providers more easily (e.g.to compare performance with OpenSSL). Hence, the TLS-specific stateful encryption in StreamAE is verified on topof an idealized AEAD interface that slightly differs from theone exported by our idealized Crypto.AEAD construction.For instance, the former represents fragments as sequencesof bytes, whereas the latter uses a lower level memory

Module Name Verification Goals LoC % annot ML LoC C LoC TimeStreamAE Game StAEb from §VI 318 40% 354 N/A 307sAEADProvider Safety and AEAD security (high-level interface) 412 30% 497 N/A 349sCrypto.AEAD Proof of Theorem 2 from §V 5,253 90% 2,738 2,373 1,474sCrypto.Plain Plaintext module for AEAD 133 40% 95 85 8sCrypto.AEAD.Encoding AEAD encode function from §V and injectivity proof 478 60% 280 149 708sCrypto.Symmetric.PRF Game PrfCtrb from §IV 587 40% 522 767 74sCrypto.Symmetric.Cipher Agile PRF functionality 193 30% 237 270 65sCrypto.Symmetric.AES Safety and correctness w.r.t pure specification 1,254 30% 4,672 3,379 134sCrypto.Symmetric.ChaCha20 965 80% 296 119 826sCrypto.Symmetric.UF1CMA Game MMac1b from §III 617 60% 277 467 428sCrypto.Symmetric.MAC Agile MAC functionality 488 50% 239 399 387sCrypto.Symmetric.GF128 GF (128) polynomial evaluation and GHASH encoding 306 40% 335 138 85sCrypto.Symmetric.Poly1305 GF (2130−5) polynomial evaluation and Poly1305 encoding 604 70% 231 110 245sHacl.Bignum Bignum library and supporting lemmas

for the functional correctness of field operations3,136 90% 1,310 529 425s

FStar.Buffer.* A verified model of mutable buffers (implemented natively) 1,340 100% N/A N/A 563sTotal 15,480 78% 12,083 8,795 1h 41m

Table IIMODULES IN OUR VERIFIED RECORD LAYER IMPLEMENTATION

model and represents fragments as mutable I/O buffers,hence the transition requires copying fragments betweenrepresentations.

Interoperability Our record implementation supports bothTLS 1.3 and 1.2 and exposes them through a common API.We have tested interoperability for our TLS 1.2 record layerwith all major TLS implementations. For TLS 1.3 draft-14, we tested interoperability with multiple implementations,including BoringSSL, NSS, BoGo, and Mint, at the IETF96Hackathon. For draft-18, we tested interoperability with thelatest version of Mint at the time of writing. In all cases,our clients were able to connect to interoperating serversusing an ECDHE or PSK_ECDHE key exchange, then toexchange data with one of the following AEAD algorithms:AES256-GCM, AES128-GCM, and ChaCha20-Poly1305.Similarly, our servers were able to accept connections frominteroperating clients that support the above ciphersuites.

Performance We evaluate the performance of our recordlayer implementation at two levels. First, we compare ourimplementation of AEAD encryption extracted to C usingan experimental backend for F? to OpenSSL 1.1.0 compiledwith the no−asm option, disabling handwritten assemblyoptimizations. Our test encrypts a random payload of 214

bytes with 12 bytes of constant associated data. We reportaverages over 3,000 runs on an Intel Core E5-1620v3 CPU(3.5GHz) on Windows 64-bit.

Crypto.AEAD OpenSSLChaCha20-Poly1305 13.67 cycles/byte 9.79 cycles/byteAES256-GCM 584.80 cycles/byte 33.09 cycles/byteAES128-GCM 477.93 cycles/byte 28.27 cycles/byte

Our implementation is 17 to 18 times slower than OpenSSLfor AES-GCM and about 30% slower for ChaCha20-Poly1305. Note that the performance of custom assemblyimplementations can be significantly better. OpenSSL with

assembly can perform ChaCha20-Poly1305 in about onecycle per byte and can do AES128-GCM and AES256-GCMin less than half a cycle per byte.

Next, we measure the throughput of our record layer inte-grated into miTLS by downloading one gigabyte of randomdata from a local TLS server. We compare two differentintegration methods: first, we extract the verified record layerin OCaml, and compile it alongside the OCaml-extractedmiTLS. Then, we build an F? interface to the C versionof our record implementation and call it from miTLS. Wecompare these results with the default AEAD provider ofmiTLS (based on OpenSSL 1.1.0 with all optimizations,including hardware-accelerated AES), and curl (which usesOpenSSL for the full TLS protocol).

OCaml C OpenSSL curlChaCha20-Poly1305 167 KB/s 183 MB/s 354 MB/s 440 MB/sAES256-GCM 68 KB/s 5.61 MB/s 398 MB/s 515 MB/sAES128-GCM 89 KB/s 5.35 MB/s 406 MB/s 571 MB/s

We observe that miTLS is not a limiting factor in thesebenchmarks as its performance using the OpenSSL imple-mentation of AEAD encryption is comparable to that oflibcurl.

Unsurprisingly, the OCaml version of our verified im-plementation performs very poorly. This is due to thehigh overhead of both memory operations and arithmeticcomputations in the OCaml backend of F? (which usesgarbage-collected lists for buffers, and arbitrary-precisionzarith integers). The C extracted version is over 30,000 timesfaster, but remains two orders of magnitude slower than thehardware-optimized assembly implementations in OpenSSLfor AES. For ChaCha20-Poly1305, we achieve 50% of theassembly-optimized OpenSSL throughput.

Although our code is optimized for verification and mod-ularity rather than performance, we do not believe that

we can close the performance gap only by improving F?

code for hardware-accelerated algorithms such as AES-GCM—instead, we intend to selectively link our F? codewith assembly code proven to correctly implement a sharedfunctional specification. We leave this line of research forfuture work.

REFERENCES

[1] N. J. AlFardan and K. G. Paterson, “Lucky thirteen: Breakingthe TLS and DTLS record protocols,” in 2013 IEEE Sympo-sium on Security and Privacy, 2013, pp. 526–540.

[2] J. B. Almeida, M. Barbosa, G. Barthe, and F. Dupressoir,“Verifiable side-channel security of cryptographic implemen-tations: Constant-time MEE-CBC,” in 23rd InternationalConference on Fast Software Encryption, FSE 2016, 2016,pp. 163–184.

[3] C. Badertscher, C. Matt, U. Maurer, P. Rogaway, and B. Tack-mann, “Augmented secure channels and the goal of the TLS1.3 record layer,” in 9th International Conference on ProvableSecurity, ProvSec 2015, 2016, pp. 85–104.

[4] G. Barthe, C. Fournet, B. Grégoire, P. Strub, N. Swamy,and S. Zanella-Béguelin, “Probabilistic relational verificationfor cryptographic implementations,” in 41st Annual ACMSymposium on Principles of Programming Languages, POPL2014, 2014, pp. 193–206.

[5] M. Bellare and P. Rogaway, “The security of triple encryptionand a framework for code-based game-playing proofs,” inAdvances in Cryptology – EUROCRYPT 2006, 2006, pp. 409–426.

[6] ——, “Code-based game-playing proofs and the securityof triple encryption,” Cryptology ePrint Archive, Report2004/331, 2004, http://eprint.iacr.org/2004/331.

[7] M. Bellare and B. Tackmann, “The multi-user security of au-thenticated encryption: AES-GCM in TLS 1.3,” in Advancesin Cryptology – CRYPTO 2016, 2016, pp. 247–276.

[8] D. J. Bernstein, “The Poly1305-AES message-authenticationcode,” in 12th International Workshopo on Fast SoftwareEncryption, FSE 2005, 2005, pp. 32–49.

[9] ——, “Stronger security bounds for Wegman-Carter-Shoupauthenticators,” in Advances in Cryptology – EUROCRYPT2005, 2005, pp. 164–180.

[10] K. Bhargavan and G. Leurent, “On the practical (in-)securityof 64-bit block ciphers: Collision attacks on HTTP over TLSand OpenVPN,” Cryptology ePrint Archive, Report 2016/798,2016, http://eprint.iacr.org/2016/798.

[11] K. Bhargavan, C. Fournet, M. Kohlweiss, A. Pironti, andP. Strub, “Implementing TLS with verified cryptographicsecurity,” in 2013 IEEE Symposium on Security and Privacy,2013, pp. 445–459.

[12] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, , A. Pironti,and P.-Y. Strub, “Triple handshakes and cookie cutters:Breaking and fixing authentication over TLS,” in 2014 IEEESymposium on Security and Privacy, 2014, pp. 98–113.

[13] K. Bhargavan, C. Fournet, M. Kohlweiss, A. Pironti, P.-Y.Strub, and S. Zanella-Béguelin, “Proving the TLS handshakesecure (as it is),” Cryptology ePrint Archive, Report 2014/182,2014, http://eprint.iacr.org/2014/182/.

[14] H. Böck, “Wrong results with Poly1305 functions,” https://mta.openssl.org/pipermail/openssl-dev/2016-March/006413,2016.

[15] H. Böck, A. Zauner, S. Devlin, J. Somorovsky, and P. Jo-vanovic, “Nonce-disrespecting adversaries: Practical forgery

attacks on GCM in TLS,” Cryptology ePrint Archive, Report2016/475, 2016, http://eprint.iacr.org/2016/475.

[16] C. Boyd, B. Hale, S. F. Mjølsnes, and D. Stebila, “Fromstateless to stateful: Generic authentication and authenticatedencryption constructions with application to TLS,” in Topicsin Cryptology – CT-RSA 2016, 2016, pp. 55–71.

[17] C. Cremers, M. Horvat, S. Scott, and T. van der Merwe,“Automated analysis and verification of TLS 1.3: 0-RTT,resumption and delayed authentication,” in 2016 IEEE Sym-posium on Security and Privacy, 2016, pp. 470–485.

[18] B. Dowling, M. Fischlin, F. Günther, and D. Stebila, “Acryptographic analysis of the TLS 1.3 handshake protocolcandidates,” in 22nd ACM Conference on Computer andCommunications Security, 2015, pp. 1197–1210.

[19] ——, “A cryptographic analysis of the TLS 1.3draft-10 full and pre-shared key handshake protocol,”http://eprint.iacr.org/2016/081, 2016.

[20] T. Duong and J. Rizzo, “Here come the ⊕ ninjas,” Availableat http://nerdoholic.org/uploads/dergln/beast_part2/ssl_jun21.pdf, May 2011.

[21] M. J. Dworkin, “Recommendation for block cipher modesof operation: Galois/Counter mode (GCM) and GMAC,”National Institute of Standards & Technology, Tech. Rep. SP800-38D, 2007.

[22] M. Fischlin, F. Günther, G. A. Marson, and K. G. Paterson,“Data is a stream: Security of stream-based channels,” inAdvances in Cryptology - CRYPTO 2015, 2015, pp. 545–564.

[23] M. Fischlin, F. Günther, B. Schmidt, and B. Warinschi,“Key confirmation in key exchange: A formal treatment andimplications for TLS 1.3,” in 2016 IEEE Symposium onSecurity and Privacy, 2016, pp. 197–206.

[24] C. Fournet, M. Kohlweiss, and P. Strub, “Modular code-based cryptographic verification,” in 18th ACM Conferenceon Computer and Communications Security, CCS 2011, 2011,pp. 341–350.

[25] F. Giesen, F. Kohlar, and D. Stebila, “On the security of TLSrenegotiation,” in 2013 ACM Conference on Computer andCommunications Security, CCS 2013, 2013, pp. 387–398.

[26] P. Gutmann, “Encrypt-then-MAC for Transport Layer Secu-rity (TLS) and Datagram Transport Layer Security (DTLS),”IETF RFC 7366, 2014.

[27] T. Jager, F. Kohlar, S. Schäge, and J. Schwenk, “On thesecurity of TLS-DHE in the standard model,” in Advancesin Cryptology – CRYPTO 2012, 2012, pp. 273–293.

[28] T. Jager, J. Schwenk, and J. Somorovsky, “On the securityof TLS 1.3 and QUIC against weaknesses in PKCS#1 v1.5encryption,” in 22nd ACM Conference on Computer andCommunications Security, 2015, pp. 1185–1196.

[29] M. Kohlweiss, U. Maurer, C. Onete, B. Tackmann, andD. Venturi, “(de-) constructing TLS 1.3,” in Progress inCryptology–INDOCRYPT 2015. Springer, 2015, pp. 85–102.

[30] H. Krawczyk, “LFSR-based hashing and authentication,” inAdvances in Cryptology – CRYPTO 1994, 1994, pp. 129–139.

[31] ——, “The order of encryption and authentication for protect-ing communications (or: how secure is SSL?),” CryptologyePrint Archive, Report 2001/045, 2001, http://eprint.iacr.org/2001/045.

[32] H. Krawczyk and H. Wee, “The OPTLS protocol and TLS1.3,” Cryptology ePrint Archive, Report 2015/978, 2015, http://eprint.iacr.org/2015/978.

[33] H. Krawczyk, K. G. Paterson, and H. Wee, “On the securityof the TLS protocol: A systematic analysis,” in Advances inCryptology – CRYPTO 2013, 2013, pp. 429–448.

[34] A. Luykx and K. G. Paterson, “Limits on authenticated

encryption use in TLS,” Personal webpage: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, 2015.

[35] D. McGrew and J. Viega, “Flexible and efficient messageauthentication in hardware and software.” Unpublished draft.Available online at http://www.cryptobarn.com/.

[36] D. McGrew, “An interface and algorithms for authenticatedencryption,” IETF RFC 5116, 2008.

[37] B. Möller, T. Duong, and K. Kotowicz, “This POODLE Bites:Exploiting The SSL 3.0 Fallback,” Available at https://www.openssl.org/~bodo/ssl-poodle.pdf, 2014.

[38] Y. Nir and A. Langley, “ChaCha20 and Poly1305 for IETFprotocols,” IETF RFC 7539, 2015.

[39] K. G. Paterson, T. Ristenpart, and T. Shrimpton, “Tag sizedoes matter: Attacks and proofs for the TLS record protocol,”in Advances in Cryptology – ASIACRYPT 2011, 2011, pp.372–389.

[40] J. Rizzo and T. Duong, “The CRIME Attack,” September2012.

[41] J. Salowey, A. Choudhury, and D. McGrew, “AES GaloisCounter Mode (GCM) cipher suites for TLS,” IETF RFC5288, 2008.

[42] P. Sarkar, “A trade-off between collision probability and keysize in universal hashing using polynomials,” CryptologyePrint Archive, Report 2009/048, 2009, http://eprint.iacr.org/2009/048.

[43] V. Shoup, “On fast and provably secure message authentica-tion based on universal hashing,” in Advances in Cryptology– CRYPTO 1996, 1996, pp. 313–328.

[44] B. Smyth and A. Pironti, “Truncating TLS connectionsto violate beliefs in web applications,” Inria, Tech.Rep. hal-01102013, Oct. 2014. [Online]. Available: https://hal.inria.fr/hal-01102013

[45] J. Somorovsky, “Systematic fuzzing and testing of TLSlibraries,” in 23rd ACM Conference on Computer and Com-munications Security, CCS 2016, 2016.

[46] N. Swamy, C. Hritcu, C. Keller, A. Rastogi, A. Delignat-Lavaud, S. Forest, K. Bhargavan, C. Fournet, P.-Y. Strub,M. Kohlweiss, J.-K. Zinzindohoue, and S. Zanella-Béguelin,“Dependent types and multi-monadic effects in F*,” in 43ndACM Symposium on Principles of Programming Languages,POPL 2016, 2016, pp. 256–270.

[47] R. Swiecki, “ChaCha20/Poly1305 heap-buffer-overflow,”CVE-2016-7054, 2016.

[48] P. Swire, J. Hemmings, and A. Kirkland, “Online privacy andISPs: ISP access to consumer data is limited and often lessthan access by others,” Georgia Tech, Tech. Rep., 2016.

[49] D. Wagner and B. Schneier, “Analysis of the SSL 3.0 pro-tocol,” in 2nd USENIX Workshop on Electronic Commerce,WOEC 1996, 1996, pp. 29–40.