ILC: A Calculus for Composable, Computational Cryptography

Kevin Liao Matthew A. Hammer Andrew Miller University of Illinois DFINITY, USA University of Illinois Urbana-Champaign, USA [email protected] Urbana-Champaign, USA [email protected] [email protected] Abstract 1 Introduction The universal composability (UC) framework is the estab- In cryptography, a proof of security in the simulation-based lished standard for analyzing cryptographic protocols in a universal composability (UC) framework is considered the modular way, such that security is preserved under concur- gold standard for demonstrating that a protocol “does its job rent composition with arbitrary other protocols. However, securely” [16]. In particular, a UC-secure protocol enjoys the although UC is widely used for on-paper proofs, prior at- strongest notion of compositionality—it maintains all secu- tempts at systemizing it have fallen short, either by using a rity properties even when run concurrently with arbitrary symbolic model (thereby ruling out computational reduction other protocol instances. This is in contrast with weaker proofs), or by limiting its expressiveness. property-based notions that only guarantee security in a In this paper, we lay the groundwork for building a con- standalone setting [37] or under sequential composition [26]. crete, executable implementation of the UC framework. Our Thus, the benefit of using UC is modularity—it supports an- main contribution is a process calculus, dubbed the Inter- alyzing complex protocols by composing simpler building active Lambda Calculus (ILC). ILC faithfully captures the blocks. However, the cost of using UC is that security proofs computational model underlying UC—interactive Turing tend to be quite complicated. We believe that applying a PL- machines (ITMs)—by adapting ITMs to a subset of the 휋- style of systemization to UC can help simplify its use, bring calculus through an affine typing discipline. In other words, new clarity, and provide useful tooling. We envision a future well-typed ILC programs are expressible as ITMs. In turn, ILC’s where modularity of cryptographic protocol composition strong confluence property enables reasoning about crypto- translates to modular implementation as well. graphic security reductions. We use ILC to develop a simpli- Reviewing prior efforts of applying PL techniques to cryp- fied implementation of UC called SaUCy. tography, we find they run up against challenges when im- porting the existing body of UC theory. Either they do not CCS Concepts • Security and privacy → Formal secu- support computational reasoning (which considers issues rity models. of probability and computational complexity) [10], do not Keywords Provable security, universal composability, pro- support message-passing concurrency for distributed proto- cess calculus, type systems cols [4], or are too expressive (allow for expressing nonde- terminism with no computational interpretation) [2]. ACM Reference Format: Our observation is that these approaches diverge from Kevin Liao, Matthew A. Hammer, and Andrew Miller. 2019. ILC: UC at a low level: UC is defined atop the underlying (con- A Calculus for Composable, Computational Cryptography. In Pro- current) computational model of interactive Turing machines ceedings of the 40th ACM SIGPLAN Conference on Programming (ITMs). The significance of ITMs is that they have a clear com- Language Design and Implementation (PLDI ’19), June 22–26, 2019, putational interpretation, so it is straightforward to relate Phoenix, AZ, USA. ACM, New York, NY, USA, 31 pages. https: execution traces to a probabilistic polynomial time computa- //doi.org/10.1145/3314221.3314607 tion, as is necessary for cryptographic reduction proofs. The presence of (non-probabilistic) nondeterminism in alterna- Permission to make digital or hard copies of all or part of this work for tive models of concurrency would frustrate such reduction personal or classroom use is granted without fee provided that copies are not proofs. ITMs sidestep this issue by having a deterministic made or distributed for profit or commercial advantage and that copies bear (modulo random coin tosses), “single-threaded” execution se- this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with mantics. That is, processes pass control from one to another credit is permitted. To copy otherwise, or republish, to post on servers or to each time a message is sent so that exactly one process is ac- redistribute to lists, requires prior specific permission and/or a fee. Request tive at any given time, and, moreover, the order of activations permissions from [email protected]. is fully determined. PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA In this paper, we take up the challenge of faithfully cap- © 2019 Association for Computing Machinery. turing these idioms by designing a new process calculus ACM ISBN 978-1-4503-6712-7/19/06...$15.00 https://doi.org/10.1145/3314221.3314607 called the Interactive Lambda Calculus (ILC), which adapts PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

ITMs to a subset of the 휋-calculus [43] through an affine 2 Overview typing discipline. In other words, well-typed ILC programs We first provide background on the universal composability are expressible as ITMs. We then use ILC to build a concrete, framework and then give a tour of ILC. executable implementation of a simplified UC framework, dubbed SaUCy. 2.1 Background on Universal Composability Security proofs in the UC framework follow the real/ideal 1.1 Interactive Lambda Calculus paradigm [26]. To carry out some cryptographic task in the real world, we define a distributed protocol that achieves the Why do we need another process calculus in the first place? task across many untrusted processes. Then, to show that it Where do existing ones fall short? On the one hand, process is secure, we compare it with an idealized protocol in which calculi such as the 휋-calculus [43] and its cryptography- processes simply rely on a single trusted process to carry out oriented variants [1, 2, 35] are not a good fit to ITMs, since the task for them (and so security is satisfied trivially). they permit non-confluent reductions by design (i.e., non- The program for this single trusted process is called an probabilistic nondeterminism). On the other hand, various ideal functionality as it provides a uniform way to describe all other calculi that do enjoy confluence are overly restrictive, the security properties we want from the protocol. Roughly only allowing for fixed or two-party communications [10, speaking, we say a protocol 휋 realizes an ideal functionality 24, 30]. F (i.e., it meets its specification) if every adversarial behavior ILC fills this gap by adapting ITMs to a subset ofthe 휋- in the real world can also be exhibited in the ideal world. calculus through an affine typing discipline. To maintain Once we have defined 휋 and F , proving realization for- that only one process is active (can write) at any given time, mally follows a standard rhythm: processes implicitly pass around an affine “write token” by virtue of where they perform read and write effects: When 1. The first step is a construction: We must provide a sim- 휋 process 퐴 writes to process 퐵, process 퐴 “spends” the write ulator S that translates any attack A on the protocol token and process 퐵 “earns” the write token. Moreover, to into an attack on F . maintain that the order of activations is fully determined, 2. The second step is a relational analysis: We must show 휋 the read endpoints of channels are (non-duplicable) affine that running under attack by any adversary A (the real resources, and so each write operation corresponds to a world) is indistinguishable from running F under attack single, unique read operation. Together, these give ILC its by S (the ideal world) to any distinguisher Z called the central metatheoretic property of confluence. environment. The importance of confluence is that the only nondeter- In particular, Z is an adaptive distinguisher: It interacts with minism in an ILC program is due to random coin tosses taken both the real world and the ideal world, and the simulation by processes, which have a well-defined distribution. Addi- is sound if no Z can distinguish between the two. tionally, any apparent concurrency hazards, such as adversar- As mentioned, the primary goal of this framework is com- ial scheduling of messages in an asynchronous network, are positionality. Suppose a protocol 휋 is a protocol module that due to an explicit adversary process rather than uncertainty realizes a functionality F (a specification of the module), built into the model itself. This eliminates non-probabilistic and suppose a protocol 휌, which relies on F as a subroutine, nondeterminism, and so ILC programs are amenable to the in turn realizes an application specification functionality G. reasoning patterns necessary for establishing computational Then, the composed protocol 휌 ◦ 휋, in which calls to F are security guarantees. replaced by calls to 휋, also realizes G. Instead of analyzing the composite protocol consisting of 휌 and 휋, it suffices to analyze the security of 휌 itself in the simpler world with F , 1.2 Contributions the idealized version of 휋. To summarize, our main contributions are these: Finally, the UC framework is defined atop the underlying computational model of interactive Turing machines (ITMs). • We design a foundational calculus for the purpose of sys- In the ITM model, processes pass control from one to another temizing UC called the Interactive Lambda Calculus, which each time a message is sent so that exactly one process is active exhibits confluence and is a faithful abstraction of ITMs. at any given time, and, moreover, the order of activations • We use ILC to build a concrete, executable implementation is fully determined. This gives ITMs a clear computational of a simplified UC framework called SaUCy. interpretation, which is necessary for the above proofs (in • We then use SaUCy to port over a sampling of theory particular, cryptographic reductions) to go through. from UC literature, including a composition theorem, an instantiation proof of UC commitments [19], and an exam- 2.2 ILC by Example ination of a subtle definitional issue involving reentrant We make the above more concrete by running through an concurrency [14]. example of commitment, an essential building block in many 2 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

F proceeds as follows, running with committer 푃 and receiver 푄. com fCom :: Wr Msg → Rd Msg ⊸ 1 ( ,푏) 푃 푏 ∈ { , } 1. Upon receiving a message Commit from , where 0 1 , let fCom toQ frP = record the value 푏 and send the message (Receipt) to 푄. Ignore let (!(Commit b), frP) = rd frP in any subsequent Commit messages. wr Receipt → toQ ; 2. Upon receiving a message (Open) from 푃, proceed as follows: If ( ) some value 푏 was previously recorded, then send the message let !Open, frP = rd frP in (Open,푏) to 푄 and halt. Otherwise, halt. wr (Opened b) → toQ

Figure 1. An ideal functionality for a one-time commitment scheme in prose (left) and in ILC (right). cryptographic protocols [11]. The idea behind commitment own the write token. Because the write token is unique, is simple: A committer provides a receiver with the digital at most one process owns the write token (“is active” or equivalent of a “sealed envelope” containing some value “can write”) at any given time. When process 퐵 reads the that can later be revealed. The commitment scheme must message from 퐴, process 퐵 earns the write token, thereby be hiding in the sense that the commitment itself reveals no conserving its uniqueness and now allowing process 퐵 to information about the committed value, and binding in the write to some other process. sense that the committer can only open the commitment • The order of activations is deterministic. Each channel (or to a single value. For security under composition, an addi- “tape” in ITM parlance) has a read endpoint and a write tional non-malleability property is required, which roughly endpoint. The read endpoint is an affine resource, and prevents an attacker from using one commitment to derive so it is owned by at most one process. This ensures that another related one. each write operation corresponds to a single, unique read All of these properties are captured at once using an ideal operation. functionality. In Figure1 (left), we show a simplified ideal functionality for one-time bit commitment, Fcom, as it would appear in the cryptography literature [19]. The functionality Intuitively, the first invariant rules out the possibility of simply waits for the committer 푃 to commit to some bit 푏, write nondeterminism. Consider the case in which two pro- notifies the receiver 푄 that it has taken place, and reveals 푏 cesses are trying to execute writes in parallel, which would to 푄 upon request by 푃. Notice that 푄 never actually sees a lead to a race condition. This does not typecheck, since the commitment to 푏 (only the (Receipt) message), so the three affine write token belongs to at most one process. Onemight properties hold trivially. justifiably wonder why write endpoints are unrestricted and In Figure1 (right), we implement a simplified version read endpoints are affine. Note that if two processes are try- ing to write in parallel, the two write endpoints need not be of Fcom in ILC to highlight some key features of the lan- guage. The function fCom takes two channel endpoints as the same, so making write endpoints affine would not help arguments. The first is a write endpoint toQ : Wr Msg (for our case in eliminating write nondeterminism. sending messages of type Msg to 푄), and the second is a read Dually, the second invariant rules out the possibility of endpoint frP : Rd Msg (for receiving messages of type Msg read nondeterminism. Consider the case in which two pro- 퐴 퐵 from 푃). At a high level, it should be clear how the communi- cesses and are listening on the same read endpoint. If a 퐶 cation pattern in fCom follows that in F , but there are a process writes on the corresponding write endpoint, which com 퐴 퐵 few details that require further explanation. These details are of or (or both) gets activation? If only one of them is better explained in the context of ILC’s type system, which activated, then we have a source of nondeterminism. If both 퐴 퐵 we give a quick tour of next. are activated, now and both own write tokens, violat- ing its affinity. In any case, this does not typecheck since 2.3 ILC Type System read endpoints are affine resources, making it impossible for two processes 퐴 and 퐵 to listen on the same read end- ILC terms have either an unrestricted type, meaning they can point. Together, these invariants ensure that processes have be freely copied, or an affine type, meaning they can be used a determined sequence of activations as desired. at most once. Affine typing serves a special purpose, namely, to ensure that ILC processes have a determined sequence of activations, as is required in ITMs. This is achieved through A Selection of Typing Rules. To see these invariants in the following invariants: action, we walk through the typing rules for fork, write, • Only one process is active at any given time. Processes im- and read expressions. We read the typing judgement Δ; Γ ⊢ plicitly pass around an affine “write token” w by virtue 푒 : 푈 as “under affine context Δ and unrestricted context Γ, of where they perform read and write effects.○ In order expression 푒 has type 푈 .” The metavariables 푈 and 푉 range for process 퐴 to write to process 퐵, process 퐴 must first over all types (both unrestricted and affine). 3 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

The fork expression 푒1 |▷ 푒2 spawns a child process 푒1 and arrows). As we mentioned, write endpoints are not affine, continues as 푒2. since this restriction does not help in preventing write non- determinism; read endpoints are affine, which does prevent Δ1; Γ ⊢ 푒1 : 푈 Δ2; Γ ⊢ 푒2 : 푉 fork read nondeterminism. To see that frP is being used affinely, , 푒 푒 푉 Δ1 Δ2; Γ ⊢ 1 |▷ 2 : notice that it is rebound when deconstructing the value- Its typing rule says that if we can partition the affine context endpoint pair from each read operation, so it can be used as Δ1, Δ2 such that 푒1 has type 푈 under contexts Δ1; Γ and again. 푒2 has type 푉 under contexts Δ2; Γ, then the expression has To see that the write token is being passed around appro- type 푉 . Notice that affine resources (e.g., read endpoints and priately, notice that the read and write effects are interleaved. the write token) must be split between the child process and Before each read operation, fCom does not own the write the parent process, thereby preventing their duplication. token: In the first read operation, only frP : RdMsg is present The write expression wr(푒1, 푒2) sends the value that 푒1 eval- in the affine context; in the second read operation, thefirst uates to on the write endpoint that 푒2 evaluates to. One thing write operation has already spent the write token. Before to mention is that only values of a sendable type (ranged each write operation, fCom does own the write token: Each over by 푆) can be sent over channels (more on this later). is preceded by a read operation.

