SSProve: A Foundational Framework for Modular Cryptographic Proofs in Coq

We begin by introducing our variant of the SSP methodology of Brzuska et al. [40]. The main concept behind this methodology is the package, which is a collection of procedure implementations that together manipulate a common piece of state, and that may depend on a set of external procedures. We refer to the set of external procedures on which the package can depend as the imports of the package. In Figure 1, we can see a high-level picture of a package P: It implements and exports the procedures \(\mathtt {X}\) and Y, and it imports the external procedure Z. The arrows indicate the direction of calls, i.e., exports that can be called from the outside point towards \(\texttt {P}\) and imports point away. We use \({\mathtt {import}({P})}\) to denote the set of procedure names the package P imports, and \({\mathtt {export}({P})}\) to denote the names of the procedures it exports. The term interface is used to refer to such a set of procedure names.¹ While the import and export interfaces of a package tell us where it can be used, in the SSP papers, the package implementations are usually given in separate figures, which describe, in pseudocode, each of the procedures exported by the package. For example, a possible pseudocode implementation corresponding to the package P can be found in Figure 2. We refer to the code of the procedure \(\mathtt {X}\) exported by package P as \(P.\mathtt {X}\) .

In Figure 2, we can also see that the package implementation also depends on some memory location \(\texttt {n}\) , which can be read and updated as shown in procedures \(\texttt {X}\) and \(\texttt {Y}\) , respectively. In SSP, such memory cells are implicitly initialized to default values depending on their type; here initially \(\texttt {n = 0}\) . In SSProve memory locations refer to a shared global memory and the declaration “ \(\texttt {mem: n : nat}\) ” in package P should be understood as: \(\texttt {n}\) is the only global memory location that is used by the procedures of P.

Package algebra. Packages can be combined as algebraic objects. We can build complex packages out of simpler ones using the following composition operations:

In SSProve sequential and parallel composition are defined even in cases in which the composed packages use the same global memory locations, which allows state sharing.

These operations have graphical counterparts, which we show in Figure 3: parallel composition (Figure 3(a)) is represented by stacking packages on top of each other; sequential composition (Figure 3(c)) is obtained by merging the input arrows of one of the packages with the output arrows of the other; finally the identity package (Figure 3(b)) is essentially silent when represented graphically, its presence being notified by longer arrows. Moreover, there are natural algebraic laws that hold between these operators. For example, sequential composition is an associative operator, which formally we can state by the following equation:Graphically these laws are obtained by simply forgetting about the dashed boxes (which represent parenthesizing) and by stretching arrows. In the SSP methodology, the \(\stackrel{ {\mbox{code}}}{\equiv }\) symbol stands for code equality between the packages: two packages are equal if the implementations of their procedures are equal to each other. As in SSProve code equality corresponds precisely to syntactic equality (including using the same global memory locations), we will write \(P = Q\) instead of \(P \stackrel{ {\mbox{code}}}{\equiv }Q\) in the remainder of the article. The aforementioned algebraic package laws (see Section 3.4 for details) are convenient for cryptographic proofs, since they allow the compositional structure of a package to be manipulated without having to look at all at the implementation of its procedures.

Games and distinguishers. A package with no imports is called a game. A game pair \({G}^{01}\) contains two games that export the same procedures, i.e., \({G}^{01} = ({G}^{0}, {G}^{1})\) such that \({\mathtt {export}({{G}^{0}})} = {\mathtt {export}({{G}^{1}})}\) and \({\mathtt {import}({{G}^{b}})} = \emptyset\) for \(b = 0, 1\) . A distinguisher for a game pair is a package \(\mathcal {D}\) with \({\mathtt {import}({\mathcal {D}})} = {\mathtt {export}({{G}^{0}})} = {\mathtt {export}({{G}^{1}})}\) and \({\mathtt {export}({\mathcal {D}})} = { \mathsf {Run}}\) , where \(\mathsf {Run}\) is an entry-point procedure that can call the procedures exported by the games and returns a Boolean value: \(\mathsf {true}\) or \(\mathsf {false}\) . When a game \({G}^{b}\) exports a single procedure \(\mathsf {Run}: \mathtt {unit} → \mathtt {bool}\) as above, we denote by \(\mathrm{Pr} [ \mathsf {true} \leftarrow G ]\) the probability that \(G.\mathsf {Run}\) returns the Boolean value \(\mathsf {true}\) when running on initial memory. We can quantify how much a distinguisher can distinguish the two packages in a game pair:

Reasoning about advantage. Next, we review the two main results used for equational-like reasoning about advantage against games in SSP:

In general, we want to bound the advantage to distinguish \({G}^{0}\) and \({G}^{n}\) (i.e., the advantage \(\alpha ({G}^{0}, {G}^{n})(\mathcal {D})\) against game pair \(({G}^{0}, {G}^{n})\) ). To do so, by repeatedly applying Lemma 2.2, it is enough to exhibit a chain of games \({G}^{0}, {G}^{1}, {G}^{2}, \ldots , {G}^{n}\) so that a bound for \(\alpha ({G}^{0},{G}^{n})(\mathcal {D})\) can be given by

As its name indicates, Lemma 2.3 is used to reduce the advantage of the distinguisher over a composed game pair ( \(P \circ {G}^{0}, P \circ {G}^{1}\) ) to the advantage over part of the game pair \({G}^{01}\) , for which we know a bound. We will use both these SSP lemmas in Section 2.3.

Shared state. As mentioned above, in SSProve, we use a shared global memory and composed packages can share state. In particular our sequential and parallel composition are defined even in cases in which the composed packages use the same memory locations. This was easy to formalize in Coq, and it allowed us to prove formally that the algebraic laws for package composition as well as the two lemmas above hold even when the involved packages share state.

This treatment of state in SSProve is quite different from the original SSP [40], in which composed packages have to always be “state separated” (i.e., have disjoint state). To make the state of packages disjoint they allow for \(\alpha\) -renaming of state variables—which shows up for instance in their definition of code equality. Such informal \(\alpha\) -renaming conventions are generally more difficult to formalize in a proof assistant [2, 14, 96]. Yet in the absence of \(\alpha\) -renaming, requiring state disjointness everywhere would only increase the proof burden and the clutter in the proved security results (it would require the adversary’s state to be disjoint from all intermediate games in the proof).

Adversaries. State separation is, however, still crucial for defining adversaries against game pairs. An adversary \(\mathcal {A}\) for a game pair is a distinguisher whose memory footprint is disjoint from the footprint of each game in the pair. We define adversaries, the memory footprint of a package, and disjointness of footprints more formally in Definition 3.3.

Perfect game indistinguishability. We say that the games \({G}^{0}\) and \({G}^{1}\) of a game pair \({G}^{01}\) are perfectly indistinguishable when \(\alpha ({G}^{01})(\mathcal {A}) = 0\) for every adversary \(\mathcal {A}\) . Perfect indistinguishability is a form of observational equivalence and states that no adversary can learn any information about which game in the pair it is interacting with.

We now present the main novel result brought by SSProve. The SSP laws above deal only with the high-level structure of composed packages. However, we often also need to show that two concrete games are equivalent with respect to what an adversary can learn from using them, i.e., perfect indistinguishability. In SSProve, we formally verify this kind of equivalence by reducing it to proving a family of semantic judgments in a probabilistic relational program logic. The logic we use is a variant of pRHL, a probabilistic relational Hoare logic introduced by Barthe et al. [26] in CertiCrypt. Judgments of this logic are of the formand intuitively mean that after separately running the two code fragments \(c_0\) and \(c_1\) on the corresponding component of a pair of memories \(m_0, m_1\) satisfying a precondition \(\phi\) , the final memories \(m_0^{\prime }, m_1^{\prime }\) and results \(a_0, a_1\) satisfy the postcondition \(\psi\) . When writing pre- and postconditions, we write as \(p.\,M\) a function that binds p and has body M (usually denoted by \(\lambda p.\,M\) in the functional programming community).² This notation is handy for writing postconditions, which depend on final memories and on final results. We adopt the convention that the variables \(m_0\) and \(m_1\) stand for the state associated to \(c_0\) and \(c_1\) in preconditions, the initial memories, and \(m_0^{\prime }, m_1^{\prime }\) stand for the corresponding state in postconditions, the final memories. We will omit them from judgments when no ambiguity can arise. We now state the main theorem of SSProve:

Intuitively, we ask that both procedures, when run on memories satisfying \(\psi\) , yield results drawn from the same distribution and memories still satisfying \(\psi\) . We leave the precise definition of stable invariants and how this theorem is proved to Section 4.2, but the main idea behind this invariant is that it keeps track of a relation between the memories of \({G}^{0}\) and \({G}^{1}\) , and that this relation is preserved as different procedures from the interface are called during the execution. This can be understood as a bisimulation argument between packages, where transitions between states come from procedure calls. We illustrate how this theorem is used in the examples from the next two subsections.

We first illustrate the key ideas of SSProve on a cryptographic proof by Brzuska et al. [40] that we have verified in Coq using our framework. In this proof, reasoning about composed packages (using Lemmas 2.2 and 2.3 above) allows for a high level of abstraction that drives the proof argument. Some steps of this proof are, however, justified by perfect indistinguishability between games, which involves inspecting the procedures of the games and applying program transformations to show the equivalence. In the previous paper proof [40] these steps were only justified informally by code inspection. Instead, we have formally verified these steps too, using Theorem 2.4 and our relational program logic.

Brzuska et al. [40] show how to construct a symmetric encryption scheme out of a PRF and use the SSP methodology to reduce security of the encryption scheme—expressed as IND-CPA—to the security of the pseudo-random function, expressed as being indistinguishable from a package doing random sampling.