Δ1; Γ ⊢ 푒1 : 푆 Δ2; Γ ⊢ 푒2 : Wr 푆 wr Δ1, Δ2, w ; Γ ⊢ wr(푒1, 푒2) : 1 ○ 3 Interactive Lambda Calculus Its typing rule says that if we own the write token and we We now present the Interactive Lambda Calculus in full, for- , 푒 can partition the affine context as Δ1 Δ2 such that 1 has type malizing its syntax, static semantics, and dynamic semantics. 푆 under contexts Δ1; Γ and 푒2 evaluates to a write endpoint (of type Wr 푆) under contexts Δ2; Γ, then the expression has type 1 (unit). Notice that typing a write expression spends 3.1 Syntax the write token, and so it cannot execute another write until 푈 it gets “reactivated” by reading from some other process. The syntax of ILC is given in Figure2. Types (written , 푉 ) are bifurcated into unrestricted types (written 퐴, 퐵) and The read expression rd(푒1, 푥.푒2) reads a value on the read affine types (written 푋, 푌 ). endpoint that 푒1 evaluates to and binds the value-endpoint pair as 푥 in the affine context of 푒 . Rebinding the read end- A subset of the unrestricted types are sendable types (writ- 2 푆 푇 point allows it to be reused. ten , ), i.e., the types of values that can be sent over chan- nels. This restriction ensures that channels model network 푒 푆 w ∉ Δ2 Δ1; Γ ⊢ 1 : Rd channels, which send only data. The sendable types include ○, , 푥 푆 푆 푒 푈 Δ2 w :! ⊗ Rd ; Γ ⊢ 2 : 1 푆 × 푇 푆 + 푇 ○ rd unit ( ), products ( ), and sums ( ). Δ1, Δ2; Γ ⊢ rd(푒1, 푥.푒2) : 푈 The unrestricted types include the sendable types, write endpoint types (Wr 푆), products (퐴 × 퐵), sums (퐴 + 퐵), arrows Its typing rule says that if we can partition the affine context (퐴 → 푈 or simply 퐴 → 푈 ), and write arrows (퐴 → 푈 ). as Δ , Δ such that 푒 evaluates to a read endpoint (of type ∞ w 1 2 1 Write arrows specify unrestricted abstractions for which Rd 푆) under contexts Δ ; Γ, and 푒 has type 푈 under contexts 1 2 the write token can be moved into the affine context of the Δ , w , 푥 :! 푆 ⊗ Rd 푆; Γ, then the expression has type 푈 . 2 abstraction body during 훽-reduction. There○ are a few things to unpack here. First, we explain The affine types include bang types! ( 퐴), read endpoint the affine product type ! 푆 ⊗ Rd 푆. Since sendable values are types (Rd 푆), products (푋 ⊗ 푌), sums (푋 ⊕ 푌 ), and arrows unrestricted and read endpoints are affine, the value read on (푋 → 푈 or simply 푋 ⊸ 푈 ). Notice that the write token the channel is wrapped in a ! operator (pronounced “bang”) 1 w lives in the affine context, though it cannot be boundto so that it can be placed in an affine pair. Next, observe that any○ variable. Instead, it flows around implicitly by virtue of w is available in the body 푒 of the read expression (i.e., it 2 where read and write effects are performed. is○ conserved), but only under the condition that it is not For concision, certain syntactic forms are parameterized already in the affine context Δ (otherwise, a process could 2 by a multiplicity 휋 to distinguish between the unrestricted arbitrarily mint write tokens, violating its affinity). (∞) and affine1 ( ) counterparts; other syntactic forms are Revisiting fCom. Having gone through several typing rules, parameterized by a syntax label ℓ, which includes the mul- we now revisit fCom from Figure1 (right). In particular, we tiplicity labels and the write label w (related to write ef- should convince ourselves that fCom respects the invariants fects). On introduction and elimination forms for functions of the type system. (abstraction, application, and fixed points), the label w de- The type signature tells us that toQ : Wr Msg is unre- notes variants that move around the write token as explained stricted (→ is the type connective for unrestricted arrows) above. On introduction and elimination forms for products and frP : Rd Msg is affine (⊸ is the type connective for affine and sums, the label w denotes the sendable variants. 4 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

All types 푈 ,푉 ::= 퐴 | 푋 Syntax labels ℓ ::= 휋 | w Sendable types 푆,푇 ::= 1 | 푆 × 푇 | 푆 + 푇 Multiplicity labels 휋 ::= 1 | ∞ Unrestricted types 퐴, 퐵 ::= 푆 | Wr 푆 | 퐴 × 퐵 | 퐴 + 퐵 | 퐴 →∞|w 푈 Unrestricted typings Γ ::= · | Γ, 푥 : 퐴 Affine types 푋, 푌 ::= ! 퐴 | Rd 푆 | 푋 ⊗ 푌 | 푋 ⊕ 푌 | 푋 →1 푈 Affine typings Δ ::= · | Δ, 푥 : 푋 | Δ, w ○ 푣 푣 , 푣 1 푣 2 푣 휆 푥. 푒 푐 푣 Values ::= ( ) | ( 1 2)ℓ | injℓ ( ) | injℓ ( ) | ℓ | | ! Channel endpoints 푐 ::= Read(푑) | Write(푑) Channel names 푑 ::= ··· 푒 푥 푒 , 푒 푖 푒 푒 , 푥 .푥 .푒 푒, 푥 .푒 , 푥 .푒 Expressions ::= | ( ) | ( 1 2)ℓ | injℓ ( ) | splitℓ ( 1 1 2 2) | caseℓ ( 1 1 2 2) 휆 푥. 푒 푒 푒 푥.푒 푒 , 푥.푒 푒 푒 | ℓ | ( 1 2)ℓ | fixℓ ( ) | let휋 ( 1 2) | ! | ¡ | 휈 (푥1, 푥2). 푒 | wr(푒1, 푒2) | rd(푒1, 푥.푒2) | ch(푒1, 푥1.푒3, 푒2, 푥2.푒4) | 푒1 |▷ 푒2

Figure 2. ILC Syntax.

Values in ILC (written 푣) include unit, pairs, sums, lambda allocation: expressions, channel endpoints (written 푐), and banged val- Ψ(푑) = 푆 ues. We distinguish between the names of channel endpoints— rdend Read(푑) and Write(푑)—and the channel 푑 itself that binds Ψ; Δ; Γ ⊢ Read(푑) : Rd 푆 them. ILC supports a fairly standard feature set of expres- sions. Bang-typed values have introduction form ! 푒 and elim- Ψ(푑) = 푆 푒 wrend ination form ¡ . The more interesting expressions are those Ψ; Δ; Γ ⊢ Write(푑) : Wr 푆 related to communication and concurrency: 휈 푥 , 푥 . 푒 푥 This pair of rules establish the canonical forms for the types • Restriction: ( 1 2) binds a read endpoint 1 and a cor- 푆 푆 푥 푒 of channel endpoints, Rd and Wr . We use the metavari- responding write endpoint 2 in . able 푐 to range over these two canonical forms. • Write: wr(푒1, 푒2) sends the value that 푒1 evaluates to on 푒 The typing rules for the functional fragment of ILC are the write endpoint that 2 evaluates to. fairly standard, except that they now have unrestricted and • Read: rd(푒1, 푥.푒2) reads a value from the read endpoint that 푒 푥 affine variants (and for some, sendable variants). 1 evaluates to and binds the value-endpoint pair as in The rule for unrestricted abstraction (uabs) extends the 푒 . 2 unrestricted context Γ with 푥 : 퐴 before checking the body 푒 • (푒 , 푥 .푒 , 푒 , 푥 .푒 ) Choice: ch 1 1 3 2 2 4 allows a process to continue of the abstraction. Notice that because unrestricted abstrac- as either 푒3 or 푒4 based on some initial read event on one 푒 푒 tions can be duplicated, the body must be affinely closed of the read endpoints that 1 and 2 evaluate to. The value (cannot contain free affine variables). read over the channel and the two read endpoints are The rule for write abstraction (wabs) is similar to uabs. The rebound in a 3-tuple as 푥1 in 푒3 or 푥2 in 푒4. Here, we show 푛 only difference is that wabs extends the affine context with only binary choice, but it can be generalized to the -ary the write token before checking the body 푒 of the abstraction. case. Dually, the write application rule (wapp) stipulates that a • Fork: 푒1 |▷ 푒2 spawns a child process 푒1 and continues as 푒 process must own the write token in order to apply a write 2. abstraction. The rule for affine abstraction (aabs) is analagous to uabs, 3.2 Static Semantics but notice that the body need not be affinely closed, since The typing rules of ILC are given in Figure3. An algorithmic affine abstractions cannot be duplicated. It turns outthat version of the rules appears in the appendix. most affine functions we write are affinely closed, and so To recap, the typing rules maintain that only one process such a function 푓 : 푋 ⊸ 푈 can be made into an unrestricted is active at any given time (unique ownership of the write function 푔 : 퐴 → 푋 ⊸ 푈 by adding a leading unrestricted token), and the order of activations is deterministic (unique argument. ownership of read endpoints). We read the typing judgement The bang rule turns an unrestrictedly typed expression Δ; Γ ⊢ 푒 : 푈 as “under affine context Δ and unrestricted 푒 : 퐴 into an affinely typed expression 푒 : ! 퐴. Dually, the context Γ, expression 푒 has type 푈 .” In full detail, the typing gnab rule turns an affinely typed expression 푒 : ! 퐴 into an judgement also includes a typing context Ψ, which maps unrestrictedly typed expression 푒 : 퐴. channel names 푑 to sendable types 푆. However, it is only The typing rules for fork, write, and read were covered used in two special rules for typing channel endpoints that in Section 2.3, so this leaves channel restriction (nu) and do not arise for source level programs, but will be needed to external choice (choice) as the remaining typing rules related typecheck a running program that has performed channel to communication and concurrency. 5 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

Δ; Γ ⊢ 푒 : 푈 Under affine context Δ and unrestricted context Γ, expression 푒 has type 푈 .

Γ(푥) = 퐴 Δ(푥) = 푋 Δ1; Γ ⊢ 푒1 : 퐴1 Δ2; Γ ⊢ 푒2 : 퐴2 uvar avar unit upair Δ; Γ ⊢ 푥 : 퐴 Δ; Γ ⊢ 푥 : 푋 Δ; Γ ⊢ ( ) : 1 Δ1, Δ2; Γ ⊢ (푒1, 푒2)∞ : 퐴1 × 퐴2

Δ1; Γ ⊢ 푒1 : 푆1 Δ2; Γ ⊢ 푒2 : 푆2 Δ1; Γ ⊢ 푒1 : 푋1 Δ2; Γ ⊢ 푒2 : 푋2 푖 ∈ {1, 2} Δ; Γ ⊢ 푒 : 퐴푖 spair apair uinj , 푒 , 푒 푆 푆 , 푒 , 푒 푋 푋 푖 푒 퐴 퐴 Δ1 Δ2; Γ ⊢ ( 1 2)w : 1 × 2 Δ1 Δ2; Γ ⊢ ( 1 2)1 : 1 ⊗ 2 Δ; Γ ⊢ inj∞ ( ) : 1 + 2

Δ1; Γ ⊢ 푒1 : 퐴1 × 퐴2 푖 ∈ {1, 2} Δ; Γ ⊢ 푒 : 푆푖 푖 ∈ {1, 2} Δ; Γ ⊢ 푒 : 푋푖 Δ2; Γ, 푥1 : 퐴1, 푥2 : 퐴2 ⊢ 푒 : 푈 sinj ainj usplit 푖 푒 푆 푆 푖 푒 푋 푋 , 푒 , 푥 .푥 .푒 푈 Δ; Γ ⊢ injw ( ) : 1 + 2 Δ; Γ ⊢ inj1 ( ) : 1 ⊕ 2 Δ1 Δ2; Γ ⊢ split∞ ( 1 1 2 2) :

Δ1; Γ ⊢ 푒1 : 푆1 × 푆2 Δ1; Γ ⊢ 푒1 : 푋1 ⊗ 푋2 Δ2; Γ, 푥1 : 푆1, 푥2 : 푆2 ⊢ 푒 : 푈 Δ2, 푥1 : 푋1, 푥2 : 푋2; Γ ⊢ 푒 : 푈 ssplit asplit , 푒 , 푥 .푥 .푒 푈 , 푒 , 푥 .푥 .푒 푈 Δ1 Δ2; Γ ⊢ splitw ( 1 1 2 2) : Δ1 Δ2; Γ ⊢ split1 ( 1 1 2 2) :

Δ1; Γ ⊢ 푒 : 퐴1 + 퐴2 Δ1; Γ ⊢ 푒 : 푆1 + 푆2 Δ2; Γ, 푥1 : 퐴1 ⊢ 푒1 : 푈 Δ2; Γ, 푥2 : 퐴2 ⊢ 푒2 : 푈 Δ2; Γ, 푥1 : 푆1 ⊢ 푒1 : 푈 Δ2; Γ, 푥2 : 푆2 ⊢ 푒2 : 푈 ucase scase Δ1, Δ2; Γ ⊢ case∞ (푒, 푥1.푒1, 푥2.푒2) : 푈 Δ1, Δ2; Γ ⊢ casew (푒, 푥1.푒1, 푥2.푒2) : 푈

Δ1; Γ ⊢ 푒 : 푋1 ⊕ 푋2 Δ2, 푥1 : 푋1; Γ ⊢ 푒1 : 푈 Δ2, 푥2 : 푋2; Γ ⊢ 푒2 : 푈 ·; Γ, 푥 : 퐴 ⊢ 푒 : 푈 w ; Γ, 푥 : 퐴 ⊢ 푒 : 푈 acase uabs ○ wabs Δ1, Δ2; Γ ⊢ case1 (푒, 푥1.푒1, 푥2.푒2) : 푈 Δ; Γ ⊢ 휆∞ 푥. 푒 : 퐴 →∞ 푈 Δ; Γ ⊢ 휆w 푥. 푒 : 퐴 →w 푈

Δ, 푥 : 푋; Γ ⊢ 푒 : 푈 Δ1; Γ ⊢ 푒2 : 퐴 Δ2; Γ ⊢ 푒1 : 퐴 →∞ 푈 aabs uapp Δ; Γ ⊢ 휆1 푥. 푒 : 푋 →1 푈 Δ1, Δ2; Γ ⊢ (푒1 푒2)∞ : 푈

Δ1; Γ ⊢ 푒2 : 퐴 Δ2; Γ ⊢ 푒1 : 퐴 →w 푈 Δ1; Γ ⊢ 푒2 : 푋 Δ2; Γ ⊢ 푒1 : 푋 →1 푈 wapp aapp Δ1, Δ2, w ; Γ ⊢ (푒1 푒2) : 푈 Δ1, Δ2; Γ ⊢ (푒1 푒2) : 푈 ○ w 1

·; Γ, 푥 : 퐴 →∞ 푈 ⊢ 푒 : 퐴 →∞ 푈 ·; Γ, 푥 : 퐴 →w 푈 ⊢ 푒 : 퐴 →w 푈 푥 : 푋 →1 푈 ; Γ ⊢ 푒 : 푋 →1 푈 ufix wfix afix Δ; Γ ⊢ fix∞ (푥.푒) : 퐴 →∞ 푈 Δ; Γ ⊢ fixw (푥.푒) : 퐴 →w 푈 Δ; Γ ⊢ fix1 (푥.푒) : 푋 →1 푈

Δ1; Γ ⊢ 푒1 : 퐴 Δ1; Γ ⊢ 푒1 : 푋 Δ2; Γ, 푥 : 퐴 ⊢ 푒2 : 푈 Δ2, 푥 : 푋; Γ ⊢ 푒2 : 푈 Δ; Γ ⊢ 푒 : 퐴 Δ; Γ ⊢ 푒 :! 퐴 ulet alet bang gnab Δ1, Δ2; Γ ⊢ let∞ (푒1, 푥.푒2) : 푈 Δ1, Δ2; Γ ⊢ let1 (푒1, 푥.푒2) : 푈 Δ; Γ ⊢ ! 푒 :! 퐴 Δ; Γ ⊢ ¡ 푒 : 퐴

Δ1; Γ ⊢ 푒1 : 푆 w ∉ Δ2 Δ1; Γ ⊢ 푒1 : Rd 푆 ○ Δ, 푥1 : Rd 푆; Γ, 푥2 : Wr 푆 ⊢ 푒 : 푈 Δ2; Γ ⊢ 푒2 : Wr 푆 Δ2, w , 푥 :! 푆 ⊗ Rd 푆; Γ ⊢ 푒2 : 푈 nu wr ○ rd Δ; Γ ⊢ 휈 (푥1, 푥2). 푒 : 푈 Δ1, Δ2, w ; Γ ⊢ wr(푒1, 푒2) : 1 Δ1, Δ2; Γ ⊢ rd(푒1, 푥.푒2) : 푈 ○

w ∉ Δ3 Δ1; Γ ⊢ 푒1 : Rd 푆 Δ2; Γ ⊢ 푒2 : Rd푇 ○ Δ3, w , 푥1 :! 푆 ⊗ Rd 푆 ⊗ Rd푇 ; Γ ⊢ 푒3 : 푈 Δ1; Γ ⊢ 푒1 : 푈 ○ Δ3, w , 푥2 :!푇 ⊗ Rd 푆 ⊗ Rd푇 ; Γ ⊢ 푒4 : 푈 Δ2; Γ ⊢ 푒2 : 푉 ○ choice fork Δ1, Δ2, Δ3; Γ ⊢ ch(푒1, 푥1.푒3, 푒2, 푥2.푒4) : 푈 Δ1, Δ2; Γ ⊢ 푒1 |▷ 푒2 : 푉

Figure 3. ILC typing rules.

6 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

퐸 = • | (퐸, 푒) | (푣, 퐸) | 푖 (퐸) Process names 푝, 푞 ::= ··· Evaluation :: ℓ ℓ injℓ | (퐸, 푥 .푥 .푒) | (퐸, 푥 .푒 , 푥 .푒 ) Name sets Σ ::= 휀 | Σ,푑 | Σ, 푝 contexts splitℓ 1 2 caseℓ 1 1 2 2 | (퐸 푒) | (푣 퐸) | (퐸, 푥.푒) | 퐸 | 퐸 Process pools 휋 ::= 휀 | 휋, 푝 : 푒 ℓ ℓ let휋 ! ¡ | (퐸, 푒) | (푣, 퐸) | (퐸, 푥.푒) Configurations 퐶 ::= ⟨Σ; 휋⟩ wr wr rd | ch(퐸, 푥1.푒3, 푒2, 푥2.푒4) | ch(푐, 푥1.푒3, 퐸, 푥2.푒4)

Figure 4. ILC dynamic syntax.

푐 푐 푐 푐 퐶1 ≡ 퐶2 Configurations 퐶1 and 퐶2 are equivalent. 1 { 2 Write endpoint 1 connects to read endpoint 2.

휋1 ≡perm 휋2 bind permProcs 푑 푑 ⟨Σ; 휋1⟩ ≡ ⟨Σ; 휋2⟩ Write( ) { Read( ) 퐶1 −→ 퐶2 Configuration 퐶1 reduces to 퐶2.

푒1 −→ 푒2 푞 ∉ Σ local fork ⟨Σ; 휋, 푝 : 퐸[푒1]⟩ −→ ⟨Σ; 휋, 푝 : 퐸[푒2]⟩ ⟨Σ; 휋, 푝 : 퐸[푒1 |▷ 푒2]⟩ −→ ⟨Σ, 푞; 휋, 푞 : 푒1, 푝 : 퐸[푒2]⟩

퐶 퐶 ′ 퐶 ′ 퐶 ′ 퐶 ′ 퐶 1 ≡ 1 1 −→ 2 2 ≡ 2 congr 퐶1 −→ 퐶2

푑 ∉ Σ nu ⟨Σ; 휋, 푝 : 퐸[휈 (푥1, 푥2). 푒]⟩ −→ ⟨Σ,푑; 휋, 푝 : 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒]⟩

푐2 { 푐1 rw 휋, 푝 퐸 푐 , 푥.푒 , 푞 퐸 푣, 푐 휋, 푝 퐸 푣, 푐 푥 푒 , 푞 퐸 ⟨Σ; : 1 [rd( 1 )] : 2 [wr( 2)]⟩ −→ ⟨Σ; : 1 [[(! 1)1/ ] ] : 2 [()]⟩

푐 { 푐푖 푖 ∈ {1, 2} cw 휋, 푝 퐸 푐 , 푥 .푒 , 푐 , 푥 .푒 , 푞 퐸 푣, 푐 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푞 퐸 ⟨Σ; : 1 [ch( 1 1 1 2 2 2)] : 2 [wr( )]⟩ −→ ⟨Σ; : 1 [[(! 1 2)1/ 푖 ] 푖 ] : 2 [()]⟩

푒1 −→ 푒2 Expression 푒1 reduces to 푒2.

let app split 푣, 푥.푒 푣 푥 푒 휆 푥. 푒 푣 푣 푥 푒 푣 , 푣 , 푥 .푥 .푒 푣 푥 푣 푥 푒 let휋 ( ) −→ [ / ] (( ℓ ) )ℓ −→ [ / ] splitℓ (( 1 2)ℓ 1 2 ) −→ [ 1/ 1][ 2/ 2]

case fix gnab 푖 푣 , 푥 .푒 , 푥 .푒 푣 푥 푒 푥.푒 푥.푒 푥 푒 푣 푣 caseℓ (injℓ ( ) 1 1 2 2) −→ [ / 푖 ] 푖 fixℓ ( ) −→ [fixℓ ( )/ ] ¡ (! ) −→

Figure 5. ILC reduction rules.

The nu rule extends the affine context Δ with a read end- 3.3 Dynamic Semantics 푥 푆 point 1 : Rd and the unrestricted context Γ with a corre- Figures4 and5 define the dynamic syntax and semantics of 푥 푆 sponding write endpoint 2 : Wr before typing the body ILC, respectively. We define a configuration 퐶 as a tuple of 푒 . dynamic channel and process names Σ, and a pool of running , , The choice rule partitions the affine context as Δ1 Δ2 Δ3. and terminated processes 휋. The first two affine contexts are used totype 푒 : 푆 and 1 Rd We read the configuration reduction judgment 퐶1 −→ 푒 : 푇 , respectively. The third affine context Δ is extended 2 Rd 3 퐶2 as “configuration 퐶1 steps to configuration 퐶2,” and the with the affine write token and a variable 푥 (or 푥 ) binding 1 2 local stepping judgment 푒1 −→ 푒2 for a single process 푒 an affine 3-tuple containing the read value and the two read as “expression 푒 steps to expression 푒 .” The rules of local 푒 푒 1 2 endpoints before checking the continuation 3 (or 4). While stepping follow a standard call-by-value semantics, where somewhat cumbersome, the generality of this rule allows we streamline the definition with an evaluation context 퐸. both read endpoints to be used in either continuation.

7 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

Configuration stepping consists of six rules. These include 4.2 Confluence a congruence rule congr that permits some of the other rules Confluence implies, among other things, that the orderof to be simpler, by making the order of the pool unimportant. reduction steps is inconsequential, and that no process sched- 휋 휋 휋 The relation 1 ≡perm 2 holds when 2 is a permutation of uling choices will affect the final outcome. ILC’s type system 휋 1. The other five rules consist of local stepping (via local), enforces confluence up to nondeterministic naming choices creating new processes (via fork), creating new channels in rules nu and fork (Figure5). To account for different (via nu), read-write interactions (via rw), and choice-write choices of dynamically-named channels and processes, re- interactions (via cw). To avoid allocating the same name spectively, we state and prove confluence with respect to twice, the name set Σ records names of allocated channels a renaming function 푓 , which consistently renames these 푐 푐 and processes. We define the relation 1 { 2 to hold when choices in a related configuration: 푐1 is the write endpoint of a corresponding read endpoint 푐2. Theorem 4.3 (Single-step confluence). For all well-typed 4 ILC Metatheory configurations 퐶, if 퐶 −→ 퐶1 and 퐶 −→ 퐶2, then there exists Intuitively, ILC’s type system design enforces that a con- a renaming function 푓 such that either: figuration’s reduction consists of a unique (deterministic) 1. 퐶 = 푓 (퐶 ), or sequence of reader-writer process pairings, and is confluent 1 2 2. there exists 퐶 such that 퐶 −→ 퐶 and 푓 (퐶 ) −→ 퐶 . with any other reduction choice that exchanges the order 3 1 3 2 3 of other (non-interactive) reduction steps. As explained in Intuitively, the sister configuration 퐶2 is either different Section3, ILC’s type system does so by restricting the write because of a name choice (case 1), or a different process sched- effects (via an affine write token) and read effects (viaaffine uling choice (case 2). In either case, there exists a renaming read endpoints) of processes. The proofs of type soundness, of any choice made to reach 퐶2, captured by function 푓 . By whose statements we discuss next, establish the validity of composing multiple uses of this theorem, and the renaming these invariants. These language-level invariants support functions that they construct, we prove a multi-step notion confluence theorems, also stated below. These theorems in- of confluence that reduces a single configuration 퐶 to two clude full confluence: Any two full reductions of a configu- equivalent terminal configurations, 퐶1 and 퐶2: ration yield a pair of equivalent configurations (isomorphic, up to a renaming of nondeterministic name choices). Theorem 4.4 (Full confluence). For all well-typed configura- tions퐶, if퐶 −→∗ 퐶 and퐶 −→∗ 퐶 and퐶 term and퐶 term, 4.1 Type Soundness 1 2 1 2 then there exists renaming function 푓 such that 퐶1 = 푓 (퐶2). We prove type soundness of ILC via mostly-standard notions of progress and preservation. To state these theorems, we The proofs of these statements can be found in the appen- follow the usual recipe, except that we give a special defini- dix. tion of program termination that permits deadlocks. (Recall that ILC is concerned with enforcing confluence as its central 5 Implementation metatheoretic property, not deadlock freedom.) Informally, 퐶 term holds when either: Using this on-paper design as a guide, we have implemented an ILC interpreter in Haskell, which at present consists of 퐶 퐶 1. is fully normal: Every process in is normalized (con- 2.3K source lines of code. The implementation of ILC and sists of a value), or our concrete implementation of the UC framework called 퐶 2. is (at least partially) deadlocked: Some (possibly empty) SaUCy (Section6) are publicly available. Access to the latest 퐶 portion of is normal, and there exists one or more read- developments can be found here: 퐶 ing processes in , or there exists one or more writing https://github.com/initc3/SaUCy. processes in 퐶, however, no reader-writer process pair exists for a common channel. 6 SaUCy We also extend the type system given in Section 3.2 with typing rules for configurations, including process pool typ- Using ILC, we build a concrete, executable implementation ings Φ from process names 푝 to types 푈 . These details, along of a simplified UC framework, dubbed SaUCy. Then, we with the proofs of progress and preservation, can be found demonstrate the versatility of SaUCy in three ways: in the appendix. 1. We define a protocol composition operator and prove its Theorem 4.1 (Progress). If Ψ ⊢ 퐶 : Φ, then either 퐶 term or associated composition theorem. there exists 퐶 ′ such that 퐶 −→ 퐶 ′. 2. We walk through an instantiation of UC commitments. 3. We use ILC’s type system to reason about “reentrancy,” a Theorem 4.2 (Preservation). If Ψ ⊢ 퐶 : Φ and 퐶 −→ 퐶 ′, subtle definitional issue in UC that has only recently been then there exists Ψ′ ⊇ Ψ and Φ′ ⊇ Φ such that Ψ′ ⊢ 퐶 ′ : Φ′. studied. 8 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

6.1 Probabilistic Polynomial Time in ILC things later, we define a partial order 푒1 ≤ 푒2, which captures 푒 푒 The goal of cryptography reduction is to relate every bad that 2 must be PPT if 1 is PPT, and if so, that their value event in a protocol to a probabilistic polynomial time compu- distributions are statistically similar. tation that solves a hard problem. The ILC typing rules do not PPT 푒1 =⇒ (PPT 푒2 and 퐷(푒1) ∼ 퐷(푒2)) indist guarantee termination, let alone polynomial time normaliza- 푒 ≤ 푒 tion, so we must tackle this in metatheory. Also, since ILC 1 2 is effectively deterministic (confluent), we will need toex- 6.2 SaUCy Execution Model press random choices some other way. To meet these needs, The implementation of SaUCy is centered around a definition we define a judgment about ILC terms that take a security of the UC execution model in ILC. For space and readability, parameter and a stream of random bits. we elide endpoint allocation/distribution with ellipses. We Definition 6.1 (Polynomial time normalization). The judg- also abbreviate the type signature (e.g., 퐴z is the type of z). ment that 푒 is polynomial time normalizable, written PPT 푒, More details can be found in the appendix. is defined as follows: execUC :: ∀ ... . 퐴z→w 퐴p × 퐴q → 퐴f → 퐴a → ·; · ⊢ 푒 : → [ ] → Nat Bit Bit Crupt → Nat → [Bit] → Bit ∀ 푘 ∈ Nat. ∀ 푟 ∈ [Bit]poly(푘) . 푒 푘 푟 →poly(푘) 푣 ppt let execUC z (p,q) f a crupt k r = PPT 푒 휈 ... . let (rf,ra,rp,rq,rz) = splitBits r in This says that if for all security parameters 푘 and all bitstrings f k rf crupt ... 푟 (of length polynomial in 푘) the term 푒 푘 푟 normalizes to a |▷ a k ra crupt ... value 푣 in poly(푘) steps, then PPT 푒. |▷ corruptOrNot p k rp (crupt == CruptP) ... Here, we have chosen a simple definition of polynomial |▷ corruptOrNot q k rq (crupt == CruptQ) ... time defined only for closed terms (i.e., an entire systemof |▷ z k rz ... ITMs), and that requires polynomial time normalization for The function execUC takes as argu- every choice of random bits, not just in expectation or with ments an environment z, a pair of pro- B | Z high probability. tocol processes (p, q), a functionality We note that most UC variants use a more nuanced def- f, an adversary a, a corruption model inition in which the individual ITM entities, such as the crupt, a security parameter k, and a ran- environment or protocol, can be judged polynomial time in- dom bitstring r. At a high level (ignor- A F dependently of their surrounding context [3, 16, 27]. Looking ing details related to corruptions for ahead to Section 6.3, this choice will constrain our defini- now), it runs each of the processes (al- Figure 6. execUC. tion of secure protocol emulation. Hofheinz et al. [28] give a locating random bits to each of them) and connects channels detailed discussion of subtle issues arising with various poly- as illustrated in Figure6. (The protocol processes p and q nomial time definitions and their consequences for defining correspond to 휋푃 and 휋푄 , respectively.) The execution is cen- UC security. Regardless, the present notion suffices for our tered on the environment z in the sense that z first gets the examples. We consider this issue complementary to the de- write token (notably, it has type Nat→w · · · → Bit), and the sign of ILC itself, and adapting other notions of polynomial experiment concludes when z returns a single bit value. time to ILC as important future work. As an example, the Next, we explain some of our main modeling choices and polynomial time notion used in IITMs [3] relies on a dis- the consequences they have for the ILC implementation. tinction between “invited” and “uninvited” messages, which To start with, we make several simplifications to standard could be captured through refinement types à la the RCF UC, for example, focusing on the special case of two-party calculus [12]. protocols (à la Simplified UC [18]). We also only aim to show Definition 6.2 (Value Distribution). Because processes are the case of static corruptions, in which the corrupt parties are confluent, we know that if 푒 푘 푟 →∗ 푣, then the value 푣 is determined at the onset. This is achieved by parameterizing unique. We can therefore define the probability distribution the entire experiment by a value crupt : Crupt denoting ensemble 퐷(푒) = {퐷푒,푘 }푘 based on a uniform distribution which parties are corrupt (if any). The data type Crupt is 푈푘 over 푘-bit strings 푟, so the distribution 퐷푒,푘 is given as defined as follows. Õ ∗ data Crupt = CruptP | CruptQ | CruptNone 퐷푒,푘 (푣) = 푈푘 (푟), for 푅 = {푟 | 푒 푘 푟 → 푣}. 푟 ∈푅 For a more general model with adaptive corruptions, execUC Definition 6.3 (Indistinguishability). What remains is to would need to accept requests from the environment to add define a notion of indistinguishability for value distributions. to the crupt list as the execution proceeds. However, we need to clarify when polynomial time normal- Our corruption model is Byzantine, meaning the adver- ization is an assumption or a proof obligation. To simplify sary gets to exert complete control over the corrupted parties. 9 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

For each party, depending on the value of crupt, either we Unfortunately this simple definition turns out to be vacu- run a copy of the honest party, or connect the channels to ous: a degenerate protocol 휋 can emulate anything simply the adversary. This is implemented in the function corrup- failing to be PPT, e.g., by diverging. To put it another way, tOrNot. the problem is the definition imposes a proof obligation on the simulator S but not on 휋. What we want to say is that fwd :: ∀ a b . Wr a → Rd a ⊸ b the real world protocol (휋, F ) must be well behaved when- letrec fwd toR frS = 1 ever the ideal world (휙, F ) is. However, even a reasonable → 2 let (!msg, frS) = rd frS in wr msg toR ; fwd toR frS protocol can result in non-PPT executions if paired with a 퐴 corruptOrNot :: ∀ ... . p → Nat → [Bit] → Bool → · · · divergent environment. To solve this problem, we define pro- let corruptOrNot p k bits iscrupt toZ toF toA toQ tocol emulation by requiring a simulation in both directions, frZ frF frA frQ = so every behavior in the ideal world must correspond to a if iscrupt then behavior in the real world and vice versa. let _ = rd frZ in error "Z can't wr to corrupt" Definition 6.4 (Protocol Emulation). The judgment that one |▷ fwd toA frF protocol-functionality pair (휋, F1) securely emulates another | ▷ fwd toA frQ (휙, F2) (as proven by the simulators SR, SI) is defined as |▷ fwd toF frA ∀ Z. execUC Z 휙 F2 1A ≤ execUC Z 휋 F1 SR else execUC Z 휋 F1 1A ≤ execUC Z 휙 F2 SI p k bits toZ toF toQ frZ frF frQ emulate SR, SI ⊢ (휋, F1) ≈ (휙, F2) The fwd function simply forwards messages received on the read endpoint frS to the write endpoint toR. In corruptOrNot, We remark this definition goes against the UC convention of if a party is corrupted, messages from the functionality and requiring simulation in one direction only. One direction is the other protocol party are forwarded to the adversary; mes- preferable intuitively because it should be fine if the protocol sages from the adversary are forwarded to the functionality. is even more secure than its specification. This does not Otherwise, the party is run as normal. pose any problem for our commitment example; however, We also model a strong form of communication channels a protocol that leaks even less information than its ideal between the parties: 푃 and 푄 are connected by a pair of raw functionality requires would be impossible to prove secure ILC channels. Communication over these channels happens under this definition. In any case, the benefit is this simplifies immediately, without activating the adversary or leaking the polynomial time notion: vacuous protocols are clearly even the existence of the message. In a more realistic model, ruled out by the top condition, and both simulations are only the parties would only be able to communicate over a net- required to be PPT when the environment Z is well-behaved. work channel modeled as a functionality, F or F [16]. smt syn 6.4 A Composition Theorem in SaUCy Consequently our Fcom functionality would need to be weak- ened by leaking some (model-specific) information about the As a first demonstration of SaUCy, we work through the message to the adversary. development of a composition operator, and give a theorem explaining its use. 6.3 Defining UC Security in ILC Definition 6.5 (UC realizes). To set out, we introduce the The central security definition in UC is protocol emulation. notation of “realizes,” which views a protocol as a way of 휋 휙 The guiding principle is that emulates if the environ- instantiating a specification functionality F2 from a setup ment cannot distinguish between the two protocols. Our first assumption functionality F1, attempt is the following, where S is the simulator that trans- (휋, F1) ≈ (id휋, F2) lates every attack in the real world into an attack expressed 휋 realizes in the ideal world: F1 −→F2 . 휋 1 휙 ∀ Z execUC Z F1 A ≤ execUC Z F2 S where id휋 is the dummy protocol, which simply relays mes- emulate sages between the environment and the functionality. This S ⊢ (휋, F1) ≈ (휙, F2) notation is convenient because it suggests a categorical ap- To remark on a few notational choices: We make the func- proach to composition. tionality explicit, so emulation is a relationship between protocol-functionality pairs. Here, 1A is the dummy adver- Theorem 6.1 (Composition Theorem). 휋 휌 sary, which just relays messages between the environment F1 −→F2 F2 −→F3 and the parties/functionality. We elide the standard dummy 휌 휋 F −−−−−→F◦ lemma that shows this is without loss of generality; the intu- 1 3 ition is that whatever an adversary can do, the environment The idea is that the 휌 ◦ 휋 can be defined in a natural way, can achieve using 1A. where the ideal functionality channel of 휌 is connected to 10 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

abstraction. Some security properties require a generalized Z Z notion of ideal functionality that the environment can inter- act with directly. All the above motivate the development of the ILC core calculus as a flexible foundation; developing 2 them in ILC is important future work. A F A F1 let (◦) (휌푃 , 휌푄 )(휋푃 , 휋푄 ) 6.5 Instantiating UC Commitments w휌P2Z w휌Q 2Zw 휌P2F w휌Q 2F We next walk through an instantiation of UC commitments w휌P2휌Q w휌Q 2휌P rZ2휌P rZ2휌Q (à la Canetti and Fischlin [19]). Instantiation proofs in SaUCy rF2휌P rF2휌Q r휌Q 2휌P r휌P2휌Q = follow a standard rhythm. We start with a security definition F 휈 ... . 휋푃 w휋P2휌P w휌P2Fw 휋P2휋Q r휌P2휋P rF2휌P r휋Q 2휋P as an ideal functionality (such as com), give the protocol, construct a simulator, and finally complete the relational |▷ 휋푄 w휋Q 2휌Q w휌Q 2Fw 휋Q 2휋P r휌Q 2휋Q rF2휌Q r휋P2휋Q analysis on paper. |▷ 휌푃 w휌P2Zw 휌P2휋P w휌P2휌Q rZ2휌P r휋P2휌P r휌Q 2휌P While commitments are one of the simplest UC primitives, |▷ 휌 w휌 2Zw 휌 2휋 w휌 2휌 rZ2휌 r휋 2휌 r휌 2휌 푄 Q Q Q Q P Q Q Q P Q as a case study, this serves two main purposes. First, the proof demonstrates several representative UC techniques [36], in Figure 7. Protocol composition operator. particular the simulator makes use of a “trusted setup” and extracts inputs from a corrupt sender. Second, the protocol the environment channel of 휋, as illustrated and defined in makes use of computational primitives and thus requires a Figure7. reduction step in the proof, which can go through because of ILC’s confluent design. Proof. To prove the theorem we construct the simulators Extending ILC with cryptographic primitives. The UC 푆R,휌 ◦ 푆R,휋 (respectively 푆I,휌 ◦ 푆I,휋 ) in the natural way as well (see the appendix). Our proof obligation is to introduce commitment protocol makes use of a cryptographic prim- an arbitrary environment Z and conclude itive, namely a trapdoor pseudorandom generator. This is provided by extending ILC with new syntactic forms, along 휌 휋 1 1 . execUC Z( ◦ )F1 A ≤ execUC Z 휋 F3 (SI,휌 ◦ SI,휋 ) with their static and dynamic semantics (given in the ap- The main idea is to notice that that we can bring 휌 from pendix). While in a symbolic setting we would instantiate the composed protocol into the environment as (Z ◦ 휌), re- these with algebraic data, in ILC we give the stepping rule flecting the fact that the environment is meant to represent in terms of an arbitrary pseudorandom function family, i.e., arbitrary outer protocols. This transformation results in an the actual computational definition. This can be instantiated equivalent term, given that ILC configurations are invariant concretely for execution (e.g., with an RSA-based function) to channel renaming and reordering of processes in a config- or treated abstractly in the metatheory when we get to the uration (as in Section4). The following derivation completes reduction step of the proof. the proof: The commitment protocol also relies on a “trusted setup,” or common reference string (CRS), which is essentially public 휌 휋 1 execUC Z( ◦ )F1 A parameters generated ahead of time. The common reference ≡ execUC (Z ◦ 휌) 휋 F1 1A (By equivalence) string is modeled as an ideal functionality Fcrs (implemented 휋 in ILC as fCrs in the appendix). ≤ execUC (Z ◦ 휌) id휋 F2 SI,휋 (From F1 −→F2)

≡ execUC (SI,휋 ◦ Z) 휌 F2 1A (By equivalence) Commitment Protocol. We implement the commitment 휌 protocol by Canetti and Fischlin [19] in ILC as follows: ≤ execUC (SI,휋 ◦ Z) id휋 F3 SI,휌 (From F2 −→F3) ≡ execUC Z id휋 F3 (SI,휋 ◦ SI,휌 ) (By equivalence) committer :: ∀ ... . Nat → [Bit] → · · · ⊸ 1

The remaining case for SR,휌 ◦ SR,휋 is symmetric. □ let committer k bits crupt toZ toF toQ frZ frF frQ = let (!(Commit b), frZ)= rd frZ in Other notions of composition. Our composition operator wr GetCRS → toF ; above is just a starting point. The “universal composition” [16] let (!(PublicStrings 휎 pk pk ), frF) = rd frF in operator essentially multiplexes sessions identified by unique 0 1 let in tags (session ids), while a joint state composition theorem col- r = take k bits lapses multiple subroutines into one [20]. Despite its name, let x = if b == 0 then prg pk0 r 휎 development in UC often involves defining additional compo- else xors (prg pk1 r) in sition operators. For example, interesting composition often wr Commit' x → toQ ; happens “in the functionality” through higher order “wrap- let (!Open, frZ)= rd frZ in per” functionalities [29, 31] which we would express through wr (Open' b r) → toQ 11 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

let simI k bits crupt toZ toF toP toQ frZ frF frP frQ = receiver :: ∀ ... . Nat → [Bit] → · · · ⊸ 1 let (pk0,td0) = kgen k in let receiver k bits crupt toZ toF toP frZ frF frP = let (pk1,td1) = kgen k in ( ) let !(Commit' x), frP = rd frP in let (r0, bits) = sample k bits in → wr GetCRS toF ; let (r1, bits) = sample k bits in let (!(PublicStrings 휎 pk pk ), frF) = rd frF in 휎 0 1 let = xors (prg pk0 r0) (prg pk1 r1) in wr Receipt → toZ ; match crupt with let (!(Open' b r), frP) = rd frP in | CruptP ⇒ if (b == 0 && x == prg pk0 r) || let (!GetCRS, frZ) = rd frZ in (b == 1 && x == xors (prg pk r) 휎) 휎 1 wr (X2Z (PublicStrings pk0 pk1)) →toZ ; then wr (Opened b) → toZ let (!(A2P (Commit' y)), frZ) = rd frZ in else error "Cannot occur in honest case." if check td0 pk0 y then wr (Commit 0) → toP else To briefly summarize what is going on: The setup CRSfunc- if check td1 pk (xors y 휎) then 휎 1 tionality fCom samples a random string and two trapdoor wr (Commit 1) → toP pseudorandom generator (PRG) keys pk0 and pk1. To commit else error "Fail" ; to 푏, the committer produces a string 푦 that is the result of let (!(A2P (Open' b r)), frZ) = rd frZ in applying one or the other of the PRGs, and if 푏 = 1 addition- if b == 0 && y == prg pk r || ally applying xor with 휎. The intuitive explanation why this 0 휎 is hiding is that without the trapdoor, it is difficult to tell b == 1 && y == xors (prg pk1 r) whether a random 4푘-bit string is in the range of either PRG. then wr Open → toP To open the commitment, the committer simply reveals the else error "Fail" preimage and the receiver checks which of the two cases | ... applies. The intuitive explanation why this is binding is that it is difficult to find a pair 푦,푦 ⊕ 휎 that are respectively in Figure 8. Ideal world simulator (excerpt) for UC commit- the range of both PRGs. ment (full version in appendix).

Defining the simulator. The SaUCy proof consists of two simulators, one for the ideal world and one for the real world. Proof Sketch. Consider the following ensembles: The ideal world simulator is ported directly from the UC 퐷 R = 퐷(execUC Z(committer, receiver) fCrs dummyA) literature [19]. The nonstandard real world simulator, given 퐷 ′ = 퐷( Z( , ) ) in the appendix, is trivial, but necessary because our protocol R execUC committer receiver bCrs dummyA emulation definition requires simulation in both directions. 퐷I = 퐷(execUC Z(dummyP, dummyQ) fCom simI) The ideal world simulator generates its own “fake” CRS for The ensemble 퐷 is over the output of Z in a real world which it stores the trapdoors. The string 휎 is not truly ran- R execution. The ensemble 퐷 ′ is similar, except Z runs with dom, but instead is the result of combining two evaluations R a bad functionality bCrs (see appendix) that computes fake of the PRGs. In Figure8, we show the case that the committer public strings in the same way that the simulator does. The 푃 is corrupt (the other case is in the appendix). The simu- ensemble 퐷 is over the output of Z in an ideal world execu- lator is activated when Z sends a message (Commit' y); in I tion. The goal is to show that 퐷 ∼ 퐷 . The proof proceeds the real world, this is relayed by the dummy adversary to R I by first showing that breaking the pseudorandomness ofthe Q, who outputs Receipt back to the environment. Hence to PRG reduces to distinguishing between 퐷 and 퐷 ′ (hence, achieve the same effect in the ideal word, the simulator must R R 퐷 ∼ 퐷 ′ ), and then by showing that breaking the pseu- send (Commit b) to F . To extract b from y, the simulator R R com dorandomness of the PRG also reduces to distinguishing makes use of the PRG trapdoor check which one has y in its between 퐷 ′ and 퐷 (hence, 퐷 ′ ∼ 퐷 ). By the transitivity range. It is necessary to argue by cryptographic reduction R I R I of indistinguishability, we have that 퐷 R ∼ 퐷I. □ that this simulation is sound, which we do next. Here, ILC’s confluence property plays a critical role: Itis 퐷 퐷 ′ Relational argument. The goal of the relational analysis necessary for defining the probability ensembles R, R, is to show that an environment’s output in the real world and 퐷I, without which we would not be able to obtain a is indistinguishable from its output in the ideal world. The reduction from some computationally hard problem to dis- proof follows the one in Canetti and Fischlin [19]. tinguishing the real world and ideal world ensembles. 12 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

6.6 Reentrancy in SaUCy Ultimately, Camenisch et al. propose a different strategy, Camenisch et al. [14] recently identified subtleties in defining which is to restrict how the environment/adversary respond UC ideal functionalities (related to reentrancy and the sched- to certain “urgent” messages that are used to exchange meta- uling of concurrent code) such that several functionalities in information (modeling related messages). That is, upon re- 푃 the literature are ambiguous as ITMs. Although concerning, ceiving an urgent message from process , the environment 푃 these issues have no cryptographic flavor, and so they are (or adversary) must return control back to immediately. better addressed from a PL standpoint. To illustrate, consider Modeling this solution is left as future work, but ILC provides the following (untypeable) ILC process reentrantF, which an ideal starting point—restrictions on the environment/ad- allows an adversary A to control the delivery schedule of versary could be expressed by behavior refinements: upon 푃 messages from 푃 to 푄 (i.e., an asynchronous channel): receiving an urgent message from , the environment (or adversary) must not send a message on its other channels loop :: ∀ a b . (a → b) → Rd a ⊸ b before sending a message to 푃. letrec loop f frS = let (!v, frS) = rd frS in f v; loop f frS let reentrantF ... frP frA = 7 Related Work loop (휆 msg . (let (!Ok, frA) = rd frA in wr msg → toQ) 7.1 Process Calculi |▷ wr msg → toA) frP Process calculi have a long and rich history. ILC occupies After receiving input from party 푃, it notifies the adver- a point in this space that is particularly suited to faithfully sary, then forks a background thread to wait for Ok before capturing interactive Turing machines (and hence, computa- delivering the message. This introduces a race condition: tional cryptography), but plenty of existing calculi are also cryptographically-flavored and/or enjoy similar properties Suppose input message 푚1 is sent by 푃, but then A, before sending Ok, instead returns control to Z, which passes 푃 to ILC. We survey some of them here. 푚 a second input 2. Now there are two queued messages. With symbolic semantics. Two early adaptations of pro- Which one gets delivered when the adversary sends Ok? cess calculi for reasoning about cryptographic protocols To resolve this issue, notice that reentrantF is untypeable were the spi calculus [2] and the applied 휋-calculus [1], both in ILC. The race condition occurs because the read endpoint of which extend the 휋-calculus with cryptographic opera- frA is duplicated (appears free in an unrestricted function). tions [43]. Symbolic UC [10] is a simulation-based security Camenisch et al. [14] identified several strategies for resolv- framework in this setting. However, protocols proven se- ing this problem in UC, which in turn are expressible ILC. cure in the symbolic setting may not be realizable with any One approach is to make the process explicitly sequential, cryptographic primitives based on hardness assumptions. such that the arrival of a second message before the first is delivered causes execution to get stuck: With computational semantics. Naturally, ensuing work has turned to bridging the gap between this PL-style of for- letrec sequentialF ... frP frA = malization and the computational model of cryptography by let (!msg, frP) = rd frP in outfitting these calculi with a computational semantics. Lin- → wr msg toA ; coln et al. [35] give a computational semantics to a variant of let (!Ok, frA) = rd frA in the 휋-calculus, which allows one to define communicating wr msg → toQ ; probabilistic polynomial-time processes; Mateus et al. [38] sequentialF ... frP frA adapts their calculus to explore (sequential) compositionality properties in protocols. A drawback of these protocols is that Alternatively, we may discard such messages arriving out they embed probabilistic choices directly into the definition— of order, returning them to sender; we express this in ILC essentially when faced with nondeterminism, each path has using the external choice operator: equal probability. Laud [33] gives a computational semantics letrec discardingF ... frP frA = to the spi calculus, which additionally includes a type system let (!msg, frP) = rd frP in for ensuring well-typed protocols preserve the secrecy of wr msg → toA ; messages given to it by users. letrec iloop () frP frA = With confluence. There are a number of other process cal- choice culi that enjoy confluence. Berger et al.6 [ ] describe a type | (_,frP,frA)@(rd frP) ⇒ wr Discard → toP ; system for capturing deterministic (sequential) computation iloop () frP frA in the 휋-calculus. The type system uses affineness and state- | (_,frP,frA)@(rd frA) ⇒ wr msg → toQ ; less replication to achieve deterministic computation. Fowler discardingF ... frP frA et al. [24] present a core linear lambda calculus with (binary) in iloop () frP frA session-typed channels and exception handling that enjoys 13 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller confluence and termination. The calculus only considers two- difference from vanilla UC[16] is that the set of parties is party protocols, so for our multiparty setting, ILC requires a fixed, which greatly simplifies polynomial time reasoning sophisticated type system to achieve confluence. and protocol composition while maintaining the same strong properties. We follow this in our execUC implementation. 7.2 Tools for Cryptographic Analysis Computer-aided tools for cryptographic analysis operate in 8 Conclusion and Future Work either the symbolic model or the computational model. The The universal composability (UC) framework is widely used survey by Blanchet [8] highlights some of their differences. in cryptography for proofs. SaUCy takes a step towards mech- Symbolic tools include the NRL protocol analyzer [41], anizing UC as a programming framework for constructing Maude-NPA [23], and Proverif [9]. In the symbolic setting, and analyzing large systems. We envision using SaUCy to cryptographic operations are abstracted as term algebras tackle, for example, applications involving blockchains and 휋 (a variant of the applied -calculus in the case of Proverif), smart contracts [21, 22, 42], which comprise an array of cryp- and adversary capabilities are nondeterministic applications tography and distributed computing components and suffer of deduction rules over these terms. Here, nondetermin- from increasingly unwieldy formalisms. ism allows the adversary to find attack traces (if there are We can view ILC typechecking of simulators in SaUCy as any), whereas the presence of nondeterminism in the com- a partial mechanization of UC proofs, though the indistin- putational setting would frustrate cryptographic reduction guishability analysis is still on paper. Even partial mecha- proofs. nization is useful for catching bugs; we imagine using SaUCy Computational tools include CertiCrypt [5], EasyCrypt [4], ∗ to systematically implement functionalities and protocols CryptoVerif [7], Cryptol [34], and F [45]. These tools focus from the literature and fuzz test them. Future work would on game-based security, which, in contrast to simulation- be to embed ILC within a mechanized proof system, such as based definitions (such as UC), only guarantee security ina F∗ or EasyCrypt. standalone setting (no composition guarantees). While they are not specifically purposed for simulation-based proofs, it Acknowledgements would be interesting to embed ILC into EasyCrypt or F∗ to use their tooling. We thank our shepherd, Amal Ahmed, and the anonymous reviewers for their valuable feedback. We also thank Marco 7.3 Variations of Universal Composability Patrignani for pointing out an error in an earlier version of A number of models for universal composability have been the paper. This material is based on work supported by the proposed in the literature [3, 10, 13–18, 20, 27, 39, 40, 44]. National Science Foundation under Grant No. 1801321 and a We highlight a few that have similar goals to ours. Graduate Research Fellowhip. In contrast with UC, which uses ITMs as its computational model, the reactive simulatability framework (RSIM) [3] uses References probabilistic IO automata, which are amenable to automated [1] Martín Abadi and Cédric Fournet. 2001. Mobile values, new names, reasoning. In contrast with RSIM, ILC is intended to be the and secure communication. In ACM Sigplan Notices, Vol. 36. ACM, basis for a convenient and flexible programming language 104–115. [2] Martın Abadi and Andrew D Gordon. 1999. A calculus for crypto- to which we can easily port existing UC pseudocode. graphic protocols: The spi calculus. Information and computation 148, Models based on inexhaustible interactive Turing ma- 1 (1999), 1–70. chines (IITMs) [15, 32] aim to address drawbacks of UC [3] Michael Backes, Birgit Pfitzmann, and Michael Waidner. 2007. The models for which polynomial time ITMs can be “exhausted” reactive simulatability (RSIM) framework for asynchronous systems. (by having other machines send useless messages, forcing Information and Computation 205, 12 (2007), 1685–1720. [4] G. Barthe, B. Grégoire, S. Heraud, and S. Béguelin. 2011. Computer- them to halt). In turn, models with exhaustible ITMs are less aided security proofs for the working cryptographer. In Proceedings of expressive. Because IITMs maintain the “single-threaded” the International Conference on the Theory and Applications of Crypto- execution semantics of ITMs, ILC can be used to build a graphic Techniques (EUROCRYPT). concrete programming model for IITM-based frameworks [5] Gilles Barthe, Benjamin Grégoire, and Santiago Zanella Béguelin. 2009. as well. Formal certification of code-based cryptographic proofs. ACM SIG- PLAN Notices 44, 1 (2009), 90–101. The abstract cryptography framework [40] advocates a [6] Martin Berger, Kohei Honda, and Nobuko Yoshida. 2001. Sequential- top-down approach: developing theory at an abstract level ity and the 휋-calculus. In International Conference on Typed Lambda (ignoring low level details such as computational models Calculi and Applications. Springer, 29–45. and complexity notions) to simplify definitions. While we [7] Bruno Blanchet. 2007. CryptoVerif: Computationally sound mecha- stick to a bottom-up approach, we aim to simplify UC via PL nized prover for cryptographic protocols. In Dagstuhl seminar “Formal Protocol Verification Applied. 117. formalisms. [8] Bruno Blanchet. 2012. Security protocol verification: Symbolic and Simplified universal composability (SUC) [18] gives a sim- computational models. In Proceedings of the First international confer- pler and restricted variant of the UC framework. The main ence on Principles of Security and Trust. Springer-Verlag, 3–29. 14 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

[9] Bruno Blanchet, V Cheval, X Allamigeon, and B Smyth. 2010. [28] Dennis Hofheinz, Dominique Unruh, and Jörn Müller-Quade. 2013. Proverif: Cryptographic protocol verifier in the formal model. URL Polynomial runtime and composability. Journal of Cryptology 26, 3 http://prosecco. gforge. inria. fr/personal/bblanche/proverif (2010). (2013), 375–441. [10] Florian Böhl and Dominique Unruh. 2016. Symbolic universal com- [29] Jonathan Katz. 2007. Universally composable multi-party computation posability. Journal of Computer Security 24, 1 (2016), 1–38. using tamper-proof hardware. In Annual International Conference on [11] Gilles Brassard, David Chaum, and Claude Crépeau. 1988. Minimum the Theory and Applications of Cryptographic Techniques. Springer, disclosure proofs of knowledge. J. Comput. System Sci. 37, 2 (1988), 115–128. 156–189. [30] Naoki Kobayashi, Benjamin C Pierce, and David N Turner. 1999. Linear- [12] Michele Bugliesi, Stefano Calzavara, Fabienne Eigner, and Matteo Maf- ity and the pi-calculus. ACM Transactions on Programming Languages fei. 2015. Affine refinement types for secure distributed programming. and Systems (TOPLAS) 21, 5 (1999), 914–947. ACM Transactions on Programming Languages and Systems (TOPLAS) [31] Ahmed Kosba, Andrew Miller, Elaine Shi, Zikai Wen, and Charalampos 37, 4 (2015), 11. Papamanthou. 2016. Hawk: The blockchain model of cryptography [13] Jan Camenisch, Manu Drijvers, and Björn Tackmann. [n. d.]. Multi- and privacy-preserving smart contracts. In 2016 IEEE symposium on Protocol UC and its Use for Building Modular and Efficient Protocols. security and privacy (SP). IEEE, 839–858. ([n. d.]). [32] Ralf Kusters. 2006. Simulation-based security with inexhaustible inter- [14] Jan Camenisch, Robert R Enderlein, Stephan Krenn, Ralf Küsters, and active turing machines. In Computer Security Foundations Workshop, Daniel Rausch. 2016. Universal composition with responsive environ- 2006. 19th IEEE. IEEE, 12–pp. ments. In International Conference on the Theory and Application of [33] Peeter Laud. 2005. Secrecy types for a simulatable cryptographic Cryptology and Information Security. Springer, 807–840. library. In Proceedings of the 12th ACM conference on Computer and [15] Jan Camenisch, Stephan Krenn, Ralf Küsters, and Daniel Rausch. [n. communications security. ACM, 26–35. d.]. iUC: Flexible Universal Composability Made Simple (Full Version). [34] Jeffrey R Lewis and Brad Martin. 2003. Cryptol: High assurance, ([n. d.]). retargetable crypto development and validation. In Military Communi- [16] R. Canetti. 2001. Universally composable security: A new paradigm cations Conference, 2003. MILCOM’03. 2003 IEEE, Vol. 2. IEEE, 820–825. for cryptographic protocols. In Proceedings of the Symposium on Foun- [35] Patrick Lincoln, John Mitchell, Mark Mitchell, and Andre Scedrov. dations of Computer Science (FOCS). 1998. A probabilistic poly-time framework for protocol analysis. In [17] Ran Canetti, Ling Cheung, Dilsun Kaynar, Moses Liskov, Nancy Lynch, Proceedings of the 5th ACM conference on Computer and communications Olivier Pereira, and Roberto Segala. 2008. Analyzing security protocols security. ACM, 112–121. using time-bounded task-PIOAs. Discrete Event Dynamic Systems 18, 1 [36] Yehuda Lindell. 2017. How to simulate it–a tutorial on the simulation (2008), 111–159. proof technique. In Tutorials on the Foundations of Cryptography. [18] Ran Canetti, Asaf Cohen, and Yehuda Lindell. 2015. A simpler variant of Springer, 277–346. universally composable security for standard multiparty computation. [37] Yehuda Lindell and Jonathan Katz. 2014. Introduction to modern cryp- In Annual Cryptology Conference. Springer, 3–22. tography. Chapman and Hall/CRC. [19] Ran Canetti and Marc Fischlin. 2001. Universally composable com- [38] Paulo Mateus, J Mitchell, and Andre Scedrov. 2003. Composition of mitments. In Annual International Cryptology Conference. Springer, cryptographic protocols in a probabilistic polynomial-time process 19–40. calculus. In International Conference on Concurrency Theory. Springer, [20] Ran Canetti and Tal Rabin. 2003. Universal composition with joint state. 327–349. In Annual International Cryptology Conference. Springer, 265–281. [39] Ueli Maurer. 2011. Constructive cryptography–a new paradigm for [21] Stefan Dziembowski, Lisa Eckey, Sebastian Faust, and Daniel Mali- security definitions and proofs. In Theory of Security and Applications. nowski. [n. d.]. Perun: Virtual payment channels over cryptographic Springer, 33–56. currencies. Technical Report. [40] Ueli Maurer and Renato Renner. 2011. Abstract cryptography. In In [22] Stefan Dziembowski, Sebastian Faust, and Kristina Hostáková. 2018. Innovations in Computer Science. Citeseer. General State Channel Networks. In Proceedings of the 2018 ACM [41] Catherine Meadows. 1996. The NRL protocol analyzer: An overview. SIGSAC Conference on Computer and Communications Security. ACM, The Journal of Logic Programming 26, 2 (1996), 113–131. 949–966. [42] Andrew Miller, Iddo Bentov, Ranjit Kumaresan, and Patrick McCorry. [23] Santiago Escobar, Catherine Meadows, and José Meseguer. 2009. 2017. Sprites: Payment channels that go faster than lightning. CoRR Maude-NPA: Cryptographic protocol analysis modulo equational prop- abs/1702.05812 (2017). erties. In Foundations of Security Analysis and Design V. Springer, 1–50. [43] Robin Milner. 1999. Communicating and mobile systems: the pi calculus. [24] Simon Fowler, Sam Lindley, J Garrett Morris, and Sára Decova. 2018. Cambridge university press. Session Types without Tiers. (2018). [44] Birgit Pfitzmann and Michael Waidner. 2001. A model for asynchro- [25] Simon J Gay and Vasco T Vasconcelos. 2010. Linear type theory for nous reactive systems and its application to secure message transmis- asynchronous session types. Journal of Functional Programming 20, 1 sion. In Security and Privacy, 2001. S&P 2001. Proceedings. 2001 IEEE (2010), 19–50. Symposium on. IEEE, 184–200. [26] Oded Goldreich, Silvio Micali, and Avi Wigderson. 1987. How to [45] N. Swamy, C. Hriţcu, C. Keller, A. Rastogi, A. Delignat-Lavaud, S. Forest, play any mental game. In Proceedings of the nineteenth annual ACM K. Bhargavan, C. Fournet, et al. 2016. Dependent types and multi- symposium on Theory of computing. ACM, 218–229. monadic effects in F∗. In Proceedings of the Symposium on Principles of [27] Dennis Hofheinz and Victor Shoup. 2015. GNUC: A new universal Programming Languages (POPL). composability framework. Journal of Cryptology 28, 3 (2015), 423–508.

15 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

A Algorithmic Typing Rules

Δin; Γ ⊢ 푒 : 푈 ⊣ Δout Under input contexts Δin and Γ, expression 푒 has type 푈 and output context Δout.

uvar avar unit Δ; Γ, 푥 : 퐴 ⊢ 푥 : 퐴 ⊣ Δ Δ, 푥 : 푋; Γ ⊢ 푥 : 푋 ⊣ Δ Δ; Γ ⊢ ( ) : 1 ⊣ Δ

Δ1; Γ ⊢ 푒1 : 퐴1 ⊣ Δ2 Δ1; Γ ⊢ 푒1 : 푆1 ⊣ Δ2 Δ1; Γ ⊢ 푒1 : 푋1 ⊣ Δ2 Δ2; Γ ⊢ 푒2 : 퐴2 ⊣ Δ3 Δ2; Γ ⊢ 푒2 : 푆2 ⊣ Δ3 Δ2; Γ ⊢ 푒2 : 푋2 ⊣ Δ3 upair spair apair 푒 , 푒 퐴 퐴 푒 , 푒 푆 푆 푒 , 푒 푋 푋 Δ1; Γ ⊢ ( 1 2)∞ : 1 × 2 ⊣ Δ3 Δ1; Γ ⊢ ( 1 2)w : 1 × 2 ⊣ Δ3 Δ1; Γ ⊢ ( 1 2)1 : 1 ⊗ 2 ⊣ Δ3

푖 ∈ {1, 2} 푖 ∈ {1, 2} 푖 ∈ {1, 2} Δ1; Γ ⊢ 푒 : 퐴푖 ⊣ Δ2 Δ1; Γ ⊢ 푒 : 푆푖 ⊣ Δ2 Δ1; Γ ⊢ 푒 : 푋푖 ⊣ Δ2 uinj sinj ainj 푖 푒 퐴 퐴 푖 푒 푆 푆 푖 푒 푋 푋 Δ1; Γ ⊢ inj∞ ( ) : 1 + 2 ⊣ Δ2 Δ1; Γ ⊢ injw ( ) : 1 + 2 ⊣ Δ2 Δ1; Γ ⊢ inj1 ( ) : 1 ⊕ 2 ⊣ Δ2

Δ1; Γ ⊢ 푒1 : 퐴1 × 퐴2 ⊣ Δ2 Δ1; Γ ⊢ 푒1 : 푆1 × 푆2 ⊣ Δ2 Δ2; Γ, 푥1 : 퐴1, 푥2 : 퐴2 ⊢ 푒 : 푈 ⊣ Δ3 Δ2; Γ, 푥1 : 푆1, 푥2 : 푆2 ⊢ 푒 : 푈 ⊣ Δ3 usplit ssplit 푒 , 푥 .푥 .푒 푈 푒 , 푥 .푥 .푒 푈 Δ1; Γ ⊢ split∞ ( 1 1 2 2) : ⊣ Δ3 Δ1; Γ ⊢ splitw ( 1 1 2 2) : ⊣ Δ3

Δ1; Γ ⊢ 푒 : 퐴1 + 퐴2 ⊣ Δ2 Δ1; Γ ⊢ 푒1 : 푋1 ⊗ 푋2 ⊣ Δ2 Δ2; Γ, 푥1 : 퐴1 ⊢ 푒1 : 푈 ⊣ Δ3 Δ2, 푥1 : 푋1, 푥2 : 푋2; Γ ⊢ 푒 : 푈 ⊣ Δ3 Δ2; Γ, 푥2 : 퐴2 ⊢ 푒2 : 푈 ⊣ Δ3 asplit ucase 푒 , 푥 .푥 .푒 푈 푥 푋 , 푥 푋 푒, 푥 .푒 , 푥 .푒 푈 Δ1; Γ ⊢ split1 ( 1 1 2 2) : ⊣ Δ3 ÷ ( 1 : 1 2 : 2) Δ1; Γ ⊢ case∞ ( 1 1 2 2) : ⊣ Δ3

Δ1; Γ ⊢ 푒 : 푆1 + 푆2 ⊣ Δ2 Δ2; Γ, 푥1 : 푆1 ⊢ 푒1 : 푈 ⊣ Δ3 Δ1; Γ ⊢ 푒 : 푋1 ⊕ 푋2 ⊣ Δ2 Δ2; Γ, 푥2 : 푆2 ⊢ 푒2 : 푈 ⊣ Δ3 Δ2, 푥1 : 푋1; Γ ⊢ 푒1 : 푈 ⊣ Δ3 Δ2, 푥2 : 푋2; Γ ⊢ 푒2 : 푈 ⊣ Δ3 scase acase Δ1; Γ ⊢ casew (푒, 푥1.푒1, 푥2.푒2) : 푈 ⊣ Δ3 Δ1; Γ ⊢ case1 (푒, 푥1.푒1, 푥2.푒2) : 푈 ⊣ Δ3 ÷ (푥1 : 푋1, 푥2 : 푋2)

·; Γ, 푥 : 퐴 ⊢ 푒 : 푈 ⊣ · w ; Γ, 푥 : 퐴 ⊢ 푒 : 푈 ⊣ · Δ1, 푥 : 푋; Γ ⊢ 푒 : 푈 ⊣ Δ2 uabs ○ wabs aabs Δ; Γ ⊢ 휆∞ 푥. 푒 : 퐴 →∞ 푈 ⊣ Δ Δ; Γ ⊢ 휆w 푥. 푒 : 퐴 →w 푈 ⊣ Δ Δ1; Γ ⊢ 휆1 푥. 푒 : 푋 →1 푈 ⊣ Δ2 ÷ (푥 : 푋)

Δ1; Γ ⊢ 푒2 : 퐴 ⊣ Δ2 Δ1; Γ ⊢ 푒2 : 퐴 ⊣ Δ2 Δ1; Γ ⊢ 푒2 : 푋 ⊣ Δ2 Δ2; Γ ⊢ 푒1 : 퐴 →∞ 푈 ⊣ Δ3 Δ2; Γ ⊢ 푒1 : 퐴 →w 푈 ⊣ Δ3 Δ2; Γ ⊢ 푒1 : 푋 →1 푈 ⊣ Δ3 uapp wapp aapp Δ1; Γ ⊢ (푒1 푒2) : 푈 ⊣ Δ3 Δ1, w ; Γ ⊢ (푒1 푒2) : 푈 ⊣ Δ3 Δ1; Γ ⊢ (푒1 푒2) : 푈 ⊣ Δ3 ∞ ○ w 1

·; Γ, 푥 : 퐴 →∞ 푈 ⊢ 푒 : 퐴 →∞ 푈 ⊣ · ·; Γ, 푥 : 퐴 →w 푈 ⊢ 푒 : 퐴 →w 푈 ⊣ · 푥 : 푋 →1 푈 ; Γ ⊢ 푒 : 푋 →1 푈 ⊣ · ufix wfix afix Δ; Γ ⊢ fix∞ (푥.푒) : 퐴 →∞ 푈 ⊣ Δ Δ; Γ ⊢ fixw (푥.푒) : 퐴 →w 푈 ⊣ Δ Δ; Γ ⊢ fix1 (푥.푒) : 푋 →1 푈 ⊣ Δ

Δ1; Γ ⊢ 푒1 : 퐴 ⊣ Δ2 Δ1; Γ ⊢ 푒1 : 푋 ⊣ Δ2 Δ2; Γ, 푥 : 퐴 ⊢ 푒2 : 푈 ⊣ Δ3 Δ2, 푥 : 푋; Γ ⊢ 푒2 : 푈 ⊣ Δ3 Δ1; Γ ⊢ 푒 : 퐴 ⊣ Δ2 ulet alet bang Δ1; Γ ⊢ let∞ (푒1, 푥.푒2) : 푈 ⊣ Δ3 Δ1; Γ ⊢ let1 (푒1, 푥.푒2) : 푈 ⊣ Δ3 ÷ (푥 : 푋) Δ1; Γ ⊢ ! 푒 :! 퐴 ⊣ Δ2

Δ1; Γ ⊢ 푒1 : 푆 ⊣ Δ2 Δ1; Γ ⊢ 푒 :! 퐴 ⊣ Δ2 Δ1, 푥1 : Rd 푆; Γ, 푥2 : Wr 푆 ⊢ 푒 : 푈 ⊣ Δ2 Δ2; Γ ⊢ 푒2 : Wr 푆 ⊣ Δ3 gnab nu wr Δ1; Γ ⊢ ¡ 푒 : 퐴 ⊣ Δ2 Δ1; Γ ⊢ 휈 (푥1, 푥2). 푒 : 푈 ⊣ Δ2 ÷ (푥1 : Rd 푆) Δ1, w ; Γ ⊢ wr(푒1, 푒2) : 1 ⊣ Δ3 ○

16 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

w ∉ Δ3 Δ1; Γ ⊢ 푒1 : Rd 푆 ⊣ Δ2 Δ2; Γ ⊢ 푒2 : Rd푇 ⊣ Δ3 ○ Δ3, w , 푥1 :! 푆 ⊗ Rd 푆 ⊗ Rd푇 ; Γ ⊢ 푒3 : 푈 ⊣ Δ4 ○ w ∉ Δ2 Δ1; Γ ⊢ 푒1 : Rd 푆 ⊣ Δ2 Δ3, w , 푥2 :!푇 ⊗ Rd 푆 ⊗ Rd푇 ; Γ ⊢ 푒4 : 푈 ⊣ Δ4 ○, , 푥 푆 푆 푒 푈 ○ choice Δ2 w :! ⊗ Rd ; Γ ⊢ 2 : ⊣ Δ3 ⊢ (푒 , 푥 .푒 , 푒 , 푥 .푒 ) 푈 ⊣ ÷ ○ rd Δ1; Γ ch 1 1 3 2 2 4 : Δ4 Δ1; Γ ⊢ rd(푒1, 푥.푒2) : 푈 ⊣ Δ3 ÷ ( w , 푥 :! 푆 ⊗ Rd 푆) ( w , 푥1 :! 푆 ⊗ Rd 푆 ⊗ Rd푇, 푥2 :!푇 ⊗ Rd푇 ⊗ Rd 푆) ○ ○

Δ1; Γ ⊢ 푒1 : 푈 ⊣ Δ2 Δ2; Γ ⊢ 푒2 : 푉 ⊣ Δ3 fork Δ1; Γ ⊢ 푒1 |▷ 푒2 : 푉 ⊣ Δ3

Figure 9. Algorithmic typing rules.

B Type Soundness We first define syntax for process and channel typings, which each map a kind of identifier (process name or channelname)to its associated type: Process pool typings Φ ::= · | Φ, 푝 : 푈 Channel typings Ψ ::= · | Ψ,푑 : 푆 Using the syntax above, we define configuration typing as a straightforward extension of single-process typing, givenin Section 3.2: Ψ ⊢ 퐶 : Φ Configuration 퐶 is well-typed. Ψ ⊢ 푒 : 푈 Ψ ⊢ ⟨Σ; 휋⟩ : Φ empty cons Ψ ⊢ ⟨Σ; 휀⟩ : · Ψ ⊢ ⟨Σ; 휋, 푝 : 푒⟩ : Φ, (푝 : 푈 )

B.1 Progress Progress for the functional fragment of ILC (local progress) is fairly standard. We follow the usual recipe, except that we give a special definition of local process termination: 푒 lterm Expression 푒 is locally terminated.

val rdterm chterm wrterm 푣 lterm 퐸[rd(푐, 푥.푒)] lterm 퐸[ch(푐1, 푥1.푒1, 푐2, 푥2.푒2)] lterm 퐸[wr(푣, 푐)] lterm In other words, 푒 lterm holds when 푒 is a value, is reading (either as a standalone read or an external choice), or is writing. Lemma B.1 (Local Progress). If Ψ ⊢ 푒 : 푈 , then either 푒 lterm or there exists 푒 ′ such that 푒 → 푒 ′. Proof. By structural induction on the derivation of Ψ ⊢ 푒 : 푈 . □ To state progress on configurations, we give a special definition of “program termination” that permits deadlocks: 퐶 term Configuration 퐶 is terminated. ∀(푝 : 푒) ∈ 휋. 푒 lterm RdChans(휋) = Σ1 WrChans(휋) = Σ2 {(푐1, 푐2) | 푐1 ∈ Σ1, 푐2 ∈ Σ2, 푐2 { 푐1} = ∅ Cterm ⟨Σ; 휋⟩ term

RdChans(휀) = · WrChans(휀) = · RdChans(휋, 푝 : 퐸[rd(푐, 푥.푒)]) = RdChans(휋), 푐 WrChans(휋, 푝 : 퐸[rd(푐, 푥.푒)]) = WrChans(휋)

RdChans(휋, 푝 : 퐸[ch(푐1, 푥1.푒1, 푐2, 푥2.푒2)]) = RdChans(휋), 푐1, 푐2 WrChans(휋, 푝 : 퐸[ch(푐1, 푥1.푒1, 푐2, 푥2.푒2)]) = WrChans(휋) RdChans(휋, 푝 : 퐸[wr(푣, 푐)]) = RdChans(휋) WrChans(휋, 푝 : 퐸[wr(푣, 푐)]) = WrChans(휋), 푐 RdChans(휋, 푝 : 푣) = RdChans(휋) WrChans(휋, 푝 : 푣) = WrChans(휋) In other words, 퐶 term holds when either: 17 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

1. 퐶 is fully normal: Every process in 퐶 is normalized (consists of a value), or 2. 퐶 is (at least partially) deadlocked: Some (possibly empty) portion of 퐶 is normal, and there exists one or more reading processes in 퐶, or there exists one or more writing processes in 퐶, however, no reader-writer process pair exists for a common channel. Theorem B.2 (Progress). If Ψ ⊢ 퐶 : Φ, then either 퐶 term or there exists 퐶 ′ such that 퐶 −→ 퐶 ′. Proof. By structural induction on the derivation of Ψ ⊢ 퐶 : Φ. Case

empty Ψ ⊢ ⟨Σ; 휀⟩ : ·

∀(푝 : 푒) ∈ 휀. 푒 lterm Vacuous Σ1 = RdChans(휀) = · By definition of RdChans Σ2 = WrChans(휀) = · By definition of WrChans {(푐1, 푐2) | 푐1 ∈ Σ1, 푐2 ∈ Σ2, 푐2 { 푐1} = ∅ ⟨Σ; 휀⟩ term By rule Cterm

Case Ψ ⊢ 푒 : 푈 Ψ ⊢ ⟨Σ; 휋⟩ : Φ cons Ψ ⊢ ⟨Σ; 휋, 푝 : 푒⟩ : Φ, (푝 : 푈 )

푒 lterm or ∃ 푒 ′ s.t. 푒 → 푒 ′ By i.h. ⟨Σ; 휋⟩ term or ∃ ⟨Σ′; 휋 ′⟩ s.t. ⟨Σ; 휋⟩ → ⟨Σ′; 휋 ′⟩ By i.h. Subcase ∃ 푒 ′ s.t. 푒 → 푒 ′ Subsubcase local ′ 푒 = 퐸[푒1] and 푒 = 퐸[푒2] Suppose ⟨Σ; 휋, 푝 : 퐸[푒1]⟩ → ⟨Σ; 휋, 푝 : 퐸[푒2]⟩ By rule local Subsubcase fork ′ 푒 = 퐸[푒1 |▷ 푒2], 푒 = 퐸[푒2], and 푞 ∉ Σ Suppose ⟨Σ; 휋, 푝 : 퐸[푒1 |▷ 푒2]⟩ → ⟨Σ, 푞; 휋, 푞 : 푒1, 푝 : 퐸[푒2]⟩ By rule fork Subsubcase nu ′ 푒 = 퐸[휈 (푥1, 푥2). 푒1], 푒 = 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒1], 푑 ∉ Σ Suppose ⟨Σ; 휋, 푝 : [휈 (푥1, 푥2). 푒1]⟩ → ⟨Σ,푑; 휋, 푝 : 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒1]⟩ By rule nu Subsubcase rw 푒 퐸 푐 , 푥.푒 , 푒 ′ 퐸 푣, 푐 푥 푒 , 푐 푐 , = [rd( 1 1)] = [[(! 1)1/ ] 1] and 2 { 1 or ′ 푒 = 퐸[wr(푣, 푐2)], 푒 = 퐸[()], and 푐2 { 푐1 푒 퐸 푐 , 푥.푒 , 푒 ′ 퐸 푣, 푐 푥 푒 , 푐 푐 Subsubsubcase = [rd( 1 1)] = [[(! 1)1/ ] 1] and 2 { 1 ∃ (푞 : 퐸[wr(푣, 푐2)]) ∈ 휋 By 푐2 { 푐1 휋, 푝 퐸 푐 , 푥.푒 휋, 푝 퐸 푣, 푐 푥 푒 ⟨Σ; : [rd( 1 1)] → ⟨Σ; : [[(! 1)1/ ] 1]⟩⟩ By rule rw ′ Subsubsubcase 푒 = 퐸[wr(푣, 푐2)], 푒 = 퐸[()], and 푐2 { 푐1 ∃ (푞 : 퐸[rd(푐1, 푥.푒1)]) ∈ 휋 By 푐2 { 푐1 ⟨Σ; 휋, 푝 : 퐸[wr(푣, 푐2)] → ⟨Σ; 휋, 푝 : 퐸[()]⟩⟩ By rule rw Subsubcase cw 푒 퐸 푐 , 푥 .푒 , 푐 , 푥 .푒 , 푒 ′ 퐸 푣, 푐 , 푐 푥 푒 , 푐 푐 , 푖 , , = [ch( 1 1 1 2 2 2)] = [[(! 1 2)1/ 푖 ] 푖 ] { 푖 ∈ {1 2} or ′ 푒 = 퐸[wr(푣, 푐)], 푒 = 퐸[()], 푐 { 푐푖, 푖 ∈ {1, 2} 푒 퐸 푐 , 푥 .푒 , 푐 , 푥 .푒 , 푒 ′ 퐸 푣, 푐 , 푐 푥 푒 , Subsubsubcase = [ch( 1 1 1 2 2 2)] = [[(! 1 2)1/ 푖 ] 푖 ] 푐 { 푐푖, 푖 ∈ {1, 2} ∃ (푞 : 퐸[wr(푣, 푐)]) ∈ 휋 By 푐 { 푐푖 18 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

휋, 푝 퐸 푐 , 푥 .푒 , 푐 , 푥 .푒 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 ⟨Σ; : [ch( 1 1 1 2 2 2)] → ⟨Σ; : [[(! 1 2)1/ 푖 ] 푖 ]⟩⟩ By rule cw ′ Subsubsubcase 푒 = 퐸[wr(푣, 푐)], 푒 = 퐸[()], 푐 { 푐푖, 푖 ∈ {1, 2} ∃ (푞 : 퐸[ch(푐1, 푥1.푒1, 푐2, 푥2.푒2)]) ∈ 휋 By 푐 { 푐푖 ⟨Σ; 휋, 푝 : 퐸[wr(푣, 푐)] → ⟨Σ; 휋, 푝 : 퐸[()]⟩⟩ By rule cw Subcase ∃ ⟨Σ′; 휋 ′⟩ s.t. ⟨Σ; 휋⟩ → ⟨Σ′; 휋 ′⟩ ⟨Σ; 휋, 푝 : 푒⟩ → ⟨Σ′; 휋 ′, 푝 : 푒⟩ By rules local and congr Subcase ⟨Σ; 푝 : 푒⟩ term and ⟨Σ; 휋⟩ term Σ1 = RdChans(휋, 푝 : 푒) and Σ2 = WrChans(휋, 푝 : 푒) Suppose {(푐1, 푐2) | 푐1 ∈ Σ1, 푐2 ∈ Σ2, 푐2 { 푐1} = ∅ or {(푐1, 푐2) | 푐1 ∈ Σ1, 푐2 ∈ Σ2, 푐2 { 푐1} ≠ ∅ Subsubcase {(푐1, 푐2) | 푐1 ∈ Σ1, 푐2 ∈ Σ2, 푐2 { 푐1} = ∅ ⟨Σ; 휋, 푝 : 푒⟩ term By rule Cterm Subsubcase {(푐1, 푐2) | 푐1 ∈ Σ1, 푐2 ∈ Σ2, 푐2 { 푐1} ≠ ∅ ∃ 푐2 { 푐1 s.t. 푐1 ∈ Σ1, 푐2 ∈ Σ2 Above 푝 : 푣 or 푝 : 퐸[rd(푐1, 푥.푒)] or 푝 : 퐸[ch(푐1, 푥1.푒1, 푐3, 푥2.푒2)] or 푝 : 퐸[ch(푐3, 푥1.푒1, 푐1, 푥2.푒2)] or 푝 : 퐸[wr(푣, 푐2)] By definition of lterm Subsubsubcase 푝 : 푣 Impossible Subsubsubcase 푝 : 퐸[rd(푐1, 푥.푒)] ∃ 푞 : 퐸[wr(푣, 푐2)] ∈ 휋 By 푐2 { 푐1 휋, 푝 퐸 푐 , 푥.푒 휋, 푝 퐸 푣, 푐 푥 푒 ⟨Σ; : [rd( 1 )]⟩ −→ ⟨Σ; : [[(! 1)1/ ] ]⟩ By rule rw Subsubsubcase 푝 : 퐸[ch(푐1, 푥1.푒1, 푐3, 푥2.푒2)] ∃ 푞 : 퐸[wr(푣, 푐2)] ∈ 휋 By 푐2 { 푐1 휋, 푝 퐸 푐 , 푥 .푒 , 푐 , 푥 .푒 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 ⟨Σ; : [ch( 1 1 1 3 2 2)]⟩ −→ ⟨Σ; : [[(! 1 3)1/ 1] 1]⟩ By rule cw Subsubsubcase 푝 : 퐸[ch(푐3, 푥1.푒1, 푐1, 푥2.푒2)] ∃ 푞 : 퐸[wr(푣, 푐2)] ∈ 휋 By 푐2 { 푐1 휋, 푝 퐸 푐 , 푥 .푒 , 푐 , 푥 .푒 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 ⟨Σ; : [ch( 3 1 1 1 2 2)]⟩ −→ ⟨Σ; : [[(! 1 3)1/ 2] 2]⟩ By rule cw Subsubsubcase 푝 : 퐸[wr(푣, 푐2)] ∃ 푞 : 퐸[rd(푐1, 푥.푒)] ∈ 휋 or ∃ 푞 : 퐸[ch(푐1, 푥1.푒1, 푐3, 푥2.푒2)] ∈ 휋 or ∃ 푞 : 퐸[ch(푐3, 푥1.푒1, 푐1, 푥2.푒2)] ∈ 휋 By 푐2 { 푐1 ⟨Σ; 휋, 푝 : 퐸[wr(푣, 푐2)]⟩ −→ ⟨Σ; 휋, 푝 : 퐸[()]⟩ By rule rw

□

B.2 Preservation Preservation for the functional fragment of ILC (local preservation) is standard. Lemma B.3 (Local Preservation). If Ψ ⊢ 푒 : 푈 and 푒 → 푒 ′, then there exists Ψ′ ⊇ Ψ such that Ψ ⊢ 푒 ′ : 푈 . Proof. By structural induction on the derivation of 푒 → 푒 ′. □ To state preservation on configurations, we first state several auxiliary results, which follow the formulation ofGayand Vasconcelos [25]. Lemma B.4 shows that typing of configurations is preserved under configuration equivalence. Lemma B.4 (Preservation Modulo Equivalence). If Ψ ⊢ 퐶 : Φ and 퐶 ≡ 퐶 ′, then Ψ ⊢ 퐶 ′ : Φ. Proof. By structural induction on Ψ ⊢ 퐶 : Φ. □ Lemma B.5 shows that a subterm of a well-typed evaluation context is typeable with a subset of the type contexts. Lemma B.5 (Typeability of Subterms). If D is a derivation of Ψ; Δ; Γ ⊢ 퐸[푒] : 푈 (written D :: Ψ; Δ; Γ ⊢ 퐸[푒] : 푈 ), then

1. there exists Ψ1, Ψ2; Δ1, Δ2; Γ1, Γ2 and 푉 such that Ψ = Ψ1, Ψ2, Δ = Δ1, Δ2, Γ = Γ1, Γ2, ′ ′ 2. D has a subderivation D (written D ⊑ D) concluding Ψ1; Δ1; Γ1 ⊢ 푒 : 푉 , 3. the position of D′ in D corresponds to the position of the hole in 퐸 (written 퐸[D′ ⊑ D]). Proof. By structural induction on the structure of 퐸. □ 19 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

Lemma B.6 shows that the subterm of a well-typed evaluation context can be replaced. Lemma B.6 (Replacement (Evaluation Contexts)). If

1. D :: Ψ1, Ψ2; Δ1, Δ2; Γ1, Γ2 ⊢ 퐸[푒] : 푈 , ′ ′ 2. D ⊑ D such that D :: Ψ2; Δ2; Γ2 ⊢ 푒 : 푉 , 3. 퐸[D′ ⊑ D], ′ 4. Ψ3; Δ3; Γ3 ⊢ 푒 : 푉 , 5. Ψ1, Ψ3; Δ1, Δ3; Γ1, Γ3 is defined, ′ then Ψ1, Ψ3; Δ1, Δ3; Γ1, Γ3 ⊢ 퐸[푒 ] : 푈 . Proof. By structural induction on the structure of 퐸. □ Finally, Lemmas B.7, B.8, B.9, B.10 show that typing of terms is preserved by substitution. Lemma B.7 (Substitution (Unrestricted)). If

1. Ψ1; Δ1; Γ1, 푥 : 퐴 ⊢ 푒 : 푈 , ′ 2. Ψ2; Δ2; Γ2 ⊢ 푒 : 퐴, 3. Ψ1, Ψ2; Δ1, Δ2; Γ1, Γ2 is defined, ′ then Ψ1, Ψ2; Δ1, Δ2; Γ1, Γ2 ⊢ [푒 /푥]푒 : 푈 .

Proof. By structural induction on the derivation of Ψ1; Δ1; Γ1, 푥 : 퐴 ⊢ 푒 : 푈 . □ Lemma B.8 (Substitution (Affine)). If

1. Ψ1; Δ1, 푥 : 푋; Γ1 ⊢ 푒 : 푈 , ′ 2. Ψ2; Δ2; Γ2 ⊢ 푒 : 푋, 3. Ψ1, Ψ2; Δ1, Δ2; Γ1, Γ2 is defined, ′ then Ψ1, Ψ2; Δ1, Δ2; Γ1, Γ2 ⊢ [푒 /푥]푒 : 푈 .

Proof. By structural induction on the derivation of Ψ1; Δ1, 푥 : 푋; Γ1 ⊢ 푒 : 푈 . □ Lemma B.9 (Substitution (Read Endpoint)). If 1. Ψ; Δ, 푥 : Rd 푆; Γ ⊢ 푒 : 푈 , 2. Ψ,푑 : 푆; Δ; Γ is defined, then Ψ,푑 : 푆; Δ; Γ ⊢ [Read(푑)/푥]푒 : 푈 . Proof. By structural induction on the derivation of Ψ; Δ, 푥 : Rd 푆; Γ ⊢ 푒 : 푈 . □ Lemma B.10 (Substitution (Write Endpoint)). If 1. Ψ; Δ; Γ, 푥 : Wr 푆 ⊢ 푒 : 푈 , 2. Ψ,푑 : 푆, Ψ; Δ; Γ is defined, then Ψ,푑 : 푆; Δ; Γ ⊢ [Write(푑)/푥]푒 : 푈 . Proof. By structural induction on the derivation of Ψ; Δ; Γ, 푥 : Wr 푆 ⊢ 푒 : 푈 . □ Theorem B.11 (Preservation). If Ψ ⊢ 퐶 : Φ and 퐶 −→ 퐶 ′, then there exists Ψ′ ⊇ Ψ and Φ′ ⊇ Φ such that Ψ′ ⊢ 퐶 ′ : Φ′. Proof. By structural induction on the derivation of 퐶 −→ 퐶 ′. Case

푒1 −→ 푒2 local ⟨Σ; 휋, 푝 : 퐸[푒1]⟩ −→ ⟨Σ; 휋, 푝 : 퐸[푒2]⟩

Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸[푒1]⟩ : Φ s.t. Φ = Φ휋, 푝 : 푈 , Ψ = Ψ1, Ψ2, and D :: Ψ1, Ψ2 ⊢ 퐸[푒1] : 푈 Assumption ′ ′ ′ ∃ D ⊑ D s.t. D :: Ψ2 ⊢ 푒1 : 푉 and 퐸[D ⊑ D] By Lemma B.5 Ψ2 ⊢ 푒2 : 푉 By i.h. and Lemma B.3 Ψ1, Ψ2 ⊢ 퐸[푒2] : 푈 By Lemma B.6

20 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

Ψ ⊢ 퐸[푒2] : 푈 By above equalities Ψ ⊢ ⟨Σ; 휋⟩ : Φ휋 Above Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸[푒2]⟩ : (Φ휋, 푝 : 푈 ) By rule cons Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸[푒2]⟩ : Φ By above equalities Ψ′ = Ψ and Φ′ = Φ Suppose ′ ′ Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸[푒2]⟩ : Φ By above equalities

Case 푞 ∉ Σ fork ⟨Σ; 휋, 푝 : 퐸[푒1 |▷ 푒2]⟩ −→ ⟨Σ, 푞; 휋, 푞 : 푒1, 푝 : 퐸[푒2]⟩

Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸[푒1 |▷ 푒2]⟩ : Φ s.t. Φ = Φ휋, 푝 : 푈 , Ψ = Ψ1, Ψ2, and D :: Ψ1, Ψ2 ⊢ 퐸[푒1 |▷ 푒2] : 푈 Assumption ′ ′ ′ ∃ D ⊑ D s.t. D :: Ψ2 ⊢ 푒1 |▷ 푒2 : 푉2 and 퐸[D ⊑ D] By Lemma B.5 Ψ2 ⊢ 푒1 : 푉1 By inversion on fork Ψ2 ⊢ 푒2 : 푉2 By inversion on fork Ψ1, Ψ2 ⊢ 퐸[푒2] : 푈 By Lemma B.6 Ψ ⊢ 퐸[푒2] : 푈 By above equalities Ψ ⊢ ⟨Σ; 휋⟩ : Φ휋 Above Ψ ⊢ ⟨Σ, 푞; 휋⟩ : Φ휋 By 푞 ∉ Σ Ψ ⊢ ⟨Σ, 푞; 휋, 푞 : 푒1⟩ : (Φ휋, 푞 : 푉1) By rule cons Ψ ⊢ ⟨Σ, 푞; 휋, 푞 : 푒1, 푝 : 퐸[푒2]⟩ : (Φ휋, 푞 : 푉1, 푝 : 푈 ) By rule cons Ψ ⊢ ⟨Σ, 푞; 휋, 푞 : 푒1, 푝 : 퐸[푒2]⟩ : Φ, 푞 : 푉1 By above equalities ′ ′ Ψ = Ψ and Φ = Φ, 푞 : 푉1 Suppose ′ ′ Ψ ⊢ ⟨Σ, 푞; 휋, 푞 : 푒1, 푝 : 퐸[푒2]⟩ : Φ By above equalities

Case 퐶 퐶 ′ 퐶 ′ 퐶 ′ 퐶 ′ 퐶 1 ≡ 1 1 −→ 2 2 ≡ 2 congr 퐶1 −→ 퐶2

Ψ ⊢퐶1 : Φ Assumption 퐶 퐶 ′ 1 ≡ 1 Given 퐶 ′ Ψ ⊢ 1 : Φ By Lemma B.4 Ψ′ ⊇ Ψ and Φ′ ⊇ Φ Suppose ′ 퐶 ′ ′ Ψ ⊢ 2 : Φ By i.h. ′ ′ Ψ ⊢퐶2 : Φ By Lemma B.4

Case 푑 ∉ Σ nu ⟨Σ; 휋, 푝 : 퐸[휈 (푥1, 푥2). 푒]⟩ −→ ⟨Σ,푑; 휋, 푝 : 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒]⟩

Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸[휈 (푥1, 푥2). 푒]⟩ : Φ s.t. Φ = Φ휋, 푝 : 푈 , Ψ = Ψ1, Ψ2 and D :: Ψ1, Ψ2 ⊢ 퐸[휈 (푥1, 푥2). 푒] : 푈 Assumption ′ ′ ′ ∃ D ⊑ D s.t. D :: Ψ2 ⊢ 휈 (푥1, 푥2). 푒 : 푉 and 퐸[D ⊑ D] By Lemma B.5 Ψ2; Γ; Δ ⊢ 푒 : 푈 where Γ; Δ = 푥1 : Rd 푆; 푥2 : Wr 푆 By inversion on nu 푑 : 푆 ⊢ Read(푑) : Rd 푆 By rule rdend 21 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

푑 : 푆 ⊢ Write(푑) : Rd 푆 By rule wrend Ψ3 ⊢ [Read(푑)/푥1][Write(푑)/푥2]푒 : 푈 where Ψ3 = Ψ2,푑 : 푆 By Lemmas B.9 and B.10 Ψ1, Ψ3 ⊢ 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒] : 푈푝 By Lemma B.6 Ψ, Ψ4 ⊢ 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒] : 푈푝 where Ψ4 = 푐1 : Rd 푆, 푐2 : Wr 푆 By above equalities Ψ, Ψ4 ⊢ ⟨Σ; 휋⟩ : Φ휋 Above Ψ, Ψ4 ⊢ ⟨Σ; 휋, 푝 : 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒]⟩ : (Φ휋, 푝 : 푈 ) By rule cons Ψ, Ψ4 ⊢ ⟨Σ; 휋, 푝 : 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒]⟩ : Φ Above ′ ′ Ψ = Ψ, Ψ4 and Φ = Φ Suppose ′ ′ Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸[[Read(푑)/푥1][Write(푑)/푥2]푒]⟩ : Φ By above equalities

Case 푐2 { 푐1 rw 휋, 푝 퐸 푐 , 푥.푒 , 푞 퐸 푣, 푐 휋, 푝 퐸 푣, 푐 푥 푒 , 푞 퐸 ⟨Σ; : 1 [rd( 1 )] : 2 [wr( 2)]⟩ −→ ⟨Σ; : 1 [[(! 1)1/ ] ] : 2 [()]⟩

Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸1 [rd(푐1, 푥.푒)], 푞 : 퐸2 [wr(푣, 푐2)]⟩ : Φ s.t. Φ = Φ휋, 푝 : 푈 , 푞 : 푉, Ψ = Ψ1, Ψ2, D푝 :: Ψ1, Ψ2 ⊢ 퐸1 [rd(푐1, 푥.푒)] : 푈 , Ψ = Ψ3, Ψ4, and D푞 :: Ψ3, Ψ4 ⊢ 퐸2 [wr(푣, 푐2)] : 푉 Assumption ′ ′ 푐 , 푥.푒 푈 ′ 퐸 ′ ∃ D푝 ⊑ D푝 s.t. D푝 :: Ψ2 ⊢ rd( 1 ) : and 1 [D푝 ⊑ D푝 ] By Lemma B.5 ′ ′ 푣, 푐 1 퐸 ′ ∃ D푞 ⊑ D푞 s.t. D푞 :: Ψ4 ⊢ wr( 2) : and 2 [D푞 ⊑ D푞] By Lemma B.5 푐2 { 푐1 s.t. Ψ(푐2) = Wr 푆 and Ψ(푐1) = Rd 푆 Given ′ Ψ2; Δ; · ⊢ 푒 : 푈 where Δ = w , 푥 :! 푆 ⊗ Rd 푆 By inversion on rd ○ ⊢ 푣 : 푆 By inversion on wr ⊢ ! 푣 :! 푆 By rule bang 푣, 푐 푆 푆 ⊢ (! 1)1 :! ⊗ Rd By rule apair 푣, 푐 푥 푒 푈 ′ Ψ2; w ; · ⊢ [(! 1)1/ ] : By Lemma B.8 ○, 퐸 푣, 푐 푥 푒 푈 Ψ1 Ψ2 ⊢ 1 [[(! 1)1/ ] ] : By Lemma B.6 퐸 푣, 푐 푥 푒 푈 Ψ ⊢ 1 [[(! 1)1/ ] ] : By above equalities Ψ ⊢ ⟨Σ; 휋⟩ : Φ휋 Above 휋, 푝 퐸 푣, 푐 푥 푒 , 푝 푈 Ψ ⊢ ⟨Σ; : 1 [[(! 1)1/ ] ]⟩ : (Φ휋 : ) By rule cons Ψ4 ⊢ ( ) : 1 By rule unit Ψ3, Ψ4 ⊢ 퐸2 [()] : 푉 By Lemma B.6 Ψ ⊢ 퐸2 [()] : 푉 By above equalities 휋, 푝 퐸 푣, 푐 푥 푒 , 푞 퐸 , 푝 푈 , 푞 푉 Ψ ⊢ ⟨Σ; : 1 [[(! 1)1/ ] ] : 2 [()]⟩ : (Φ휋 : : ) By rule cons 휋, 푝 퐸 푣, 푐 푥 푒 , 푞 퐸 Ψ ⊢ ⟨Σ; : 1 [[(! 1)1/ ] ] : 2 [()]⟩ : Φ By above equalities Ψ′ = Ψ and Φ′ = Φ Suppose ′ 휋, 푝 퐸 푣, 푐 푥 푒 , 푞 퐸 ′ Ψ ⊢ ⟨Σ; : 1 [[(! 1)1/ ] ] : 2 [()]⟩ : Φ By above equalities

Case

푐 { 푐푖 푖 ∈ {1, 2} cw 휋, 푝 퐸 푐 , 푥 .푒 , 푐 , 푥 .푒 , 푞 퐸 푣, 푐 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푞 퐸 ⟨Σ; : 1 [ch( 1 1 1 2 2 2)] : 2 [wr( )]⟩ −→ ⟨Σ; : 1 [[(! 1 2)1/ 푖 ] 푖 ] : 2 [()]⟩

Ψ ⊢ ⟨Σ; 휋, 푝 : 퐸1 [ch(푐1, 푥1.푒1, 푐2, 푥2.푒2)], 푞 : 퐸2 [wr(푣, 푐)]⟩ : Φ s.t. Φ = Φ휋, 푝 : 푈 , 푞 : 푉, Ψ = Ψ1, Ψ2, D푝 :: Ψ1, Ψ2 ⊢ 퐸1 [ch(푐1, 푥1.푒1, 푐2, 푥2.푒2)] : 푈 , Ψ = Ψ3, Ψ4, and D푞 :: Ψ3, Ψ4 ⊢ 퐸2 [wr(푣, 푐)] : 푉 Assumption ′ ′ 푐 , 푥 .푒 , 푐 , 푥 .푒 푈 ′ 퐸 ′ ∃ D푝 ⊑ D푝 s.t. D푝 :: Ψ2 ⊢ ch( 1 1 1 2 2 2) : and 1 [D푝 ⊑ D푝 ] By Lemma B.5 ′ ′ 푣, 푐 1 퐸 ′ ∃ D푞 ⊑ D푞 s.t. D푞 :: Ψ4 ⊢ wr( 2) : and 2 [D푞 ⊑ D푞] By Lemma B.5 22 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

푐 { 푐1 s.t. Ψ(푐) = Wr 푆, Ψ(푐1) = Rd 푆, Ψ(푐2) = Rd푇 or 푐 { 푐2 s.t. Ψ(푐) = Wr푇, Ψ(푐1) = Rd 푆, Ψ(푐2) = Rd푇 Given Subcase 푐 { 푐1 ′ Ψ2; Δ; · ⊢ 푒 : 푈 where Δ = w , 푥1 :! 푆 ⊗ Rd 푆 ⊗ Rd푇 By inversion on choice ○ ⊢ 푣 : 푆 By inversion on wr ⊢ ! 푣 :! 푆 By rule bang 푣, 푐 , 푐 푆 푆 푇 ⊢ (! 1 2)1 :! ⊗ Rd ⊗ Rd By rule apair 푣, 푐 , 푐 푥 푒 푈 ′ Ψ2; w ; · ⊢ (! 1 2)1/ 1] 1 : By Lemma B.8 ○, 퐸 푣, 푐 , 푐 푥 푒 푈 Ψ1 Ψ2 ⊢ 1 [[(! 1 2)1/ 1] 1] : By Lemma B.6 퐸 푣, 푐 , 푐 푥 푒 푈 Ψ ⊢ 1 [[(! 1 2)1/ 1] 1] : By above equalities Ψ ⊢ ⟨Σ; 휋⟩ : Φ휋 Above 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푝 푈 Ψ ⊢ ⟨Σ; : 1 [[(! 1 2)1/ 1] 1]⟩ : (Φ휋 : ) By rule cons Ψ4 ⊢ ( ) : 1 By rule unit Ψ3, Ψ4 ⊢ 퐸2 [()] : 푉 By Lemma B.6 Ψ ⊢ 퐸2 [()] : 푉 By above equalities 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푞 퐸 , 푝 푈 , 푞 푉 Ψ ⊢ ⟨Σ; : 1 [[(! 1 2)1/ 1] 1] : 2 [()]⟩ : (Φ휋 : : ) By rule cons 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푞 퐸 Ψ ⊢ ⟨Σ; : 1 [[(! 1 2)1/ 1] 1] : 2 [()]⟩ : Φ By above equalities Ψ′ = Ψ and Φ′ = Φ Suppose ′ 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푞 퐸 ′ Ψ ⊢ ⟨Σ; : 1 [[(! 1 2)1/ 1] 1] : 2 [()]⟩ : Φ By above equalities Subcase 푐 { 푐2 ′ Ψ2; Δ; · ⊢ 푒 : 푈 where Δ = w , 푥2 :!푇 ⊗ Rd 푆 ⊗ Rd푇 By inversion on choice ○ ⊢ 푣 : 푇 By inversion on wr ⊢ ! 푣 :!푇 By rule bang 푣, 푐 , 푐 푇 푆 푇 ⊢ (! 1 2)1 :! ⊗ Rd ⊗ Rd By rule apair , 푣, 푐 , 푐 푥 푒 푈 ′ Ψ2 w ; · ⊢ (! 1 2)1/ 2] 2 : By Lemma B.8 ○, 퐸 푣, 푐 , 푐 푥 푒 푈 Ψ1 Ψ2 ⊢ 1 [[(! 1 2)1/ 2] 2] : By Lemma B.6 퐸 푣, 푐 , 푐 푥 푒 푈 Ψ ⊢ 1 [[(! 1 2)1/ 2] 2] : By above equalities Ψ ⊢ ⟨Σ; 휋⟩ : Φ휋 Above 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푝 푈 Ψ ⊢ ⟨Σ; : 1 [[(! 1 2)1/ 2] 2]⟩ : (Φ휋 : ) By rule cons Ψ4 ⊢ ( ) : 1 By rule unit Ψ3, Ψ4 ⊢ 퐸2 [()] : 푉 By Lemma B.6 Ψ ⊢ 퐸2 [()] : 푉 By above equalities 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푞 퐸 , 푝 푈 , 푞 푉 Ψ ⊢ ⟨Σ; : 1 [[(! 1 2)1/ 2] 2] : 2 [()]⟩ : (Φ휋 : : ) By rule cons 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푞 퐸 Ψ ⊢ ⟨Σ; : 1 [[(! 1 2)1/ 2] 2] : 2 [()]⟩ : Φ By above equalities Ψ′ = Ψ and Φ′ = Φ Suppose ′ 휋, 푝 퐸 푣, 푐 , 푐 푥 푒 , 푞 퐸 ′ Ψ ⊢ ⟨Σ; : 1 [[(! 1 2)1/ 2] 2] : 2 [()]⟩ : Φ By above equalities

□ C Confluence The following lemmas state structural invariants over write effects and read endpoints of a well-typed configuration: atmost one process owns the write token w , and every read endpoint is a non-duplicable (affine) resource. ○ Lemma C.1 (Unique writer process). If 퐶 is a well-typed configuration with process pool 휋, then there exists at most one process in 휋 that owns the write token w (i.e., has w in its affine context). ○ ○ Proof. By structural induction over the typing derivation for 퐶. □ Lemma C.2 (Unique reader process). If 퐶 is a well-typed configuration with process pool 휋, and 푐 is a read endpoint in this configuration, then there exists at most one process in 휋 where 푐 appears. Proof. By structural induction over the typing derivation for 퐶. □ 23 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

Theorem C.3 (Single-step confluence). For all well-typed configurations 퐶, if 퐶 −→ 퐶1 and 퐶 −→ 퐶2 then there exists renaming a function 푓 such that either:

1. 퐶1 = 푓 (퐶2), or 2. there exists 퐶3 such that 퐶1 −→ 퐶3 and 푓 (퐶2) −→ 퐶3.

Proof. By induction on the pair of steps ⟨퐶 −→ 퐶1 , 퐶 −→ 퐶2⟩. We consider the following cases: Case congruence If either step uses congr, we apply the inductive hypothesis. Case independent processes If both steps advance distinct processes, using any of the rules local, fork and nu, we produce 퐶3 by combining those two (independent) steps. Case one process If both steps advance the same process, we show that this is deterministic (up to naming) by constructing the naming function 푓 such that 퐶2 = 푓 (퐶1). Most cases are straightforward since they perform no nondeterministic choices. The only source of nondeterminism is the name choices, in rules nu and fork. In each case, we map the name choice from the second step to that of the first step. Case interaction If either step uses rw or cw, we rely on Lemmas C.1 and C.2 to show that both steps use either rw or cw, and that the reader-writer process pair is unique. □ By composing multiple uses of this theorem we prove multi-step confluence. However, to carry forth this composition, we need a more general notion of single-step confluence, which is parameteric in a renaming function for the initial configurations.

Theorem C.4 (Single-step confluence, generalized). For all well-typed configurations 퐶 and renaming functions 푓 , if 퐶 −→ 퐶1 and 푓 (퐶) −→ 퐶2 then there exists renaming function 푔 such that either: 1. 퐶1 = 푔(퐶2), or 2. there exists 퐶3 such that 퐶1 −→ 퐶3 and 푔(퐶2) −→ 퐶3. Proof. Analogous to the proof of Theorem C.3 (single-step confluence). □ We prove a full confluence theorem that is generalized similarly, by accepting a renaming function 푓 to produce a new function 푔: ∗ ∗ Theorem C.5 (Full confluence). For all well-typed configurations 퐶, and renaming functions 푓 , if 퐶 −→ 퐶1 and 푓 (퐶) −→ 퐶2 and 퐶1 term and 퐶2 term then there exists a renaming function 푔 such that 퐶1 = 푔(퐶2). ∗ ∗ Proof. By induction on the reduction sequence pair ⟨퐶 −→ 퐶1 , 푓 (퐶) −→ 퐶2⟩. Because of single-step confluence, we know that if either reduction sequence is empty, then the other must be empty, and that if either takes a step, the other must take a step. Case empty When empty, we have the resulting renaming function 푔 via single-step confluence. Case step 퐶 퐶 ′ 퐶 ′ ∗ 퐶 푓 퐶 퐶 ′ We consider the case where each reduction consists of at least one step: −→ 1 and 1 −→ 1 and ( ) −→ 2 and 퐶 ′ ∗ 퐶 푔 푔 퐶 ′ 퐶 ′ 2 −→ 2. By single-step confluence, we have that there exists 0 such that 0 ( 2) = 1. By the inductive hypothesis, we have that there exists 푔 such that 퐶1 = 푔(퐶2). □

24 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

D ILC Implementation of execUC The full implementation of the UC execution experiment is given in Figure 10. data Crupt = CruptP | CruptQ | CruptNone corruptOrNot :: ∀ ... . 퐴p → Nat → [Bit] → Bool → · · · let corruptOrNot p k bits iscrupt toZ toF toA toQ frZ frF frA frQ= if iscrupt then let _ = rd frZ in error "Z can't wr to corrupt" |▷ fwd toA frF |▷ fwd toA frQ |▷ fwd toF frA else p k bits toZ toF toQ frZ frF frQ

퐴 퐴 퐴 퐴 퐴 B execUC :: z→w p × q → f → a → Crupt → Nat → [Bit] → Bit | let execUC z (p,q) f a crupt k r = Z 휈 (rZ2P, wZ2P), (rP2Z, wP2Z) ,(rZ2Q, wZ2Q),(rQ2Z, wQ2Z) ,(rP2F, wP2F), (rF2P, wF2P) ,(rQ2F, wQ2F), (rF2Q, wF2Q) ,(rF2A, wF2A), (rA2F, wA2F) A F ,(rA2Z, wA2Z), (rZ2A, wZ2A) , (rP2A, wP2A), (rA2P, wA2P) , (rQ2A, wQ2A), (rA2Q, wA2Q) ,(rP2Q, wP2Q),(rQ2P, wQ2P) . let (rf,ra,rp,rq,rz) = splitBits r in f k rf crupt wF2P wF2Q wF2A rP2F rQ2F rA2F |▷ a k ra crupt wA2Z wA2F wA2P wA2Q wP2Q rZ2A rF2A rP2A rQ2A |▷ corruptOrNot p k rp (crupt == CruptP) wP2Z wP2F wP2A wP2Q rZ2P rF2P rA2P rQ2P |▷ corruptOrNot q k rq (crupt == CruptQ) wQ2Z wQ2F wQ2A wQ2P rZ2Q rF2Q rA2Q rP2Q |▷ z k rz wZ2P wZ2Q wZ2A rP2Z rQ2Z rA2Z

Figure 10. Full implementation of execUC. The channels follow a uniform naming scheme. The read end of a channel is prefixed with r- and the write end of a channel is prefixed with w-. The channel rZ2P denotes the read end of communications from the environment z to the party p. First, the random bitstring is split amongst each of the five parties. Then, the functionality, the adversary, and both protocol parties are spawned in a child process (given the appropriate channels and parameters), and the process continues as the environment process. Notice that parties are run in wrapper functions, which alter their behavior depending on whether or not they are corrupted. If a party is corrupted, then the adversary masquerades as the party.

25 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller

E Extending ILC with Trapdoor of the two cases applies. The intuitive explanation why this Permutations is binding is that it is difficult to find a pair 푦,푦 ⊕ 휎 that are UC Commitments are realized from cryptographic primitives, respectively in the range of both prgs. such as trapdoor permutations, which require extensions to The UC proof consists of two simulators, one for the ideal world and one for the real world. The ideal world simula- ILC. The new syntactic forms are kgen, tdp, inv, and hc with tor, given in Figure 17 is ported directly from the UC litera- the static and dynamic semantics shown in Figure 11. The semantics are written in terms of the cryptographic objects ture [19], while the non-standard real world simulator, given themselves. in Figure 18, is required because our protocol emulation def- inition requires simulation in both directions. The key to The key generation function keygen takes as input a ran- dom bitstring and outputs a random public key 푣 and a the ideal world simulator is to allow the simulator to gen- 푝푘 erate its own “fake” CRS, for which it stores the trapdoors. trapdoor 푣 . The trapdoor permutation function tdp takes 푡푑 The string 휎 is not truly random, but instead is the result as inputs a key 푣 and a bitstring 푣 and outputs a bitstring 푝푘 푖푛 of combining two evaluations of the prgs. The ideal world 푣표푢푡 . The inv function takes as inputs a key-trapdoor pair (푣 , 푣 ) and a bitstring 푣 and outputs a bitstring 푣 . The simulator consists of two cases, depending on which of the 푝푘 푡푑 푖푛 표푢푡 parties is corrupt. hardcore predicate function hc takes as input a key 푣푝푘 and outputs a single bit. In the case that the committer P is corrupt, the simulator needs to be able to the committed value. The simu- We can use these to implement a special pseudorandom extract lator is activated when Z sends a message ( ′ 푦); in number generator 퐺 : {0, 1}푘 → {0, 1}4푘 that has a trap- Commit 푝푘 the real world, this is relayed by the dummy adversary to Q, door property, i.e., it is easy to compute, but difficult to invert who outputs back to the environment. Hence to except with special information called the “trapdoor.” Committed achieve the same effect in the ideal word, the simulator must 퐺 (푟) = (3푛) (푟), ( (3푛−1) (푟)),..., ( (푟)), (푟)
푏 푏 푦 푝푘 f푝푘 B f푝푘 B f푝푘 B send (Commit ) to FCom. To extract from , the simulator makes use of the prg trapdoor check which one has 푦 in its Here, f is a trapdoor permutation over {0, 1}푘 , with f (푖) (푟) 푝푘 푝푘 range. It is necessary to argue by cryptographic reduction th denoting the 푖 -fold application of f푝푘 , and B is a hardcore that this simulation is sound. To show this, we would define predicate for f푝푘 . In ILC, this can be implemented as: an alternative execution where the prg is substituted for a iterate :: ∀ a . Int → (a → a) → a → a truly random function (i.e., a random oracle). If an environ- ment Z could distinguish between these two worlds, then prg :: [Bit] → [Bit] → Nat → [Bit] we could adapt the execution to distinguish the prg from let prg pk r k = random, violating the prg assumption. letrec aux j = In the case that the receiver Q is corrupt, the simulator if j ≤ 0 then [hc r] needs to equivocate. The simulator is activated when Z in- else hc (iterate j (tdp pk) r) : aux pk r (j − 1) in puts (Commit 푏) to P, after which FCom sends Committed iterate (3 ∗ k) (tdp pk) r ++ aux pk r (3 ∗ k − 1) to the simulator. In the real world, the environment receives a commitment message (Commit′ 푦) from corrupted Q for F Universally Composable Commitment some seemingly-random 푦. To achieve the same effect, the Protocol simulator must choose 푦. However, the simulator is next activated when the Z inputs (Open 푏) to P, after which the In this section we give the full elaboration of our UC commit- simulator learns 푏 from F . However, in the real world the ment instantiation. The specification functionality is given Com environment receives a valid opening (Opened′ 푏 푟) that is in the body in Figure1, along with the protocol implementa- consistent with 푦 and with the value chosen by the environ- tion in Section 6.5. Our development follows closely from the ment. Thus the simulator must initially choose 푦 so that it psuedocode in the UC literature [19], which we show here can later be opened to either value 푏 may take. The simula- in Algorithm1. The protocol relies on the CRS functionality tor achieves this by choosing 휎 and 푦 ahead of time while which we define here in Figure 15. To briefly summarize generating the fake CRS. The reduction step is the same, and what is going: the setup CRS samples a random string 휎 involves replacing prg with a true random function. and two trapdoor pseudorandom generators (prgs pk , pk ). 0 1 Recall that the motivation for the real world simulator is to To commit to the bit 푏, the commiter produces a string 푦 rule out degenerate protocols that diverge in some way. For that is the result of applying one or the other of the prgs, every well behaved environment such that the ideal world is and if 푏 = 1 additionally applying xor with 휎. The intuitive PPT, we need to demonstrate an adversary in the real world explanation why this is hiding is that without the trapdoor, that is also PPT. Fortunately, the real world simulator, shown it is difficult to tell whether a random 4푘-bit string is in the in Figure 18 is much simpler than ideal world simulator. range of either prg. To open the commitment, the committer Essentially the simulator runs a copy of the honest protocol simply reveals the preimage and the receiver checks which

26 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA

Expressions 푒 ::= kgen(푒) | tdp(푒1, 푒2) | inv(푒1, 푒2) | hc(푒) Δ; Γ ⊢ 푒 : 푈 Under affine context Δ and unrestricted context Γ, expression 푒 has type 푈 .

Δ; Γ ⊢ 푒 : [Bit] Δ1; Γ ⊢ 푒1 : [Bit] Δ2; Γ ⊢ 푒2 : [Bit] kgen tdp Δ; Γ ⊢ kgen(푒) : [Bit] × [Bit] Δ1, Δ2; Γ ⊢ tdp(푒1, 푒2) : [Bit]

Δ1; Γ ⊢ 푒1 : [Bit] × [Bit] Δ2; Γ ⊢ 푒2 : [Bit] Δ; Γ ⊢ 푒 : [Bit] → Bit inv hc Δ1, Δ2; Γ ⊢ inv(푒1, 푒2) : [Bit] Δ; Γ ⊢ hc(푒) : Bit

푒1 −→ 푒2 Expression 푒1 reduces to 푒2. 푣 푣 , 푣 푣 , 푣 , 푘 푣 , 푣 푣 , 푘 , 푘 , 푘 Gen( 푟 ) = ( 푝푘 푡푑 )∞ 푝푘 푡푑 ∈ {0 1} f ( 푝푘 푖푛) = 표푢푡 f : {0 1} → {0 1} → {0 1} kgen tdp 푣 푣 , 푣 푣 , 푣 푣 kgen( 푟 ) −→ ( 푝푘 푡푑 )∞ tdp( 푝푘 푖푛) −→ 표푢푡

푣 , 푣 , 푣 푣 , 푘 , 푘 , 푘 , 푘 푣 푣 , 푘 , Inv(( 푝푘 푡푑 )∞ 푖푛) = 표푢푡 Inv: {0 1} × {0 1} → {0 1} → {0 1} B( 푝푘 ) = B: {0 1} → {0 1} inv hc 푣 , 푣 , 푣 푣 푣 푣 inv(( 푝푘 푡푑 )∞ 푖푛) −→ 표푢푡 hc( 푝푘 ) −→

Figure 11. Extending ILC with trapdoor permutations. The semantics are parameterized by a security parameter 푘. for each of the corrupted parties. The simulation that results Protocol 1: Universally Composable Commitment in this case is identical. 1 Public strings: 4푛 2 휎: Random string in {0, 1} 푝푘 , 푝푘 3 0 1: Keys for generator 푛 4푛 퐺푘 : {0, 1} → {0, 1} 4 Commit(푏): 푛 5 푟 ← {0, 1} 6 푦 퐺 (푟) B 푝푘푏 7 if 푏 = 1 then 푦 B 푦 ⊕ 휎 8 Send (Commit,푦) to receiver. 9 Upon receiving (Commit,푦) from 퐴, 퐵 outputs (Receipt). 10 Decommit(푥): 11 Send (푏, 푟) to receiver. 12 푦 = 퐺 (푟) 푏 = Receiver checks 푝푘푏 for 0, or 푦 = 퐺 (푟) ⊕ 휎 푏 = 푝푘푏 for 1. If verification succeeds, then 퐵 outputs (Open,푏).

27 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller dummy :: ∀ a ... . Nat → [Bit] → Crupt → · · · a let dummyA k bits crupt toZ toF toP toQ toQasP frZ frF frP frQ = let fwd2Z () c = loop (휆 m . wr (X2Z m) → toZ) c in loop (휆 x . match x with | A2F m ⇒ wr m → toF | A2P m ⇒ if crupt == CruptP then wr m → toQasP else wr m → toP) frZ |▷ fwd2Z () frF |▷ fwd2Z () frP |▷ fwd2Z () frQ

Figure 12. Dummy adversary. The dummy adversary forwards messages from the environment to either the functionality (if the message has constructor A2F) or the party p (if the message has constructor A2P). Similarly, the dummy adversary forwards messages from the functionality or the procotol parties to the environment. dummyP :: ∀ a b ... . Nat → [Bit] → Wr a → · · · b let dummyP k r toZ toF toQ frZ frF frQ = fwd toF frZ |▷ fwd toZ frF

Figure 13. Dummy party. The dummy party simply relays information between the environment and the functionality. fCrs :: ∀ a ... . Nat → [Bit] → Crupt → · · · a let fCrs k bits crupt toP toQ toA frP frQ frA = let (휎, bits) = sample (4∗k) bits in let (r0, bits) = sample k bits in let (r1, bits) = sample k bits in let pk0 = kgen k r0 in let pk1 = kgen k r1 in 휎 let pub = PublicStrings pk0 pk1 in let replyCrs to fr = loop (휆 _. wr pub → to) fr in replyCrs toP frP |▷ replyCrs toQ frQ |▷ replyCrs toA frA

Figure 14. Ideal functionality for common reference string.

28 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA bCrs :: ∀ a ... . Nat → [Bit] → Crupt → · · · a let bCrs k bits crupt toP toQ toA frP frQ frA = let (r0, bits) = sample k bits in let (r1, bits) = sample k bits in let pk0 = kgen k r0 in let pk1 = kgen k r1 in 휎 let = xors (prg pk0 r0) (prg pk1 r1) 휎 let pub = PublicStrings pk0 pk1 in let replyCrs to fr = loop (휆 _. wr pub → to) fr in replyCrs toP frP |▷ replyCrs toQ frQ |▷ replyCrs toA frA

Figure 15. Bad ideal functionality for common reference string.

fCom :: Nat → [Bit] → Crupt → · · · ⊸ R 1 let fCom k bits crupt toP toQ toA frP frQ frA = let (!(Commit b), frP) = rd frP in wr Receipt → toQ ; let (!Open, frP) = rd frP in wr (Opened b) → toQ

Figure 16. Ideal functionality for one-time bit commitment.

29 PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA Kevin Liao, Matthew A. Hammer, and Andrew Miller simI :: Nat → [Bit] → Crupt → · · · ⊸ 1 let simI k bits crupt toZ toF toP toQ frZ frF frP frQ =

let (pk0,td0) = kgen k in let (pk1,td1) = kgen k in let (r0, bits) = sample k bits in let (r1, bits) = sample k bits in 휎 let = xors (prg pk0 r0) (prg pk1 r1) in match crupt with | CruptP ⇒ let (!GetCRS, frZ) = rd frZ in 휎 wr (X2Z (PublicStrings pk0 pk1)) →toZ ; let (!(A2P (Commit' y)), frZ) = rd frZ in

if check td0 pk0 y then wr (Commit 0) → toP else 휎 if check td1 pk1 (xors y ) then wr (Commit 1) → toP else error "Fail" ; let (!(A2P (Open' b r)), frZ) = rd frZ in

if b == 0 && y == prg pk0 r || 휎 b == 1 && y == xors (prg pk1 r) then wr Open → toP else error "Fail" | CruptQ ⇒ let (!GetCRS, frZ) = rd frZ in 휎 wr (X2Z (PublicStrings pk0 pk1)) → toZ ; let (!Receipt, frQ) = rd frQ in

let y = prg pk0 r0 in wr (X2Z (Commit' y)) → toZ ; let (!(Opened b'), frQ) = rd frQ in if (b' == 0) then wr (X2Z (Opened' r0)) → toZ else wr (X2Z (Opened' r1)) → toZ | CruptNone ⇒ error "Fail"

Figure 17. Ideal world simulator for UC commitment.

30 ILC: A Calculus for Composable, Computational Cryptography PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA simR :: Nat → [Bit] → Crupt → · · · ⊸ 1 let simR k bits crupt toZ toF toP toQ frZ frF frP frQ = match crupt with | CruptP ⇒ let (!(Commit b), frZ) = rd frZ in wr GetCRS → toF ; 휎 let (!(PublicStrings pk0 pk1), frF) = rd frF in let r = take k bits in 휎 let y = if b == 0 then prg pk0 r else xors (prg pk0 r) in wr (Commit' y) → toQ ; let (!(Open), frZ)= rd frZ in wr (Open' b r) → toQ | CruptQ ⇒ let (!(Commit' y), frQ) = rd frQ in wr Receipt → toZ ; let (!(Open' b r), frQ) = rd frQ in wr (Opened b) → toZ | CruptNone ⇒ error "Fail"

Figure 18. Real world simulator for UC commitment.

31