The scheme assumes a pseudo-random function called \(\mathtt {prf}\) with the following signature:where \({&#x0007B; 0, 1 &#x0007D; ^n}\) represents the set of n-bit sequences. It is possible to formalize and quantify the security of PRF-based encryption as the probability for an adversary to distinguish it from a package that samples from a uniform distribution (real versus random paradigm [86]). Concretely, given the packages \({\mathtt {PRF}}^{0}\) and \({\mathtt {PRF}}^{1}\) as in Figure 4, where “<$ uniform S” represents uniform sampling from set \(\texttt {S}\) , the advantage of an adversary \(\mathcal {A}\) against the game \({\mathtt {PRF}}^{01} = ({\mathtt {PRF}}^{0}, {\mathtt {PRF}}^{1})\) is defined using Definition 2.1 as follows:The three basic algorithms we use to construct a symmetric encryption scheme out of \(\mathtt {prf}\) are given in Figure 5. These are not packages themselves but rather code used inside packages.

The security property proposed for this encryption scheme is defined as the advantage on a game pair that captures indistinguishability under chosen-plaintext attack (IND-CPA). We refer to this game pair as \({\mathtt {IND-CPA}}^{01}\) , and the packages involved are introduced in Figure 6. Notice that in procedure \({\mathtt {IND-CPA}}^{1}.\mathsf {Enc}\) the argument \(\mathtt {msg}\) is never used, the encryption procedure is run on a random \(\mathtt {msg^{\prime }}\) . Therefore, the advantage of an adversary with respect to the game pair \({\mathtt {IND-CPA}}^{01}\) represents the probability that the adversary is able to distinguish the encryption of \(\mathtt {msg}\) from the encryption of a random bit-string. The security of the encryption procedure with respect to an adversary \(\mathcal {A}\) against \({\mathtt {IND-CPA}}^{01}\) is then \(\alpha ({\mathtt {IND-CPA}}^{01})(\mathcal {A})\) .

Brzuska et al. [40] use a sequence of game-hops to bound \(\alpha ({\mathtt {IND-CPA}}^{01})\) in terms of (a linear function of) the advantage \(\alpha ({\mathtt {PRF}}^{01})\) . This technique of game-hops follows the style of inequality reasoning chains from Section 2.1 (Lemma 2.2), where each step involves establishing the advantage on a game pair, and as a result we obtain a bound on the advantage of the game consisting of the initial and final game.

In this example, \({\mathtt {IND-CPA}}^{b}\) is shown equivalent to a variant, \({\mathtt {MOD-CPA}}^{b}\) , that gets the pad through the PRF, i.e., with a call to \(\mathtt {Eval}\) of the package \({\mathtt {PRF}}^{0}\) or \({\mathtt {PRF}}^{1}\) (see Figure 7). By repeatedly applying Lemma 2.2, we bound \(\alpha ({\mathtt {IND-CPA}}^{01})(\mathcal {A})\) byBy observing that \(\alpha ({\mathtt {IND-CPA}}^{0}, {\mathtt {MOD-CPA}}^{0} \circ {\mathtt {PRF}}^{0})(\mathcal {A}) = 0\) and \(\alpha ({\mathtt {MOD-CPA}}^{1} \circ {\mathtt {PRF}}^{0}, {\mathtt {IND-CPA}}^{1})(\mathcal {A}) = 0\) , and by using Lemma 2.3 twice, we reduce this bound towhere \(\varepsilon _{\it stat.} = \alpha ({\mathtt {MOD-CPA}}^{0} \circ {\mathtt {PRF}}^{1},\ {\mathtt {MOD-CPA}}^{1} \circ {\mathtt {PRF}}^{1})\) . The advantage of an attacker with respect to \({\mathtt {MOD-CPA}}^{0}\) and \({\mathtt {MOD-CPA}}^{1}\) is usually referred to as statistical gap, a polynomial function of the number of calls from the adversary (see Reference [40, Appendix A]). One could prove a precise bound based on the birthday paradox here [40, Appendix A], but this would require formal reasoning about failure events [26]. It would be useful to extend SSProve in the future with a unary, union bounds logic for adding more precision to such steps [23].

We can informally interpret the formally proved bound above as saying that if the advantage of \(\mathcal {A}\circ {\mathtt {MOD-CPA}}^{b}\) against PRF and the statistical gap are negligible then the advantage of \(\mathcal {A}\) against \({\mathtt {IND-CPA}}^{01}\) is also negligible, under the additional assumption that \(\mathcal {A}\) is probabilistic polynomial time and has disjoint state from \({\mathtt {PRF}}^{1}\) , so that \(\mathcal {A}\circ {\mathtt {MOD-CPA}}^{b}\) is an adversary against \({\mathtt {PRF}}^{01}\) . While this disjointness assumption is needed at the top level, when applying Lemma 2.2 for reducing the advantage of the adversary \(\mathcal {A}\) for game pair \({\mathtt {IND-CPA}}^{01}\) , we are basically using \(\mathcal {A}\) as a distinguisher, which does not introduce additional state disjointness requirements, i.e., for applying Lemma 2.2, the state of \(\mathcal {A}\) is only required to be disjoint from \({\mathtt {IND-CPA}}^{01}\) , not from \({\mathtt {MOD-CPA}}^{b}\) and \({\mathtt {PRF}}^{b}\) .

It remains to justify the two perfect indistinguishability statements above. These steps involve replacing an informal argument [40] by a fully formal one, moving to our probabilistic relational program logic. We will detail one of these steps: \(\alpha ({\mathtt {IND-CPA}}^{0},\ {\mathtt {MOD-CPA}}^{0} \circ {\mathtt {PRF}}^{0})(\mathcal {A}) = 0\) . The other step, \(\alpha ({\mathtt {MOD-CPA}}^{1} \circ {\mathtt {PRF}}^{0},\ {\mathtt {IND-CPA}}^{1})(\mathcal {A}) = 0\) , is analogous.

To prove this equivalence, Brzuska et al. [40] notice that the Enc procedures of \({\mathtt {IND-CPA}}^{0}\) and \({\mathtt {MOD-CPA}}^{0} \circ {\mathtt {PRF}}^{0}\) (see Figure 8) return the same distributions of ciphertext when called on the same \(\mathtt {msg}\) . The two procedures are obtained by “inlining” the code of \({\mathtt {PRF}}^{0}.\texttt {Eval}\) inside \({\mathtt {MOD-CPA}}^{0}\) , and by “unfolding” the code of \(\mathtt {enc}\) .

The left- and right-hand side procedures in Figure 8 only differ when \(\mathtt {k} = \bot\) , in which case the left Enc procedure first samples k and then r, while the right Enc first samples r and then k. In both procedures, k and r are drawn from independent distributions. Here, Brzuska et al. [40] conclude informally that independence allows to “swap” the two operations. We instead use Theorem 2.4 to formally reduce \(\alpha ({\mathtt {IND-CPA}}^{0}, {\mathtt {MOD-CPA}}^{0} \circ {\mathtt {PRF}}^{0})(\mathcal {A}) = 0\) to showing the equivalence of the two Enc procedures from Figure 8. In our probabilistic relational program logic, this comes down to proving the following judgment for all plaintext messages \(\texttt {msg}\) ,This judgment intuitively states that encrypting \(\texttt {msg}\) with the same initial memories “ \(m_0 = m_1\) ,” terminates in memories and ciphertexts drawn from the same distribution, “ \(m_0^{\prime } = m_1^{\prime } \wedge rc_0 = rc_1\) .” We use the following instance of the \(\mathtt {swap}\) rule from Section 4.1, to formally justify this swapping:³

We also illustrate the key ideas of SSProve on a security proof for the ElGamal encryption scheme inspired by The Joy of Cryptography textbook [86, Chapter 15.3]. ElGamal belongs to the family of public-key or asymmetric encryption schemes, which use a public key for encryption and a private key for decryption. Public-key schemes therefore require a key generation algorithm producing the pair of public and private keys. In our formalization, it suffices to provide the aforementioned algorithms together with key-, plaintext-, and cipher-spaces to automatically obtain a public-key scheme together with its related security notions (to be proved) such as security against CPA. In what follows, we describe which spaces and algorithms define ElGamal and the security proof we provided for it.

ElGamal is parameterized by a multiplicative cyclic group \((\mathcal {G}, \texttt {*})\) with n elements and with generator g, usually denoted by \(\left\lt g\right\gt = \mathcal {G}\) . Plaintexts are elements \(msg \in \mathcal {G}\) and ciphertexts are pairs of group elements \(c = (c_{\mathit {rnd}}, c_{\mathit {msg}}) \in \mathcal {G}\times \mathcal {G}\) . Secret keys are elements of \(\mathbb {Z}_{n}\) , while public keys are group elements once again, \(\mathtt {pk} \in \mathcal {G}\) . The key generation algorithm (KeyGen in Figure 9) generates a secret key that is a random number \(\texttt {sk} \in &#x0007B; 0, \ldots , n - 1 &#x0007D;\) and a public key that is \(g^{\texttt {sk}}\) . Encryption and decryption (Enc and Dec in Figure 9) involve the group operation \((_*_)\) , exponentiation \((_)-\) and the multiplicative inverse \((_)^{-1}\) . Encryption works probabilistically, generating an ephemeral key rnd to derive a shared secret shs, which is used to encrypt the plaintext message msg.

Under the Decisional Diffie–Hellman (DDH) assumption for the group \(\mathcal {G}\) , namely, that \({\mathtt {DDH}}^{0}\) and \({\mathtt {DDH}}^{1}\) from Figure 10 are computationally indistinguishable, one can prove that an adversary cannot distinguish messages encrypted with the ElGamal scheme from ciphertexts that are randomly sampled (CPA). Our formalization only considers the case in which the adversary can see a single ciphertext (one-time CPA, written OT-CPA), as it is known that this suffices for public-key encryption schemes to satisfy CPA [86, Claim 15.5]. We leave the formalization of this last result as future work and discuss hereafter our proof of OT-CPA in SSProve.

The security property OT-CPA is expressed in terms of the advantage against game pair \({\mathtt {CPA}}^{01}\) in Figure 11. An adversary \(\mathcal {A}\) can call Get_pk() and get the public key, if already initialized.⁴ The adversary can “challenge” a package to encrypt a certain plaintext \(\mathtt {msg}\) through \(\mathtt {Challenge(msg)}\) . Both packages return a ciphertext only if the counter is 0—as expressed by the use of assert—so the adversary can only see one ciphertext. Both packages call KeyGen to generate public and private keys, but while \({\mathtt {CPA}}^{0}\) indeed encrypts the message provided by the adversary with the public key through Enc(pk, msg), the package \({\mathtt {CPA}}^{1}\) instead returns a randomly sampled ciphertext (c_rnd, c_msg) <$ uniform \({\mathcal {G}\times \mathcal {G}}\) , i.e., a pair of group elements sampled from the uniform distribution on \(\mathcal {G}\times \mathcal {G}\) .

The OT-CPA proof reduces the advantage of adversary \(\mathcal {A}\) against \(({\mathtt {CPA}}^{0}, {\mathtt {CPA}}^{1})\) to the advantage of \(\mathcal {A}\circ \mathtt {MOD-CPA}\) against \(({\mathtt {DDH}}^{0},{\mathtt {DDH}}^{1})\) , with the auxiliary package \(\mathtt {MOD-CPA}\) listed in Figure 12:We once again obtain this result by repeatedly applying Lemma 2.2 to bound \(\alpha ({\mathtt {CPA}}^{01})(\mathcal {A})\) byWe prove that the first and last advantages are null by proving the packages perfectly indistinguishable, and the remaining advantage is equal to \(\alpha ({\mathtt {DDH}}^{01})(\mathcal {A}\circ \mathtt {MOD-CPA})\) by simple application of Lemma 2.3. It now remains to show the equivalences below:

Step \(\alpha ({\mathtt {CPA}}^{0}, \mathtt {MOD-CPA}\circ {\mathtt {DDH}}^{0})(\mathcal {A}) = 0\) : We apply Theorem 2.4 and reduce the goal to a relational judgment between \({\mathtt {CPA}}^{0}\texttt {.Challenge(msg)}\) and \((\mathtt {MOD-CPA}\circ {\mathtt {DDH}}^{0})\texttt {.Challenge(msg)}\) for a generic plaintext msg, and where the invariant \(\psi\) is equality of memories. Inlining the code of Query provided by \({\mathtt {DDH}}^{0}\) inside \(\mathtt {MOD-CPA}\) and unfolding one realizes that the two code fragments are identical and the judgment holds by application of the reflexivity rule in Section 4.1.

Step \(\alpha (\mathtt {MOD-CPA}\circ {\mathtt {DDH}}^{1}, {\mathtt {CPA}}^{1})(\mathcal {A}) = 0\) : This step is quite similar to the one above. After inlining, however, the two code fragments are not exactly the same, since in particular \({\mathtt {CPA}}^{1}\) completely ignores \(\mathtt {msg}\) and returns a random ciphertext, while \(\mathtt {MOD-CPA}\circ {\mathtt {DDH}}^{1}\) returns \(\mathtt {msg*g}\) ^{\(\mathtt {rnd^{\prime }}\)} for a random \(\mathtt {rnd^{\prime }}\) . To have equality of memories as invariant \(\psi\) , we show that in \(\mathcal {G}\) , multiplication by \(\mathtt {g^(_)}\) acts like a one time pad, which is a standard result [26, Section 6.2].

The language of the Coq system, Gallina, is a dependently typed, purely functional programming language. As such, we can directly express functional code in Gallina, but not code with side-effects such as reading from and writing to memory, probabilistic sampling, or external procedure calls. We thus represent cryptographic code via a combination of the ambient language Gallina and a monad of effectful computations. Monads constitute an established way of adding effects to a purely functional language [76, 97]. Free monads in particular allow to separate the representation (syntax) of an embedded language from its interpretation (semantics).

Raw code. We use a hybrid approach [78] of embedding the pure fragment of our cryptographic programming language shallowly in Coq, and embedding the effects deeply via a free monad. This free monad is defined as an inductive type:⁵

Some more explanations about \(\texttt {raw_code}\) are in order. The type parameter \(\texttt {A}\) indicates the result of a computation of type \(\texttt {raw_code A}\) . The first clause of the above definition lets us inject any pure value \(\texttt {x}\) of type \(\texttt {A}\) into the monad as return \(\texttt {x}\) . Calls to external procedures are represented via \(\texttt {call p x &#x03BA; }\) , where the first argument \(\texttt {p : opsig}\) specifies the name of the procedure, the type of its argument ( \(\texttt {src p}\) ), and its return type ( \(\texttt {tgt p}\) ). The second argument \(\texttt {x}\) is the input value of type \(\texttt {src p}\) passed to the called procedure. The last argument \(&#x03BA;\) is the continuation of the program, awaiting the result of the call to \(\texttt {p}\) . The \(\texttt {get}\) and \(\texttt {put}\) operations take a (typed) global memory location \(\texttt {&#x2113;}\) as argument, respectively, read from and write to that location, and continue with the continuation \(\texttt {&#x03BA; }\) . Finally, we may sample from a collection of probabilistic subdistributions \(\texttt {Op}\) . Subdistributions constitute the base of our code semantics and are further discussed in Section 3.2. The type \(\texttt {Op}\) is a parameter of the language that can be instantiated by the user. Sampling a subdistribution \(\texttt {op}\) on type \(\texttt {dom op}\) (the domain of the subdistribution) can be composed with a matching continuation \(\texttt {&#x03BA; }\) (continuations are explained below).

We will use the following two pieces of code as running examples to explain different aspects of the definition:The code in (2) increments the value stored at location \(&#x2113;\) by \(\texttt {1}\) and returns the value before the increment. The code in (3) draws a random bit-string \(\texttt {y}\) of length n, calls an external procedure \(\texttt {Prf}\) with arguments \(\texttt {y}\) and bit-string \(\texttt {101010}\) , and returns the result.

Code with locations and interface. Raw code is merely a representation of syntax. To record which imported procedures and global memory locations are used, we introduce a corresponding predicate. We consider the code with respect to set of locations \(\mathcal {L}\) and to an import interface \(\mathcal {I}\) , which is a set of procedure signatures ( \(\texttt {opsig}\) ) consisting of a name, an input type, and an output type. The predicate checks that all reads and writes performed in the code are made to locations in \(\mathcal {L}\) and that all imported procedures belong to \(\mathcal {I}\) . Concretely, the code in (2) uses locations in the singleton set \(\texttt {&#x2113;}\) and has the empty import interface, while (3) uses the empty set of locations and the interface {Prf : {0, 1}ⁿ × {0, 1}ⁿ → {0, 1}ⁿ}. The type \(\texttt {code}\) \(_{\mathcal {L},I}\) is then simply defined as raw code that verifies the predicate corresponding to locations \(\mathcal {L}\) and import interface \(\mathcal {I}\) :In the article, we sometimes omit the set of locations and the interface. Thanks to the use of tactics and Coq’s type classes, proofs regarding these locations and interfaces for well-scoped user-written code are constructed automatically without requiring user intervention.

Locations are typed, which means that each \(\texttt {&#x2113; }\) in \(\mathcal {L}\) is designated a specific type that corresponds to the type of data stored in the respective memory cell. The type assigned to \(\texttt {&#x2113; }\) is denoted by \(\texttt {type &#x2113; }\) .

Continuations. A continuation is a suspended computation awaiting the result of an operation, intuitively corresponding to the rest of the program. Consider for instance the code (2). The \(\texttt {get}\) operation performs a memory lookup at the location \(&#x2113;\) , and its continuation is a Coq function “” of type “” that receives the value stored at \(&#x2113;\) as its parameter \(x_&#x2113;\) . The continuation in turn performs a \(\texttt {put}\) operation, storing the value \(x_&#x2113; + 1\) at memory location \(&#x2113;\) , and returns the value \(x_&#x2113;\) . The code thus corresponds to the expression written as \(\texttt {&#x2113; ++}\) in common imperative languages.

Variables. As demonstrated in example (2), we draw a strict distinction between a location \(&#x2113;\) , which can be accessed and updated via \(\texttt {get}\) and \(\texttt {put}\) , and the value stored in memory at location \(&#x2113;\) . In (2), this value is available in the continuation of \(\mathtt {get \ &#x2113; (\lambda x_&#x2113; . put ...)}\) as \(\mathtt {x_&#x2113; }\) . Formally speaking, \(\mathtt {x_&#x2113; }\) is an immutable Coq variable, and in (2) the location \(&#x2113;\) itself is a Coq variable of type \(\texttt {Location}\) . This distinction is already present in SSP [40, Definition 2], where locations correspond to “state variables” and the ambient, mathematical notion of variable is referred to as “local variable.”

Memory initialization. As mentioned in Section 2.1, memory locations are implicitly initialized to default values depending on their type (for instance in Figure 2 \(\texttt {n}\) is initialized to \(\texttt {0}\) ). Yet, we frequently want to clearly distinguish the case when a location was implicitly initialized to a default value from the case when it was explicitly initialized. For instance, in Figure 6, we want to distinguish the case in which the key \(\texttt {k}\) has not yet been generated from the case in which it has been. To achieve this, we define the type of the \(\texttt {k}\) as option \(\texttt {key}\) , using the following standard definition for the option type:Memory locations of type option \(\texttt {key}\) are implicitly initialized to the dummy value \(\bot\) , which is different from any generated key, which is tagged with the constructor \(\texttt {Some}\) .

Monadic bind. The \(\texttt {bind}\) operation of the monad, with type code A → (A → code B) →code B, allows the composition of effectful code. Take for instance the following pieces of code:We would like to use \(\texttt {c}\) as an argument to \(\texttt {&#x03BA; }\) , but the types do not match: \(\texttt {&#x03BA; }\) expects a value of type \(\texttt {nat}\) as argument, not a computation of type \(\texttt {code nat}\) . We define a standard \(\texttt {bind}\) operation that achieves this by traversing the code of \(\texttt {c}\) , applying \(&#x03BA;\) when a returned value is encountered, and recursively pushing \(&#x03BA;\) into any other continuations:An easy structural induction over \(\texttt {code}\) allows us to prove that \(\texttt {bind}\) satisfies the expected monad laws: bind is associative (bind m (λ p . bind (f p) g) = bind (bind m f) g), and return serves as a unit ( \(\texttt {bind}\) (return x) \(\texttt {f = f x}\) and \(\texttt {bind m}\) return \(\texttt {= m}\) ).

Loops. We do not have syntax for loops in \(\texttt {code}\) . However, since we are embedding in Coq, we take advantage of its recursion mechanisms to write terminating loops. The most basic construction we can write is a “ for i := 0 to N do \(\texttt{c}\) ” loop that repeats \((\texttt {N}{+}1)\) -times a command \(\texttt {c}\) , providing to \(\texttt {c}\) the value of the index \(\texttt {i}\) . In the code below, the pattern matching happens over the natural number \(\texttt {N}\) , which in Coq is represented in unary format, so it is either \(\texttt {0}\) (zero) or \(\texttt {S n}\) (read successor of \(\texttt {n}\) , for some natural number \(\texttt {n}\) ).More generally, we can define a “do-while” loop that repeatedly executes a loop body while a condition holds, checked after each iteration. To ensure termination in Coq, we add a natural number \(\texttt {N}\) to bound the maximum number of iterations:At the end, the returned Boolean signals whether there was remaining fuel (i.e., iteration steps) available or not. In the future, we hope to extend SSProve to potentially non-terminating loops, since the semantic models of probabilistic programs usually support general fixpoints (as further discussed in Section 5.5).

Standard subdistributions. Probabilistic operations denoting a collection of subdistributions we may sample from are included in the type \(\texttt {Op}\) , which is a parameter of our language. Standard subdistributions including uniform sampling on finite types as well as a null subdistribution are predefined for convenience. The null subdistribution in particular allows us to represent failure and an assert construct. Failure at type \(\texttt {A}\) is defined as sampling from the null distribution \(\texttt {dnull}\) .A simple assertion is not expected to produce any interesting values but only gets evaluated for the possibility of failing if the condition is violated. This is expressed by the fact that a successful assert simply returns a value of unit type, where \(\texttt {unit}\) is Coq’s singleton type with a unique inhabitant \(\texttt {()}\) .If \(\texttt {b}\) is true, then assert returns the trivial value \(\texttt {()}\) , but if \(\texttt {b}\) is \(\texttt {false}\) , we instead sample from the \(\texttt {dnull}\) subdistribution via \(\texttt {fail unit}\) , assigning probability zero to all values of the type \(\texttt {unit}\) (i.e., to \(\texttt {()}\) ). Sampling from the null subdistribution is similar to non-termination, and means that the continuation will never be called. This provides a simple and clearly defined semantics for assertion failures. While this is not the only choice [29, 52, 84], this formalizes our understanding of the following informal convention from the paper introducing SSP [40]: “all our definitions and theorems apply only to code that never violates assertions.”

We can see this use of assert in Figure 11 from Section 2.4. The packages \({\mathtt {CPA}}^{b}\) ensure that the Challenge procedure can be called only once by running assert \(\texttt {counter = 0}\) . If the assertion succeeds, then we may assume that \(\texttt {counter = 0}\) holds in the rest of the procedure, until \(\texttt {counter}\) is incremented. We can demonstrate how distinguishers interact with procedures calling assert by computing \(\mathrm{Pr}\![ \mathsf {true} \leftarrow \mathcal {D}\circ {\mathtt {CPA}}^{b} ]\) (as used in Definition 2.1) for a distinguisher \(\mathcal {D}\) that calls \(\texttt {Challenge}\) twice on some fixed message before always returning \(\texttt {true}\) . Even though the distinguisher still returns \(\texttt {true}\) in this scenario, assert will fail the second time the distinguisher calls \(\texttt {Challenge}\) , and thus the subdistribution represented by \((\mathcal {D}\circ {\mathtt {CPA}}^{b})\!.\mathsf {Run}\) becomes the null subdistribution. It follows that \(\mathrm{Pr} [ \mathsf {true} \leftarrow \mathcal {D}\circ {\mathtt {CPA}}^{b} ] = 0\) .

The simple use of assert above is “logical”: We limit the input to certain functions or the ways in which protocols can be called to exploit these assertions in our security reasoning. A more complex use of assertions, which we call “dependent,” occurs in the following example. Consider the situation where we have a memory location \(\texttt {&#x2113; : Location}\) holding a key that is initialized to \(\bot\) . Formally, this amounts to the information \(\texttt {type &#x2113;}\) = option \(\texttt {key}\) , which may be presented in the signature of a package as \(\texttt {mem: &#x2113;}\) : option \(\texttt {key}\) . We did not distinguish immutable variables and locations in Section 2, but we carry out a careful analysis of memory initialization in the KEM-DEM case study in Section 6. For instance, we will see in Figure 14 (Section 6, Page 35) an implementation of a \(\texttt {Get()}\) procedure that returns the key stored at location \(\texttt {k_loc}\) . This procedure defines a partial function of type \(\texttt {unit &#x2192; key}\) , that fails to return a value if the memory location has not yet been explicitly initialized (i.e., it is \(\bot\) ).We first retrieve the potentially not explicitly initialized key from memory as \(\texttt {k}\) , of type \(\texttt {option key}\) . We then check via a dependent assert that \(\texttt {k}\) is not \(\texttt {l}\) , and record the asserted condition as \(\texttt {kSome}\) of type \(\texttt {k &#x02260; l}\) . We can now apply getSome with \(\texttt {kSome}\) to safely coerce \(\texttt {k}\) from \(\texttt {option key}\) to \(\texttt {key}\) . In this example, the code that follows the assertion depends on the asserted condition, whereas in the previous example with \(\texttt {counter}\) the assertion was only used when reasoning in the relational program logic. Indeed the continuation of dependent assert, called \(\texttt {kont}\) in the declaration below, has type \(\texttt {b}\) = true → \(\texttt {code A}\) . In other words, it constitutes a piece of \(\texttt {code}\) , computing a value of type \(\texttt {A}\) , that is defined only when the assertion \(\texttt {b}\) is true. Operationally \(\texttt {assertD}\) is similar to the simple assert above, but the actual Coq definition in terms of \(\texttt {fail}\) and a conditional is more complicated, because it uses dependent elimination to type-check the success branch. Since such details are not important here, we refer the interested reader to the Coq source and only show the type of this operator:

Procedure calls. A call to an external procedure such as \(\texttt {Prf}\) in (3) is represented by the \(\texttt {call}\) operation, taking as arguments a procedure name \(\texttt {p}\) annotated with a type, a value matching the argument type of \(\texttt {p}\) , and a continuation \(&#x03BA;\) matching the return type of \(\texttt {p}\) . In Section 3.3, we show how an implementation gets substituted for this placeholder via sequential package composition.

Notation. The use of continuations is pervasive in monadic code, and to alleviate the presentation, we introduce the following more familiar notation:In code listings we will frequently omit the \(\texttt {;}\) separator when it would occur at the end of a line. We will also write \(\texttt {c_1 ; c_2}\) for \(\texttt {_ &#x2190; c_1 ; c_2}\) when the continuation \(\texttt {c_2}\) does not use its argument.

Correct typing. The typing constraints imposed by the \(\texttt {raw_code}\) definition enforce correct typing for user-written code, guaranteeing that operations and their continuations are compatible. For instance, let the continuation of \(\texttt {get}\) in (2) be \(\texttt {f}\) . Then, \(\texttt {f}\) is only compatible with \(&#x2113;\) if \(\texttt {f}\) ’s domain matches the type of \(&#x2113;\) , i.e., \(\texttt {f : type &#x2113; &#x02192; raw_code A}\) for some type \(\texttt {A}\) .

Syntax at work. We now illustrate our formal syntax in action. For this, we restate the procedure \(\mathtt {PRF^0.Eval(x)}\) from Figure 4 more formally using \(\texttt {raw_code}\) and the various notations above:

TWThis is not really equivalent is it? The bind should be some \(\texttt {;}\) and then do a \(\texttt {get}\) again on \(\texttt {k}\) to match the above.PGHswitched to a \(\texttt {get}\) as suggested (which is justified by \(\texttt {getSome}\) ). Also using an if-then-else instead of a match to more closely mirror the pseudo-code. Here, we mix constructors of \(\texttt {raw_code}\) with other Gallina terms such as the match construct. The result of the match is made available to the continuation of the code as \(\texttt {val_k}\) via a use of \(\texttt {bind}\) (under the guise of “ \(\texttt {val_k &#x2190; ... ; ...}\) ”).

When no external procedure calls ( \(\texttt {call o x k}\) ) appear in a piece of code \(\texttt {c : code A}\) , it is possible to interpret \(\texttt {c}\) as a state-transforming probability subdistribution of typeThis semantics is similar to that of CertiCrypt [26]. The type \(\texttt {SD A}\) denotes the collection of all subdistributions over type \(\texttt {A}\) . Generally speaking, a subdistribution is a function \(d: A &#x02192; \mathbb {R}\) assigning a certain probability \(d(a)\) to each \(a:A\) in such a way that \(\int _A d \le 1\) . We use the definition of subdistributions from mathcomp-analysis [4, 69], a Coq library from which we use the foundations it gives to discrete probability theory. The semantics function \(\texttt {Pr_code}\) is defined by recursion on the structure of \(\texttt {c}\) . Its definition basically boils down to providing an effect handler that interprets state and probabilities in the monad \(\texttt {mem &#x02192; SD(- x mem)}\) .

Using this subdistribution semantics, we can formalize the notation \(\mathrm{Pr}\![ b \leftarrow G ]\) from Section 2.1 as follows: (i) extract the \(\mathtt {Run}\) function from G; (ii) apply \(\texttt {Pr_code}\) to it; (iii) run it on the initial memory; (iv) extract the Boolean component (first projection) from the resulting subdistribution. The final result has type \(\texttt {d : SD bool}\) , the type of subdistributions for Booleans, and we precisely define \(\mathrm{Pr}\![ b \leftarrow G ] = \texttt {d}(b)\) as the probability assigned to b by this subdistribution on Booleans.

A raw package is a finite map from names to raw procedures, which are functions from some \(\texttt {A}\) to \(\texttt {raw_code B}\) . An interface is a finite set of operation signatures ( \(\texttt {opsig}\) ), each specifying the name, argument type, and result type of a procedure. A package is then a raw package \(\mathit {RP}\) together with an import interface \(\mathcal {I}\) , an export interface \(\mathcal {E}\) , and a set of locations \(\mathcal {L}\) , such that each procedure in \(\mathit {RP}\) uses only locations in \(\mathcal {L}\) and imports only from \(\mathcal {I}\) , and each procedure name listed in \(\mathcal {E}\) is implemented by a procedure in \(\mathit {RP}\) of the appropriate type. Consider for instance the package \(\mathtt {MOD-CPA}\) in Figure 13. The memory used, \({\mathtt {mem}({\mathtt {MOD-CPA}})}\) ,⁶ consists of two locations, pk : option pubKey and \(\texttt {counter : nat}\) . The import interface \({\mathtt {import}({\mathtt {MOD-CPA}})}\) contains a single procedure \(\texttt {Query : unit &#x02192;\) \(\mathtt {\mathcal {G}\times \mathcal {G}\times \mathcal {G}}\) . There are two procedures implemented by \(\mathtt {MOD-CPA}\) , yielding an export interface \({\mathtt {export}({\mathtt {MOD-CPA}})}\) containing and .

We define composition of packages, following the intuition of Brzuska et al. [40]. Given two raw packages P and Q, we define their sequential composition \(Q \circ P\) by traversing Q and replacing each \(\texttt {call}\) by the corresponding procedure implementation in P. In case P does not implement the procedure for which we search, we use a dummy value instead. If the exports of P match the imports of Q—i.e., \({\mathtt {import}({Q})} \subseteq {\mathtt {export}({P})}\) —then no dummy value will be used. Concretely, during the traversal each \(\texttt {call p a &#x03BA; }\) node is replaced bywhere \(\mathtt {link_P}\) stands for the recursive call of the function composing P with the remaining code. Experts will recognize this transformation as an algebraic effect handler [28], interpreting the free monad for probabilities, state and the operations imported by P to code in the free monad for probabilities, state, and the operations imported by Q. We have \({\mathtt {mem}({Q \circ P})} = {\mathtt {mem}({P})} \cup {\mathtt {mem}({Q})}\) , \({\mathtt {import}({Q \circ P})} = {\mathtt {import}({P})}\) and \({\mathtt {export}({Q \circ P})} = {\mathtt {export}({Q})}\) .

Given two raw packages P and Q, we may define their parallel composition \(P \parallel Q\) by aggregating the implementations and delegating calls to the respective package providing it. This operation is defined even if both packages have overlapping export signatures, in which case procedures in P will be given priority. If their exports are disjoint, i.e., \({\mathtt {export}({P})} \cap {\mathtt {export}({Q})} = \emptyset\) , then this overlap situation does not happen, and we have \({\mathtt {mem}({P \parallel Q})} = {\mathtt {mem}({P})} \cup {\mathtt {mem}({Q})}\) , \({\mathtt {import}({P \parallel Q})} = {\mathtt {import}({P})} \cup {\mathtt {import}({Q})}\) and \({\mathtt {export}({P \parallel Q})} = {\mathtt {export}({P})} \cup {\mathtt {export}({Q})}\) .

Private state. When formalizing composition in SSProve, we do not impose any a priori restrictions on the disjointness of the state that the composed packages manipulate. The essence of state separation can be thus viewed as disjointness of state between the adversary \(\mathcal {A}\) and the games in a pair \({G}^{01}\) . We therefore introduce the more economical assumption that only the adversary has to have disjoint state in our security definitions and corresponding theorem statements (e.g., Theorem 2.4). Formally, an adversary \(\mathcal {A}\) to game pair \({G}^{01}\) is thus a distinguisher for \({G}^{01}\) with the additional assumption that \({\mathtt {mem}({\mathcal {A}})}\) is disjoint from both \({\mathtt {mem}({{G}^{0}})}\) and \({\mathtt {mem}({{G}^{1}})}\) . This extra state assumption sets apart adversaries from distinguishers: We do not require that the state of a distinguisher be disjoint from the game pair it tries to distinguish, and we still proved Lemma 2.2 and Lemma 2.3 from Section 2.1. The difference between distinguishers and adversaries manifests, for instance, in the definition of perfect indistinguishability from the end of Section 2.1, which quantifies only over adversaries. Distinguishers that are not adversaries could otherwise directly access the game state and trivially distinguish the games we want to consider indistinguishable.

In the setting of SSProve, in which memory locations are global and not up to \(\alpha\) -renaming, this fine-grained state separation is helpful, since not only it minimizes the burden of formally proving disjointness, but it also reduces the clutter in the statement of the final results.

Automation of side conditions. In our Coq formalization, we provide automation for the checking of side conditions required to build packages and their compositions. This includes checking predicates such as \(\texttt {has_locs_and_imports}\) to ensure that the implementation of a package is consistent with the expected interface and memory footprint. There are limitations, however, to the scope of the automation; specifically checking disjointness of location sets is currently quite basic. We plan to improve this situation in future work.

We formally proved the algebraic laws obeyed by packages as stipulated by Brzuska et al. [40]. Sequential composition is associative and parallel composition is commutative and associative, so for any packages \(P_1, P_2, P_3\) :We furthermore relate the two package operations with an interchange law stating thatCommutativity of parallel composition only holds if the packages have indeed disjoint interfaces: \({\mathtt {export}({P_1})} \cap {\mathtt {export}({P_2})} = \emptyset\) . The interchange law will only ask this of \(P_3\) and \(P_4\) : \({\mathtt {export}({P_3})} \cap {\mathtt {export}({P_4})} = \emptyset\) .

The identity package \({\mathtt {ID}_{I}}\) behaves as an identity for sequential composition when using the correct interface:

As we have hinted before, these laws do not require disjointness of state, because they are syntactic equalities. In fact, in SSProve they hold with respect to the usual equality of Coq (“propositional equality,” written \(\texttt {_ = _}\) ), without the need to define a separate notion of “code equality” [40].

The logic we use is a variant of pRHL, a probabilistic relational Hoare logic introduced by Barthe et al. [26]. The logic exposes relational judgments of the formfor which a basic intuition is provided in Section 2.2. Formally, \(c_0\) and \(c_1\) denote probabilistic stateful code with return type \(A_0\) and \(A_1\) , respectively, and the precondition \(m_0 : \mathsf {mem}, m_1 : \mathsf {mem}\vdash \phi : \mathbb {P}\) is a proposition with free variables \(m_0\) and \(m_1\) denoting the initial state of the memory (before execution of the code). The postcondition \(m_0^{\prime } : \mathsf {mem}, a_0 : A_0, m_1^{\prime } : \mathsf {mem}, a_1 : A_1 \vdash \psi : \mathbb {P}\) is a predicate on the values returned by the executed code, which is parameterized by the variables \(m_0^{\prime }\) and \(m_1^{\prime }\) representing the final state of the memory (after execution) and by the final values \(a_0\) and \(a_1\) . As mentioned before, we will sometimes omit the quantifications when they are clear from the context. We will also abuse notation and sometimes write, e.g., \(\psi (m_0^{\prime },a_0) (m_1^{\prime },a_1)\) for the substitution of \(\psi\) with the given memories and values. The code fragments appearing in a judgment are drawn from the free monad \(\texttt {code}\) \(_{\mathcal {L} , I}\) of Section 3.1, and meet the further requirement that no oracle calls \(\texttt {call o x k}\) appear in them (exactly as in Section 3.2). The precondition \(\phi\) is defined to be a relation between initial memories (for instance, \(m_0 = m_1\) ). Similarly the postcondition \(\psi\) relates final memories and final results, intuitively obtained after the execution of \(c_i\) on \(m_i\) . We describe how to assign a formal semantics for such probabilistic judgments in Section 5.2. The semantics is based on the notion of probabilistic couplings, already adopted by Barthe et al. [22]. In the remainder of this subsection, we describe a selection of our rules. The presentation does not contain all the rules employed in practice by SSProve, nor does it provide a canonical presentation of these rules: some rules are overlapping hence there are multiple ways to prove the same relational judgment, but the actual derivation might be simpler with this redundancy. We return to the question of the organization of rules after this presentation:The \(\texttt {reflexivity}\) rule relates the code c to itself when both copies are executed on identical initial memories.The \(\texttt {seq}\) rule relates two sequentially composed commands using \(\texttt {bind}\) by relating each of the sub-commands.The \(\texttt {swap}\) rule states that if a certain relation on memories I is invariant with respect to the execution of \(c_0\) and \(c_1\) , then the order in which the commands are executed is not relevant. We used the \(\texttt {swap}\) rule in Section 2.3 to swap two independent samplings; in that case the invariant I consisted in the equality of memories.The eqDistrL rule allows us to replace \(c_0\) by \(c_0^{\prime }\) when both codes have the same denotational semantics as defined by \(\mathtt {Pr_code}\) , in the sense of Section 3.2.The symmetry rule simply states that the symmetric judgment holds if the arguments of the pre- and postconditions are swapped accordingly.The for-loop rule relates two executions of for-loops with the same number of iterations by maintaining a relational invariant through each step of the iteration.The do-while rule relates two bounded while loops with bodies \(c_0\) and \(c_1\) . Every iteration preserves a relational invariant on memories I that depends on a pair of Booleans, and the postcondition also stipulates that \(c_0\) and \(c_1\) return the same Boolean, i.e., \(b_0 = b_1\) . This rule follows the pattern of the unbounded do-while rule defined for simple imperative programs by Maillard et al. [70]. We believe that, with some additional work, their ideas could be used to also support unbounded loops in SSProve (see Section 5.5 for details).The uniform rule relates sampling from uniform distributions on finite sets A and B that are in a bijective correspondence. Note how it applies the bijection f in the continuation on the right-hand side:The code \(y \mathbin {\mathtt {\lt \$}}D \: ;\:\,c_0\) samples y from the subdistribution D. If y is never used in \(c_0\) , as indicated by the last premise of the dead-sample rule, then we would like to argue that the sampling constitutes “dead code” and can be ignored. This intuition only holds if D is a proper distribution rather than a subdistribution. For instance, if D is the null distribution, the sampling behaves like “ \(\texttt {assert false}\) ” and can certainly not be ignored. The premise \(\sum _{x \in |D|} D(x) = 1\) ensures that D is indeed a proper distribution (also known as a “lossless subdistribution”). A uniform distribution over a non-empty set would, for instance, constitute a proper distribution in this sense:The sample-irrelevant rule has a similar flavor to dead-sample, as it too requires D to be a proper distribution. We assume that \(c_0\ y\) can be related to \(c_1\) for all values of y. In other words, the choice of a particular value for y is irrelevant for the pre- and postcondition at hand. Therefore, sampling y from a proper distribution D will likewise allow us to conclude that \(c_0\ y\) is related to \(c_1\) :The assert rule relates two assert commands, as long as “ \(b_0 = b_1\) ” holds before the commands. Note that while the precondition is a predicate on initial memories, nothing prevents it form talking about other things such as the Booleans \(b_0\) and \(b_1\) quantified at the meta-level. It guarantees “ \(b_0 = \mathtt {true}\wedge b_1 = \mathtt {true}\) ” afterwards, ignoring the values \(a_0\) and \(a_1\) of type \(\texttt {unit}\) :The one-sided assertL rule specifies the behavior an assert with a true Boolean, by relating it with return (). Note that if a code fragment \(c_0\) is shown to be related to an assertion failure , then \(c_0\) must necessarily contain an assertion failure as well, i.e., correspond to the null sub-distribution. Indeed the (sound) model of our program logic, explained in Section 5, gives rise to a total correctness semantics [70] for assertion failures: assertion failures only relate to other assertion failures:The assertD rule allows reasoning about the dependent version of assert where the continuation \(&#x03BA; _i\) is only well-defined if the assertion holds, as described in Section 3.1. As in the assert rule, the two assertion conditions \(b_0\) and \(b_1\) may a priori be different. The precondition \(\phi\) has to ensure that \(b_0\) and \(b_1\) are either both true or both false. The continuations \(&#x03BA; _i\) are defined only in case the assertions succeed. Under this assumption, here represented as the hypotheses \(H_0\) and \(H_1\) , the continuations \(&#x03BA; _i\) must be related for the same pre and post as the composite statements “ \({\texttt {assert } b_i \texttt { as } h_i} \: ;\:\,&#x03BA; _i\ h_i\) ”. The intuition for the validity of this rule is the following: if \(b_i\) is true, \({\texttt {assert } b_i \texttt { as } h_i}\) is defined as \(&#x03BA; _i \ h_i\) , and we appeal to the last premise. If \(b_i\) is false, then both composite statements \(\texttt {fail}\) and evaluate to the null distribution:The put-get rule states that looking up the value at location \(&#x2113;\) after storing v at \(&#x2113;\) results in the value v. We also have a similar rule to remove a put right before another one at the same location, and one for two get in a row. More interestingly, we provide one-sided rules for get and put, which update the pre- or postcondition accordingly:

With get-lhs, the left-hand side program is able to read from a memory location while we record that information in the precondition. Dually, get-lhs-rem will recover that information from the precondition. We also use the information in the preconditions when dealing with memory invariants such as the one presented in Section A for the security proof of KEM-DEM.

The situation is slightly more complicated for one-sided writes, because writing might break a postcondition. Typically, writing on only one side when the postcondition ensures that both memory locations are equal would (maybe temporarily) break said postcondition:

Instead, put-lhs modifies the precondition to state that the precondition \(\phi\) was satisfied by a previous memory state, and that the current memory state is the same except that \(&#x2113;\) now points to v. Typically, when \(\phi\) is an invariant—such as one stating the equality of the two memories—we relax the precondition temporarily until we reach a new state where it holds again, for instance by having a similar write on the right-hand side. Rule restore-pre-lhs is such an example—although much simplified—of how one can recover the precondition after a write, provided they can prove that the precondition holds after the corresponding update of memory. In SSProve, we, in fact, implement a more general rule accounting for any number of writes on both the left- and right-hand sides. Several put operations are performed, until one can show that the invariant is preserved by all these memory updates.

More generally, we define handy tactics to apply these rules immediately, as well as performing the necessary massaging of goals so that they become applicable. As such, we have automation for swapping multiple lines at once and checking that the swap was legal. Moreover, these tactics rely on the hints mechanism of Coq and can thus be extended by the user.

Organization of the relational program logics rules. The rules of the relational program logic are not canonically derived but a few guidelines have been used to come up with them. These guidelines follow three independent criteria: the algebraic criterion, the historical criterion, and the practical criterion. The algebraic criterion follows the idea that the effects employed in the programming language can be modeled using algebraic structures, e.g., monads, and rules corresponding to the standard combinators of this algebraic presentation can be naturally expressed [70]. In particular, equationally presented monads such as the state monad, the exception monad or the Giry probability monad [58, 80] naturally induce reasoning rules corresponding to their equational theory [57]. The algebraic approach, however, falls short of providing a complete solution accounting for the distinction between one-sided and two-sided rules specific to a particular effect—e.g., rules for get and set when considering the state monad. For these rules, the historical presentation follows earlier work on (x)pRHL [22, 26], providing both one-sided and two-sided rules. Finally, the pragmatics of proving relational properties of programs in SSProve pushed for specific presentations of the rules, well tailored to streamlined applications in practice, in particular, when considering the specifics of the Coq hosting environment, such as tactic language and incremental proof derivation through interactive use of existential variables and subgoals generation. The redundancy between rules created by these different approaches to relational program logic rules’ design is not an issue in practice, since each of these rules is proved against the semantic model presented in Section 5 rather than assumed axiomatically. The question of completeness of the rules is somehow side-stepped in our setting by having an escape hatch using the relational semantics: in any case, if the rules we provide are not suitable to prove a particular judgment, one can always fall back to the underlying semantic model and prove an additional valid rule at that level. Ultimately, we validate the design of the rules present in SSProve via case studies, ensuring that the chosen set of rules are indeed enough to obtain concrete interesting results.

If we denote by \(\mathsf {mem}\) the type of memories, then a binary memory predicateholds on a pair of memories \((h_0, h_1)\) , written \((h_0, h_1) \vDash \psi\) , when \(\psi (h_0,h_1)\) holds. Moreover, we say that such predicate is stable on sets of locations \(\mathcal {L}_0\) and \(\mathcal {L}_1\) when for all \(h_0, h_1\) such that \((h_0, h_1) \vDash \psi\) , we have for all memory locations l, such that \(l \not\in \mathcal {L}_0\) and \(l \not\in \mathcal {L}_1\) , that

In other words, on locations outside of \(\mathcal {L}_0\) and \(\mathcal {L}_1\) , \(\psi\) must ensure equality of corresponding values and nothing else.

When we want to prove that two packages with the same interface are perfectly indistinguishable, we will assume that we have a stable predicate on the locations of the packages, and moreover, that this predicate is an invariant on the different operations of the interface. This invariance of the predicate is the reason why \(\psi\) appears both as a pre- and postcondition in Theorem 2.4. Notice that stable predicates do not impose conditions on the intermediate states of each procedure in the interface of Theorem 2.4, e.g., two related procedures may differ in their internal order of updates, as long as the final results of computations are related.

Before giving the proof sketch for Theorem 2.4, we state a theorem that is also proved in Coq and relates the probabilistic relational program logic with the probabilistic semantics.

We are now ready to outline the proof for Theorem 2.4.

The aforementioned framework builds upon a monadic representation of effects to provide sound semantics to a large class of relational program logics. As we shall see, this class notably contains logics for reasoning about cryptographic code: code that can manipulate state and sample randomly (see Section 4.1). A generic relational program logic \(r\mathcal {L}\) is a deductive system with a relational judgment \(\vDash _{} c_0 \sim c_1 \, &#x0007B; \:w\:&#x0007D;\) asserting that pairs of effectful code fragments \(c_0,c_1\) behave according to a given relational specification w connecting the two computations. The exact shape of code and specifications appearing in such a judgment can vary depending on what programming language and logic are considered.

The recipe laid out by Maillard et al. [70] stems from the realization that not only effectful code can be modelled using monads, but specifications can too, and we can build semantics for \(r\mathcal {L}\) using a so-called relational effect observation in three steps:

Once a relational effect observation \(\theta\) is specified, we define a semantic judgment for \(r\mathcal {L}\) as follows:where \(c_i:M_i\,A_i\) and \(w:W(A_0,A_1)\) .

A typical example of a relational specification monad is the relational backward predicate transformer monad \(\mathrm{BP}(A_0,A_1) := (A_0\times A_1{&#x02192; }\mathbb {P})&#x02192; \mathbb {P}\) , where \(\mathbb {P}\) is the type of propositions. Intuitively a backward predicate transformer \(w:\mathrm{BP}(A_0,A_1)\) maps a relational postcondition \(\phi\) to a precondition \(w\, \phi\) sufficient to ensure \(\phi\) on the result of the executions of code fragments \(c_0,c_1\) respecting w (i.e., for which \(\vDash _{\theta } c_0 \sim c_1 \, &#x0007B; \:w\:&#x0007D;\) for some \(\theta\) ). The preorder on \(\mathrm{BP}(A_0,A_1)\) is given by reverse pointwise implication. For two backward predicate transformers \(w_1, w_2 : \mathrm{BP}(A_0,A_1)\) , we say that \(w_1 \le w_2\) when \(\forall \phi .\ w_2 \, \phi \Rightarrow w_1 \, \phi\) . Every pre-/postcondition pair \((pre, post)\) can systematically be translated into a single backward predicate transformer \(\mathrm{toBP}(pre,post)\) :Note that \(\mathrm{BP}\) does not form a monad: it takes two types \(A_0,A_1\) as input but only returns one \((A_0\times A_1{&#x02192; }\mathbb {P})&#x02192; \mathbb {P}\) . Yet \(\mathrm{BP}\) somehow still behaves as a monad, because we can equip it with \(\texttt {bind}\) and \(\texttt {return}\) operations satisfying equations akin to the standard monad laws. This is one of the reasons why our precise definitions of relational specification monad and relational effect observation are centered around the notion of relative monad instead, as discussed in Reference [70] and explained here in Section 5.4.

The technique above can be exploited to build a model for a probabilistic relational program logic. We model probabilistic code using a free monad \(\mathrm{F}_\mathit {Pr}\) over a probabilistic signature, reusing \(\texttt {code}\) \(_{\mathcal {L} , I}\) mentioned in Section 3.1, where we require that only sampling operations are performed. This code can be assigned a probabilistic semantics using the monad of subdistributions [13, 58], following the track of Section 3.2, but ignoring considerations around state. This semantics assignment can, in fact, be seen as a monad morphism \(\delta : \mathrm{F}_\mathit {Pr}&#x02192; \mathrm{SD}\) .

Specifications and effect observation. To model specifications for probabilistic code, we use the relational specification monad \(\mathrm{BP}\) of backward predicate transformers, defined above. The relational effect observation \(\theta _\mathit {Pr}\) is based on the notion of probabilistic coupling. A coupling \({d} : {\texttt {coupling}(d_0, d_1)}\) of two subdistributions \(d_0:\mathrm{SD}(A_0)\) and \(d_1:\mathrm{SD}(A_1)\) is a subdistribution over \(A_0 \times A_1\) such that its left and right marginals correspond to \(d_0\) and \(d_1\) , respectively. For \(d_i : \mathrm{SD}(A_i)\) two subdistributions, we define \(\theta _\mathit {Pr}^{\prime } : \mathrm{SD}\times \mathrm{SD}&#x02192; \mathrm{BP}\) byWe moreover turn the domain of \(\theta _\mathit {Pr}^{\prime }\) into a product of free monads by settingIntuitively, if \(w : BP(A_0 ,A_1)\) is obtained out of a \((pre,post)\) pair, then the semantic judgment \(\vDash _{\theta _{Pr}} c_0 \sim c_1 \, &#x0007B; \:w\:&#x0007D;\) holds when one can find a coupling d of \(\delta (c_0),\delta (c_1)\) whose support validates post whenever pre is valid.

Our probabilistic model \(\vDash _{\theta _{Pr}} c_0 \sim c_1 \, &#x0007B; \:w\:&#x0007D;\) validates state-free accounts of several rules of Section 4.1. First, since the subdistribution monad is commutative (sampling operations always commute), our semantics validates a state-free variant of the swap rule. Second, as it is often the case for an arbitrary effect observation, symmetric rules like uniform involving similar effectful operations on both sides (here: \(a \mathbin {\mathtt {\lt \$}}~\mathtt {uniform}\ A\) ) are validated as well. Third, failing assertions at type A can be modelled using the null subdistribution on A, and this interpretation allows us to validate the assert rule in our model. Fourth, a state-free variant of the reflexivity rule can be established by building, for any subdistribution s, a coupling \({d} : {\texttt {coupling}(s, s)}\) of s with itself. Fifth, any relational effect observation \(\theta\) validates a rule like seq. Such a rule is essentially a syntactic formulation of the fact that \(\theta\) should preserve the monadic composition, which is true by definition.

The implementation of the relational effect observation \(\theta _\mathit {Pr}\) in Coq depends on a mathematical theory of couplings and of their interaction with probabilistic programs that we developed. This theory relies internally upon the mathcomp-analysis library [3, 4], particularly on their formalization of real numbers, subdistributions and discrete integrals.

To extend this first model to stateful code and state-aware specifications, we adapt to our setting the classical notion of state monad transformer [65]. A monad transformer maps monads M to monads \(\mathrm{T}\,M\) and monad morphisms \(\theta\) to monad morphisms \(\mathrm{T}\,\theta\) . In particular, the state monad transformer takes as input a monad M and a fixed set of states S and produces a monad with underlying carrier \(\mathrm{StT}\,M(A) = S &#x02192; M (A \times S)\) with additional ability to read and write elements of S. Besides, a monad transformer comes equipped with a family of liftings \(\texttt {lift}^{\mathrm{T}} : \forall M.\ M &#x02192; \mathrm{T}\,M\) coercing any computation in the original monad M to a computation in the extended effectful environment \(\mathrm{T}\,M\) . We generalize this to specification monads and build modularly an effect observation \(\theta _\mathit {Pr,St}\) on top of \(\theta _\mathit {Pr}\) :using two sets of global states \(S_0,S_1\) for the left and right, whereFollowing the definition of \(\theta _\mathit {Pr}\) in Section 5.2, we further extend \(\theta _\mathit {Pr,St}^{\prime }\) by turning its domain into a product of free monads \(\mathrm{F}_\mathit {Pr,St}^2 := \mathrm{F}_\mathit {Pr,St}\times \mathrm{F}_\mathit {Pr,St}\) over a stateful and probabilistic signature. This extension is obtained from \(\theta _\mathit {Pr,St}^{\prime }\) by precomposition with the mapping mentioned in Section 3.2:

Using the liftings \(\texttt {lift}^{\mathrm{StT}}\) provided by \(\mathrm{StT}\) , we can build from any purely probabilistic relational judgment \(\vDash _{\theta _\mathit {Pr}} c_0 \sim c_1 \, &#x0007B; \:w\:&#x0007D;\) a relational judgment \(\vDash _{\theta _\mathit {Pr,St}} c_0 \sim c_1 \, &#x0007B; \:\texttt {lift}^\mathrm{StT}\,w\:&#x0007D;\) in the state-aware model. This correspondence can be shown to form an embedding of logics: for every \(c_0, c_1, w\) free from state manipulation, derivations of \(\vDash _{\theta _\mathit {Pr,St}} c_0 \sim c_1 \, &#x0007B; \:\texttt {lift}^\mathrm{StT}\,w\:&#x0007D;\) are in bijective correspondence with derivations of \(\vDash _{\theta _\mathit {Pr}} c_0 \sim c_1 \, &#x0007B; \:w\:&#x0007D;\) . The proof of this latter fact is simplified by the modularity of the construction. This modularity is moreover reflected in the way \(\theta _\mathit {Pr,St}(c_0,c_1)\) evaluates. A first pass converts stateful operations of \(c_0,c_1\) and yields state-passing probabilistic code. A second pass interprets the remaining sampling operations and yields state-transforming subdistributions. Last, a third pass uses \(\theta _{Pr}\) and yields the expected specification \({\theta _\mathit {Pr,St}(c_0,c_1): \mathrm{StT}(\mathrm{BP})(A_0,A_1)}\) . The semantic judgment \(\vDash _{\theta _\mathit {Pr,St}} c_0 \sim c_1 \, &#x0007B; \:w\:&#x0007D;\) obtained out of \(\theta _\mathit {Pr,St}\) validates all of the rules of our relational program logic (including Section 4.1).

Our semantics relies on the notion of relational effect observation (Section 5.1), and on our ability to apply a suitable state transformer to them (Section 5.3). In this section, we provide categorical definitions for those notions. Our Coq formalization of the semantics is essentially a formal version of the theory laid out here. Note that Coq types and functions between them form a category that we call \(\mathrm{Type}\) . We will also use the category \(\mathrm{PreOrder}\) of types equipped with a preorder structure (reflexive, transitive relation), and monotone functions.

Computations and specifications as order-enriched relative monads. We are interested in modelling probabilistic programs using monads. Yet, in our constructive setting probabilistic computations fail to form a monad. Indeed, our Coq formalization relies on the mathcomp-analysis library, which defines the type of subdistributions \(\mathrm{SD}(A)\) (see Section 3.2) only when A is a “choiceType,” that is, a type equipped with an enumeration function for each of its decidable subtypes. This extra choice structure is crucial to define a well-behaved notion of discrete integral on A, and consequently of subdistribution on A. KMThis is a bit mysterious, could we give a simple explanation of the operation a choice type support (I think it allows to extract an enumeration out a type, no ?)AVMchanged a bit Beyond the discrepancy between the domain and codomain of \(\mathrm{SD}\) , it is still possible to endow it with slightly modified versions of the expected \(\texttt {bind}\) and \(\texttt {return}\) operations, that satisfy laws comparable to the standard monad laws. Fortunately, Altenkirch et al. [10] explain well how these superficial obstructions due to a mismatch between the domain and codomain of a monad-like structure can be solved using the closely related notion of a relative monad instead.

As a trivial example, any monad \(M : \mathcal {C}&#x02192; \mathcal {C}\) can be seen as a relative monad over the identity functor \(\mathrm{Id}_{\mathcal {C}}\) . Writing \(\mathrm{chTy}\) for the category of choice types (choiceType), we are able to package \(\mathrm{SD}: \mathrm{chTy}&#x02192; \mathrm{Type}\) as a monad relative to the inclusion functor \(\mathrm{chTy}&#x02192; \mathrm{Type}\) forgetting the extra choice structure. Similarly the probabilistic code monad \(\mathrm{F}_\mathit {Pr}\) must actually be restricted to \(\mathrm{chTy}\) and only forms a relative monad \(\mathrm{F}_\mathit {Pr}: \mathrm{chTy}&#x02192; \mathrm{Type}\) over the inclusion functor.

Regarding specifications, relational specification monads W fail to form monads as well. Indeed, \(W : \mathrm{Type}\times \mathrm{Type}&#x02192; \mathrm{PreOrder}\) expects two types \(A_0,A_1\) as input but only returns one \(W(A_0,A_1)\) , which is moreover pre-ordered. Again, it turns out that relational specification monads W (including \(\mathrm{BP}\) ) can be seen as relative monads, over the discrete product functor \(\mathrm{dprod}\) mapping two types to their product seen as a trivial preorder:Specializing the definition of a relative monad with \(J=\mathrm{dprod}\) , the \(\texttt {bind}\) and \(\texttt {return}\) operations of W take the following form:To soundly model relational program logics, the \(\texttt {bind}^{\mathrm{W}}\) operation of the relational specification monad being used should be monotonic in both arguments. In our setting, we can, in fact, easily express that condition by requiring all categorical constructions to be order-enriched [62, 63, 82]. For the sake of readability, we ignore the trivial considerations arising from this enrichment and consider that all the constructions we are dealing with are implicitly order-enriched.

Summing up, in our setting:

For instance, the domain and codomain of the relational effect observation \(\theta _\mathit {Pr}\) defined in Section 5.2 form, respectively, a product of \(\mathrm{Type}\) -valued relative monads, and a relational specification monad:

Relational effect observations. Consider \(M_0, M_1\) two \(\mathrm{Type}\) -valued relative monads with base functors \(J_0, J_1\) , respectively. Let W be a relational specification monad. The relative monads \(M_0\times M_1\) and W organize in the following configuration:

A relational effect observation \(\theta : M_0 \times M_1 &#x02192; W\) is a collection of mappingspreserving the \(\texttt {bind}\) and \(\texttt {return}\) operations of \(M_0, M_1\) up to inequalitiesAn instance of relational effect observation is of course given by \(\theta _\mathit {Pr}\) . Note that \(\theta _\mathit {Pr}\) validates those inequalities but fails to validate them as equalities.

In our development, relational effect observations \(\theta : M_0 \times M_1 &#x02192; W\) are defined as special cases of lax morphisms between order-enriched relative monads. We refer the interested reader to our formalization⁷ for a precise definition of this notion. In the remainder of this section, we explain how to extend relative monads and lax morphisms between them with state. In particular, this extension will apply to relational effect observations such as \(\theta _\mathit {Pr}\) .

Transforming a relative monad with an appropriate left adjunction. It is a standard result that every adjunction induces a monad and that every monad is induced by a family of adjunctions (see Reference [68], chapter 6). A similar kind of correspondence holds between left J-relative adjunctions on one side, and J-relative monads on the other. The two following definitions appear in Reference [10].

In this work, we introduce the following notion.

If \(\mathcal {I}\) is cartesian, \(\mathcal {C}\) is cartesian closed, and J preserves cartesian products, then the following configuration gives rise to a transforming adjunction \(\sigma \, : \, J\circ ({-}\times S) {\,\,}_J\!\dashv S&#x02192; {-}\) , which we suggestively call “state-transforming adjunction.” Note that the J-relative monad induced by this adjunction \(X \mapsto S &#x02192; J(X \times S)\) is a J-shifted version of a standard state monad:

Adding state to a J-relative monad M consists in applying the above theorem with the state-transforming adjunction \(\sigma\) defined above to obtain \(\mathrm{StT}\, M := T_\sigma \, M\) . In particular, this is how the domain and codomain of \(\mathrm{StT}(\theta _\mathit {Pr})\) from Section 5.3 are defined.

Transforming lax morphisms. To transform lax morphisms of relative monads (such as \(\theta _\mathit {Pr}\) ) we follow the same methodology as in the previous paragraph. Various non-standard categorical notions are at play under the hood: lax morphisms of left relative adjunctions, lax functors, and lax natural transformations. Informally, let \(\theta : M &#x02192; W\) be a lax morphism of relative monads. Let \(\alpha\) be a transforming adjunction for both M and W. Then \(\theta\) induces a lax morphism between the Kleisli adjunctions of its domain and codomain: \(\mathrm{Kl}(\theta)\) can then be pasted with an appropriate cell to obtain a lax morphism between the transformed adjunctions, which ultimately induces a morphism \(\mathrm{T}_\alpha \, \theta : \mathrm{T}_\alpha \, M &#x02192; \mathrm{T}_\alpha \, W\) between the transformed relative monads. Adding state to a relational effect observation \(\theta\) now consists in applying the above with the state-transforming adjunction \(\sigma\) . This is how we can obtain \(\mathrm{StT}(\theta _\mathit {Pr}) := \mathrm{T}_\sigma \, \theta _\mathit {Pr}\) in a modular way.

We use the semantic framework of Maillard et al. [70] based on effect observations to obtain a formal and foundational approach to relational program logics for cryptographic code. In this section, we compare this methodology to other approaches for modelling relational program logics.

The Foundational Cryptography Framework (FCF) [78] develops machine-checked proofs of cryptographic code in the Coq proof assistant. Computations are modelled as elements of a free monad, then interpreted as distributions. This denotational model is subsequently used to derive a program logics using couplings. The approach we take is similar, but we paid special attention to the intermediate monadic structures involved. For instance, FCF distinguishes the type of simple computations \(\texttt {Comp}\,R\) with result value in R from the type of computations with access to some oracle \(\texttt {OracleComp}\,I\,O\,R\) . The latter provides operations to query an oracle with a given value in I and obtain results in O of an oracle call that are not found in simple computations. We rely on the genericity of free monads at the level of packages to encode both the simple computations and computations with oracles in a single uniform type of code, using the parameterized operations to provide oracle queries for instance. State passing is done explicitly in FCF, while we prefer a more abstract presentation using a state monad transformer. As a result, we obtain a conceptually comfortable decomposition of our computational monads and specifications, at the price of additional work to define the few components that we need for verification of cryptographic code.

Although the implementation of EasyCrypt does not have a proper foundational backend per se, many rules of its probabilistic relational Hoare logic (pRHL) were proved sound in Coq in a project called XHL with respect to a model [94], parts of which have been merged into mathcomp-analysis [4]. Our own development relies on these very same definitions and lemmas for the probabilistic aspect of the relational specification monads and the underlying theory of couplings. Our contribution here, forced by the organization of the framework of Maillard et al. [70], is to show formally that the various lemmas proved in the library indeed build instances of the monadic abstractions that are not explicated in the original development. Amongst the technical difficulties that appeared in that operation, we should mention the fact that distributions are only built-in mathcomp-analysis for types equipped with a certain choice structure, reflecting the constructive nature of Coq. However, we cannot endow distributions with such a choice structure, and in particular, distributions do not form monads, but they do form relative monads over the functor forgetting the choice structure (see Section 5.4). Note that although the definition of the semantic judgment \({\vDash _{\theta _\mathit {Pr,St}} c_0 \sim c_1 \, &#x0007B; \:w\:&#x0007D; }\) can seem abstract at first, it ultimately reduces to a direct formulation equivalent to the one underlying XHL.

CertiCrypt is a predecessor of EasyCrypt embedded directly in Coq and our foundational approach is closer in spirit to CertiCrypt than to its successor. CertiCrypt’s Coq code employs an elaborate definition of probabilistic Relational Hoare Logic judgments in terms of approximate couplings, based on the ALEA library [13, 77], which directly offers support for bounding the distance between the distributions of two probabilistic programs. It also features a memory model distinguishing between local and global variables, providing the ability to give a direct semantics for first-order procedure calls with local state in the form of “stack frames.” This memory model could be employed easily in our account of the state relative monad transformer.

CertiCrypt, EasyCrypt, and FCF provide some support for unbounded while loops, ultimately relying at the semantic level on the fact that distributions take values in a complete lattice, namely, the real numbers, and using standard fixpoint theorems to obtain an interpretation of arbitrary loops. Our semantic account could also support such an extension, as witnessed by the semantics Maillard et al. [70] construct for a simple Imp language with unbounded loops.

While a direct ad hoc definition of the model is comparatively simpler to implement, our categorical approach aims to provide more modularity, with the potential to account for multiple effects. This modular approach makes explicit that the model can be restricted to one validating a solely probabilistic program logic (Section 5.2). Moreover, it should be possible to extend our stateful model with other effects using a similar range of algebraic techniques. However, as things stand now, incorporating new effects in our relational program logic and its associated semantics can only be done on a case by case basis. Developing and using the framework required a high proof effort, in particular to manipulate the various layers of abstractions when proving concrete statements, such as the soundness of rules of the relational program logics specific to the effects involved. Further engineering work would be needed to make efficient use of the factorisation provided by abstraction and bring this approach to a competitive level compared to the simpler direct approach of FCF [78] and XHL [94].

The KEM-DEM protocol involves the use of a symmetric key to encrypt the actual data that is going to be sent. The \(\mathtt {KEY}\) package is used for generating, storing and accessing such a key.

All our statements, as well as the \(\mathtt {KEY}\) package itself, are parameterized over a type of symmetric keys and distribution keyD for generating them. In this respect, we generalize [40], which uniformly samples over bit-strings of a given length. We give the \(\mathtt {KEY}\) package in Figure 14.

Next, we consider packages that may rely on \(\mathtt {KEY}\) either for storage/generation or for access of an otherwise set key; we will later see the KEM and DEM as instances of those. We call the former keying and the latter keyed games. More formally, a keying game \({\mathtt {K}}^{b}\) is given by a core keying game \({\mathtt {CK}}^{b}\) with \({\mathtt {import}({{\mathtt {CK}}^{0}})} = &#x0007B; \mathtt {Set}&#x0007D;\) , and \({\mathtt {import}({{\mathtt {CK}}^{1}})} = &#x0007B; \mathtt {Gen}&#x0007D;\) , and \(\mathtt {Get}\not\in {\mathtt {export}({{\mathtt {CK}}^{b}})}\) , while a keyed game \({D}^{b}\) is given by a core keyed game \({\mathtt {CD}}^{b}\) such that \({\mathtt {import}({{\mathtt {CD}}^{b}})} = &#x0007B; \mathtt {Get}&#x0007D;\) , and \(\mathtt {Gen}\not\in {\mathtt {export}({{\mathtt {CD}}^{b}})}\) . They are graphically represented in Figure 15 (where we write \(\mathtt {Gen}/ \mathtt {Set}\) to indicate that the import is either \(\mathtt {Gen}\) or \(\mathtt {Set}\) depending on the secret bit b) and defined as follows:The import and export interface conditions stated above ensure that these packages are meaningful.

As we will see, we will define the \(\mathtt {KEM}\) package as a core keying game, and the \(\mathtt {DEM}\) package as a core keyed game. From that fact alone, we will be able to derive security bounds on games that combine them as evidenced by the following lemma.

To be as general as possible, we will assume we are given KEM and DEM schemes. As stated earlier, the KEM will generate a symmetric key and encrypt it using an asymmetric scheme. The DEM will then use that symmetric key to encrypt the data to be sent. To that effect, we assume we are given a public and secret key spaces pkey and skey, together with a relation pkey_pair to tell which secret key correspond to which public key. We furthermore assume a symmetric key space key and an encrypted symmetric key space ekey together with distributions keyD and ekeyD on them.⁸ Finally, we also assume that we have a type of ciphers and a type of plaintexts together with a distinguished null plaintext (which we will write as \(\mathtt {0}\) ), as well as a distribution on ciphers cipherD. In the original SSP paper [40], these distributions are uniform distributions and these types are described using bit-strings, but we decided for a more abstract approach, not only because it is slightly more general but also because things appear simpler, as we do not have to deal with low-level concerns.

A KEM, \(\eta\) , is given by the following:

We additionally require that with an appropriate secret key, the original symmetric key can be recovered by applying \(\eta .\mathsf {decap}\) to the encrypted key returned by \(\eta .\mathsf {encap}\) . This specification, and the specification of \(\eta .\mathsf {kgen}\) are handled in our formalization using the diagonal of our probabilistic relational program logic, i.e., we ensure that property \(\varphi\) holds of c by verifying that the judgment holds.

A DEM, \(\theta\) , is given by the following:

Note that we do not need to know that \(\theta .\mathsf {dec}\) and \(\theta .\mathsf {enc}\) are inverses of each other to conduct the security proof, so we do not require it. Of course, the DEM schemes of interest will verify this property as well.

For the remainder of this section, we assume that we are given a KEM \(\eta\) and a DEM \(\theta\) . Using them, we define the \({\mathtt {KEM}}^{b}\) and \({\mathtt {DEM}}^{b}\) games in Figure 18.¹⁰ These games are then used, respectively, as core keying and keyed games in the \({\mathtt {KEM-CCA}}^{01}\) and \({\mathtt {DEM-CCA}}^{01}\) game pairs (represented in Figure 19):

We finally combine \(\eta\) and \(\theta\) to form a public-key encryption (PKE) in the form the \({\mathtt {PKE-CCA}}^{01}\) game pair defined in Figures 20 and 22.

To state our PKE security theorem, we also define in Figures 21 and 23 the \(\mathtt {MOD-CCA}\) package, which has the same exports as \({\mathtt {PKE-CCA}}^{ 01}\) , but which will eventually be composed sequentially with \(\mathtt {KEM}\) , \(\mathtt {DEM}\) and \(\mathtt {KEY}\) to form an auxiliary game, featured in Figure 24 and defined asThe security theorem that we formalize is then the following:

Note here that unfortunately, one detail of the proof leaks into the theorem statement: the adversary is also forbidden from using the state of the intermediary game pair \({\mathtt {AUX}}^{01}\) . Concretely, that means an adversary is not allowed to use \(\texttt {k_loc}\) in addition to the locations of \({\mathtt {PKE-CCA}}^{01}\) .

\(\Sigma\) -protocols have been formalized before. Butler et al. [42] formalize a number of \(\Sigma\) -protocols in CryptHOL, and prove compositional properties of these protocols. Sidorenco et al. [90] formalize \(\Sigma\) -protocols in EasyCrypt, and combine them with a formalization of multi-party computation (MPC) to formalize a, so-called, MPC-in-the-head protocol.

For our representation of \(\Sigma\) -protocols, we build on both these formalizations to define the \(\mathtt {SIGMA}\) scheme and its corresponding security properties.

Additionally, we assume uniform distributions, challengeD and witnessD, for sampling challenges and witnesses of the relation, respectively.

Security is defined as several games interacting utilizing the \(\mathtt {SIGMA}\) scheme. The various security games are shown in Figures 26 and 27 .

For any game that depends on a \(\Sigma\) scheme, we denote the scheme as follows: \(\mathtt {P}_{S}\) denotes the \(\mathtt {P}\) game depending on the \(\Sigma\) scheme S. For brevity, the scheme is sometimes omitted from the notation.

A commitment scheme is another cryptographic primitive allowing a committer with some message msg to convince a verifier of two things: First, that msg has a fixed value set before contacting the verifier. Second, that the committer can at any later time reveal the value of msg to the verifier.

In particular, it must be the case that the verifier is convinced that the revealed message has not been changed from the original fixed message.

A commitment scheme is parameterized by types of messages, opening keys, and commitments. The scheme is given by the following:

For any given instance of a commitment scheme, we define the security definitions from Definition 7.3 as the security games seen in Figures 30 and 31.

Following the presentation of Damgaard [50], we show how our \(\mathtt {SIGMA}\) scheme with related security games can be used to construct a commitment scheme. This result is mostly of theoretical interest, and has previously been formalized in CryptHOL [42]. We formalize the result in SSProve to experiment with leveraging the package laws to build one protocol from another, and compare this result with the construction in CryptHOL in Section 7.2.1.

The key component of this transformation is the \(\mathtt {COM}\) package shown in Figure 29. Here, \(\mathtt {COM}\) is parameterized by the \(\mathtt {SIGMA}\) scheme. Moreover, \(\mathtt {COM}\) is meant to be composed with the \(\mathtt {KEY}\) package, which is responsible for distributing the public and secret keys between the parties, and as such imports \(\texttt {Init}\) and \(\texttt {Get}\) . The \(\mathtt {KEY}\) package is shown in Figure 28. Note that the \(\mathtt {KEY}\) package contains the signing key. We use the \(\mathtt {KEY}\) package because we need to sample a commitment key that fits the relation of the \(\Sigma\) -protocol without revealing the underlying witness used. Without this package, we would not be able to use our theorems of the \(\Sigma\) -protocol without giving the committer access to the secret part of the relation.

\(\mathtt {COM}\) then exports two procedures:

In this transformation, the types of the underlying \(\Sigma\) -protocol dictate the types of the commitment scheme. In particular, the message type of the commitment scheme is the type of the challenge used in the \(\Sigma\) -protocol.

First, in Theorem 7.4, we show that the construction is hiding with its security bounded by the Special Honest-Verifier Zero-Knowledge property of the underlying \(\Sigma\) -protocol.

The binding property states that it must be infeasible for an adversary to produce two openings to the same commitments. Usually, this property is stated as: the probability of \(\mathtt {BIND}\circ \mathtt {COM}\) returning true, for any input, is sufficiently small. In SSProve, we do not have a unary logic to express such a statement. Rather, we prove in our relational logic that any adversary that makes \(\mathtt {BIND}\circ \mathtt {COM}\) return true, can be used to construct a program that outputs a witness of the relation. The package using the adversary to extract a witness for the relation is given by Figure 32. If a \(\Sigma\) -protocol is used to construct the commitment scheme, then the binding game is infeasible to win, because it is infeasible to compute the witness from the statement in a \(\Sigma\) -protocol. ¹²

To prove Theorem 7.5, we use Lemma 2.2 and Lemma 2.3 to replace the commitments with \(\Sigma\) -protocol transcripts, via \({\mathtt {SOUND}}^{1}\) .

The Schnorr protocol [87] is parameterized over a cyclic group \((\mathcal {G}, \texttt {*})\) with q elements generated by g. Schnorr’s protocol is a \(\Sigma\) -protocol for the relation \((h, w) \in \mathbf {R}\iff h = g^{w}\) , where w is an element of \(\mathbb {Z}_{q}\) and \(h \in \mathcal {G}\) .

Messages are elements \(a \in \mathcal {G}\) and responses are elements \(z \in \mathbb {Z}_{q}\) . Challenges are sampled from a uniform distribution over \(\mathbb {Z}_{q}\) .

The protocol is implemented as an SSP package as shown in Figure 33. In particular, the package exports match the expected imports of our \(\Sigma\) -protocol security statements.

Based on Lemmas 7.6 and 7.7, we can instantiate Theorems 7.4 and 7.5. For the latter, we can directly apply the theorem to show that any adversary has no advantage between the binding game and directly extracting the witness. For the former, the adversary also has no advantage, which we show in Theorem 7.8.

We omit the simple proof of the binding property [42, pg.9], which can be found in our formalization (Lemma commitment_binding in SigmaProtocol.v).