Linicrypt: A Model for Practical Cryptography

Abstract

A wide variety of objectively practical cryptographic schemes can be constructed using only symmetric-key operations and linear operations. To formally study this restricted class of cryptographic algorithms, we present a new model called Linicrypt. A Linicrypt program has access to a random oracle whose inputs and outputs are field elements, and otherwise manipulates data only via fixed linear combinations.

Our main technical result is that it is possible to decide in polynomial time whether two given Linicrypt programs induce computationally indistinguishable distributions (against arbitrary PPT adversaries, in the random oracle model).

We show also that indistinguishability of Linicrypt programs can be expressed as an existential formula, making the model amenable to automated program synthesis. In other words, it is possible to use a SAT/SMT solver to automatically generate Linicrypt programs satisfying a given security constraint. Interestingly, the properties of Linicrypt imply that this synthesis approach is both sound and complete. We demonstrate this approach by synthesizing Linicrypt constructions of garbled circuits.

Authors supported by NSF award 1149647.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Throughout cryptography, we find many examples of objectively practical constructions that share common features. In particular, they treat blocks of bits as atomic units, and manipulate these units by calling a symmetric-key primitive or by interpreting them as elements in a field and applying strictly linear operations to them. Below are just some examples:

• Standard block cipher modes like CBC, OFB, PCBC for privacy, and LRW modes [34] for tweakable block ciphers consist of calls to the underlying block cipher and xor, the linear operation in $GF(2^n)$. (This ignores matters of padding/ciphertext stealing, where the input is not an exact multiple of field elements.)

• Constructions in other settings also consist of calls to an underlying symmetric primitive along with xor operations: the Davies-Meyer construction & its variants [13, 47] for collision-resistance; the Even-Mansour [18] and Feistel [35] constructions for PRPs; NMAC, HMAC [31], and VMAC [32] for authenticity; Naor’s commitment scheme [41].

• Some constructions use $GF(2^n)$-linear transformations with (fixed) coefficients other than 1 (i.e., these constructions use multiplication by fixed field elements). These include: OCB mode [50] for authenticated encryption, CMC mode [23] for disk encryption, XE/XEX modes [49] for tweakable block ciphers, PMAC [12] for authentication.

• Signing algorithms for lightweight one-time signature schemes like those of Lamport [33] and Winternitz [52] consist purely of calls to a one-way or [target] collision-resistant hash function. Variants like W-OTS+ [25] incorporate xor operations. Few-time signature schemes like HORS and variants [45, 48] also use only a random oracle. These simple signature schemes can be composed to give many-use signature schemes using Merkle trees [39] and derivatives thereof [11, 14–16, 21, 40, 44]. These extensions do not introduce any additional operations on the atomic field elements.

• Practical constructions of garbled circuits [22, 29, 30, 42, 53] simply use xor and calls to an underlying hash function/KDF, while the construction of [46] uses polynomial interpolation (with fixed points of evaluation) over $GF(2^n)$, which is a linear operation.

1.1 Overview of Our Results

Inspired by the constructions above, we introduce a restricted model of computation called Linicrypt. Programs in the Linicrypt model have access to a random oracle (to model a symmetric-key primitive), whose inputs and outputs are elements of a field $\mathbb {F}$. The field $\mathbb {F}$ is public and its size should be exponential in the security parameter.

Beyond calling a random oracle, Linicrypt programs can manipulate field elements only by uniformly sampling them or by applying fixed linear combinations. More formally, a (pure) Linicrypt program is a fixed sequence of statements of the following form:

Linicrypt is expressive enough to capture cryptographic construction of interest, but still restrictive enough that it provides several key benefits:

• 1. It is tractable to reason about cryptographic properties of Linicrypt programs. Our main technical result is that it is possible to decide, in polynomial time, whether two Linicrypt programs induce indistinguishable output distributions (in the random oracle model, against arbitrary PPT adversaries).

  We also point out that unforgeability properties (e.g., given the output of a program $\mathcal {P}$, it is hard to predict an internal value $v^*$) can be easily transformed into indistinguishability properties, making many standard styles of security definition expressible (and efficiently decidable) in Linicrypt.

• 2. Unlike in other restricted models, Linicrypt programs manipulate data as atomic units. This makes it possible to prove fine-grained lower bounds to the level of optimal constant factors (e.g., “this cryptographic task cannot be done in Linicrypt with keys smaller than $5\lambda$ bits”). Such lower bounds for Linicrypt hold in the random oracle model, and hence they also imply impossibility of a black-box construction from one-way functions.

• 3. The question of finding a Linicrypt program whose output is indistinguishable from some specification (e.g., its output is pseudorandom) can be expressed as an existential formula. One can then use an SAT/SMT solver to find a witness — i.e., automatically synthesize a secure Linicrypt construction. Additionally, if the formula is found to be unsatisfiable, it implies that no secure Linicrypt construction exists for the task — i.e., this paradigm for program synthesis is both sound and complete.

In Sect. 2 we formally define Linicrypt, develop techniques to reason about its algorithms, and prove our main technical result. Later in Sect. 3 we give an example application of our approach to program synthesis. We show how to use an SMT solver to synthesize secure Linicrypt constructions of garbled circuits. Specifically, for a given boolean function $f: \{0,1\}^k \rightarrow \{0,1\}^\ell$ (e.g., an adder, a multiplexer), we synthesize Linicrypt procedures to garble f (as an atomic unit) in a way that is compatible with the Free XOR optimization of [30].

1.2 Related Work and Inspiration

Minicrypt. Linicrypt is inspired in name by Impagliazzo’s [26] Minicrypt, which refers to a hypothetical world in which one-way functions exist but no “fancier” cryptography is possible. Minicrypt is formalized (as in [27]) by having a random oracle and allowing adversaries to be computationally unbounded (but with only polynomially many queries to the oracle). In this way, the random oracle becomes the only available source of computational cryptography.

The main distinction therefore between Linicrypt & Minicrypt is the additional constraint of linearity. This restriction allows Linicrypt lower bounds to resolve optimal constant factors, whereas optimal constant factors are not typically well-defined in Minicrypt. For example, imagine instantiating a secure Minicrypt scheme with security parameter $\lambda /c$; as a function of $\lambda$, the resulting construction would typically have constants reduced by a factor of c but still be secure.

Generic Group Model. Linicrypt has many similarities to the generic group model (GGM) of Shoup [51]. In the GGM, adversaries are restricted to manipulating elements of a cyclic group in a black-box way using only the prescribed group operations. While the GGM was originally proposed as a heuristic model for adversaries, one can also use GGM constructions to prove lower bounds. Dodis et al.  [17] show that full-domain hashing from RSA cannot be proven secure using techniques that treat the RSA group as a generic multiplicative group. Papakonstantinou et al.  [43] show that identity-based encryption is impossible via a GGM construction (without a bilinear pairing).

GGM lower bounds can identify optimal constant factors, which is one of the goals of Linicrypt. A line of work by Abe et al.  [1–3] considers the case of structure-preserving digital signatures. They prove (among other things) that 3 group elements are optimal for structure-preserving signatures implemented by GGM algorithms. More recently, synthesis has been effectively applied [7] to generate novel and optimal structure-preserving schemes.

Despite these similarities, we point out some important technical differences:

• (1) In the GGM, group elements are represented via a random encoding into bits, and adversaries are allowed to “look at” these encodings. This is slightly less restricting than our compartmentalized approach in which encodings don’t play a part (and hence Linicrypt programs cannot perform equality tests). In that regard, our model is similar to the generic-group variant of Maurer [38]. Since our goal is to place restrictions on constructions rather than adversaries, the distinction does not seem to be very significant.

• (2) Linicrypt includes a random oracle, which has not yet been considered in GGM lower bound results to the best of our knowledge. The random oracle is indeed a source of technical complications in Linicrypt.

• (3) Both Linicrypt and GGM allow only linear operations (e.g., in the GGM, a value “in the exponent” can only be manipulated in linear ways). However, a Linicrypt program must apply linear operations with fixed (i.e., known to the adversary) coefficients, while the GGM model allows constructions to choose random (secret) coefficients. This difference is what allows Diffie-Hellman-style constructions to be modeled in GGM but not in Linicrypt. Namely, a GGM algorithm can hide a random value “in the exponent” by performing the generic operation $g \mapsto g^x$, but the analogous operation in Linicrypt ($v \mapsto xv$) hides nothing since x would always be considered fixed.

Algebraic Cryptography Model. Applebaum et al.  [6] define a model for arithmetic cryptography, building on earlier work by Ishai et al.  [28]. Their model has some similarities to Linicrypt but also fundamental differences. Compared to Linicrypt, the arithmetic model allows for general field operations on its elements, not just linear combinations. More importantly, the defining feature of the arithmetic model is that the construction is oblivious to the underlying field/ring — the construction must work no matter what field/ring is used. In order to model cryptographic practice, Linicrypt allows the ring to be specified by the construction. Additionally, their model does not currently include random oracles, and hence it is only applicable to information-theoretic constructions or computational assumptions that can be obtained from the algebraic structure in a black-box way. The model is not equipped to consider standard assumptions like the existence of pseudorandom functions or collision-resistant hash functions.

Linear Garbling. In this work we study Linicrypt programs in the context of garbled circuit constructions. This is inspired in part by the lower bound of Zahur et al.  [53]. They too observe that practical garbled circuit constructions consist of only linear operations and calls to a random oracle. They prove a lower bound, namely, that such “linear garbling schemes” require 2 field elements to garble a single and gate.

In concurrent and independent work, Pastro et al.  [36] extend the model of linear garbling and characterize security in terms of linear-algebraic properties like span. They generalize the garbling scheme of [53] to natively support low-degree polynomials (not just AND-gates).

Later in Sect. 3 we go into more detail about the ZRE lower bound in the context of Linicrypt. For now, we simply point out the main differences between our work and the two above: (1) in this work we present a full theory of Linicrypt, not constrained only to garbled circuits; (2) the above models of linear garbling only consider “Linicrypt programs” that make non-adaptive calls to the random oracle, whereas our general Linicrypt model has no such restriction (arguably, the ability to reason about arbitrary oracle queries is the most important feature of Linicrypt). The difference is important specifically in the context of garbled circuits since, in most schemes, adaptive oracle queries result when composing several gates together in a larger circuit.

Synthesis of Cryptographic Constructions. Synthesis has been effectively used in the generic group model to discover batching schemes for signature verification [5] and optimal structure-preserving signatures [7]. Both of these results synthesize constructions involving bilinear pairings.

Malozemoff et al.  [37] synthesized IND-CPA secure block cipher modes by expressing the main loop of a mode as a directed graph. They defined typing rules for the vertices of this graph and showed that if a valid assignment of types exists, then the resulting scheme is secure. Using a SAT solver, they were able to check for valid type assignments for candidate modes and subsequently enumerate secure modes. In a followup work, Hoang et al.  [24] extended the synthesis to authenticated encryption modes built from tweakable block ciphers.

Prior work of Gagné et al.  [19, 20] developed techniques for automated proofs of security for (CPA-secure) block cipher modes. Akinyele et al.  [4] use an SMT solver to automate transformations of pairing-based signature schemes.

In all of the works involving block cipher modes [19, 20, 24, 37] the techniques are developed for modes involving just xor operations and [tweakable] block cipher calls. This corresponds to a natural special case of Linicrypt. We emphasize, however, that in these works the methods are sound but not complete.¹

2 Linicrypt

2.1 Basic Model

A pure Linicrypt program over field $\mathbb {F}$ is a tuple $\mathcal {P} = (\mathsf {in}, \mathsf {out}, \mathsf {cmds})$, where: $\mathsf {in}$ is a nonnegative integer, $\mathsf {out}$ is an ordered sequence of indices from $\{1, \ldots , |\mathsf {cmds}|\}$, and $\mathsf {cmds}$ is an ordered sequence of Linicrypt commands. The ith command in $\mathsf {cmds}$ must have one of the following forms:

• $(\textsc {inp}, j)$, where $1 \le j \le \mathsf {in}$ [retrieve a value from input]

• $(\textsc {samp})$ [sample an element of $\mathbb {F}$]

• $(\textsc {lin}, c_1, \ldots , c_{i-1})$, where each $c_j \in \mathbb {F}$ [perform a linear combination of values]

• $(\textsc {hash}, t, j_1, \ldots , j_k)$, where $t \in \{0,1\}^*$ and $j_1, \ldots , j_k < i$ [call the random oracle on a set of variables, and additional (fixed) string t]

Intuitively, the program $\mathcal {P}$ takes as input a vector from $\mathbb {F} ^\mathsf {in}$, then performs the operations specified by $\mathsf {cmds}$. Each of the internal values of $\mathcal {P}$ is assigned to a variable v[i]. Finally, the program outputs the values whose indices are in the set $\mathsf {out}$. More formally, we define the behavior of $\mathcal {P}$ as a process via:

Note that H is an oracle with type $H: \{0,1\}^* \times \mathbb {F} ^* \rightarrow \mathbb {F}$. In informal discussions, we often omit the first argument to H when it is an empty string.

2.2 Mixed Linicrypt Programs and Modelling Real-World Primitives

Most of the cryptographic primitives listed in the introduction cannot actually be implemented strictly as pure Linicrypt programs. For example, consider the one-time Winternitz signature of a single “digit” $x \in [m]$. The secret key $sk \leftarrow \mathbb {F}$ is chosen uniformly. The public key is then $pk := H^{(m)}(sk)$. To sign x, release $\sigma := H^{(x)}(sk)$. Then to verify, check $pk \overset{?}{=} H^{(m-x)}(\sigma )$.

The main operations in Winternitz are simply repeated calls to the hash/one-way function H, which are certainly allowed in Linicrypt. However, the signing algorithm uses x in a non-linear way — to choose how many Linicrypt commands to execute!

Fig. 1.

The signing algorithm for one-time Winternitz signatures as a mixed Linicrypt program. Each inner box on the right-hand side is a pure Linicrypt programs, $\mathsf{sign} (\cdot ,x)$, for fixed x.

We therefore extend the scope of Linicrypt beyond pure Linicrypt programs. A mixed Linicrypt program is one in which we designate some inputs to be non-linear and the others to be linear. For instance, in the signing algorithm of Winternitz signatures there is a for-loop whose exit condition is non-linear in x.

We can associate any mixed Linicrypt program with a collection of pure Linicrypt programs. Think of any mixed Linicrypt program as a switch/case statement (based on its non-linear input) selecting which pure Linicrypt program to run. See Fig. 1 for the example of Winternitz signatures. Each $\mathsf{sign} (\cdot ,x)$ is a pure Linicrypt program. Since x is public in the security definition for signatures, we can express the security of the (mixed) signing algorithm in terms of the properties of each (pure) program $\mathsf{sign} (\cdot , x)$.

The way one decides to model some inputs as non-linear and other inputs as linear is highly application-specific. In general, it makes the most sense to let the length of non-linear inputs to be a constant c: First, the complexity of deciding security and synthesizing constructions grows exponentially with c. Second, this implies that all of the security properties are a result of the Linicrypt operations (the random oracle and linear operations over a field $\mathbb {F}$, whose size is exponential in the security parameter) and not the non-linear behavior. In other words, in a security game an adversary could guess with constant probability the non-linear input, leaving a residual pure Linicrypt program. So security is reduced to the security properties of the individual pure Linicrypt programs in the collection.

Throughout the rest of this section we develop a general theory of Linicrypt, and restrict our attention to pure Linicrypt programs. Later when discussing specific applications of Linicrypt to garbled circuits, we explicitly discuss mixed Linicrypt programs and non-linear inputs, etc.

2.3 Algebraic Representation

Let $\mathcal {P}$ be a (pure) Linicrypt program with notation as above. Say that v[i] is a derived variable if $\mathsf {cmds}[i]$ is of the form $(\textsc {lin}, \cdots )$. Otherwise say that v[i] is a base variable. That is, a base variable is the result of a command with one of samp, hash, or inp. Let $\mathsf {base}$ denote the number of base variables. The main idea behind manipulating Linicrypt programs in an algebraic way is to observe that all values of importance can be expressed as linear functions of the base variables.

In more detail, fix an ordering of the base variables and denote them by the vector ${\varvec{v}}_{\textsf {base}}$. Then for the ith command in $\mathsf {cmds}$, define $\mathsf {row}(i)$ to be the vector in $\mathbb {F} ^{\mathsf {base}}$ such that $v[i] = \mathsf {row}(i) \cdot {\varvec{v}}_{\textsf {base}}$, where the $\cdot$ denotes dot product of vectors. More formally:

$$ \mathsf {row}(i) \overset{\textsf {def}}{=} {\left\{ \begin{array}{ll} [\overbrace{0~0\cdots ~0}^{j-1}~1~0\cdots 0] &{} \text{ if } v[i] \text{ is } \text{ the } j\text{ th } \text{ base } \text{ variable } \\ \sum _j c_j \mathsf {row}(j) &{} \text{ if } \mathsf {cmds}[i] = (\textsc {lin}, c_1, \ldots , c_{i-1}) \end{array}\right. }. $$

We create a matrix to represent the output of a Linicrypt program:

$$\begin{aligned} \mathcal {M}&\overset{\textsf {def}}{=} \begin{bmatrix} \text{--- } \mathsf {row}(o_1) \text{--- } \\ \vdots \\ \text{--- } \mathsf {row}(o_k) \text{--- } \end{bmatrix}, \quad \text{ where } \mathsf {out}= (o_1, \ldots , o_k). \end{aligned}$$

$\mathcal {M}$ therefore characterizes the direct correlations among the program’s output variables. Yet, it contains no information about how these variables may be correlated via the random oracle! So, our characterization of a Linicrypt program includes a set of oracle constraints. The idea behind an oracle constraint $\langle t, \mathcal {Q}, \varvec{a} \rangle$ is that if the random oracle is called on input $(t; \mathcal {Q}\times {\varvec{v}}_{\textsf {base}})$ then the response will be $\varvec{a}\cdot {\varvec{v}}_{\textsf {base}}$.

$$\begin{aligned} \mathcal {C}&\overset{\textsf {def}}{=}\left. \left\{ \left\langle t, \begin{bmatrix} \text{--- } \mathsf {row}(j_1) \text{--- } \\ \vdots \\ \text{--- } \mathsf {row}(j_k) \text{--- } \end{bmatrix}, \mathsf {row}(i) \right\rangle ~\right| ~ \mathsf {cmds}[i] = (\textsc {hash}, t, j_1, \ldots , j_k) \right\} \end{aligned}$$

Without loss of generality, we can assume that no two constraints share $(t, \mathcal {Q})$ in common. Under that restriction, the set $\{ \varvec{a}\mid \langle t, \mathcal {Q}, \varvec{a} \rangle \in \mathcal {C} \}$ is a linearly independent set — i.e., the results of distinct random oracle queries are linearly independent.

Finally, we define the algebraic representation of a Linicrypt program $\mathcal {P}$ to be $(\mathcal {M},\mathcal {C})$. We refer to $\mathcal {M}$ as the output matrix and $\mathcal {C}$ as the set of oracle constraints.

To demonstrate the different ways of viewing a Linicrypt program, consider the following example, with $\mathsf {in}= 0$:

There are three base variables. With $v_4, v_5$ being output variables, the output matrix $\mathcal {M}$ consists of $\mathsf {row}(4), \mathsf {row}(5)$. There is one $\textsc {hash}$-command “$v_4 := H(\texttt {foo},v_3,v_2)$,” leading to a single oracle constraint $\langle \mathtt {foo}, \begin{bmatrix}\mathsf {row}(3) \\ \mathsf {row}(2) \end{bmatrix}, \mathsf {row}(4) \rangle$.

In the rest of this paper, we specialize to input-less (i.e., $\mathsf {in}=0$) Linicrypt programs. Restricting our domain to input-less programs simplifies the definitions & proofs. This is justified by our main application to garbled circuits. In the security definition for garbled circuits, the adversary chooses an input x to the function, but since we model x as non-linear input, what is left over is a collection of security experiments, one for each x, each involving an input-less (pure) Linicrypt program.

We hereafter overload notation and write $\mathcal {P} = (\mathcal {M},\mathcal {C})$. We claim that $(\mathcal {M}, \mathcal {C})$ completely characterizes the behavior of $\mathcal {P}$. In more detail, let $\mathcal {P}$ be an input-less Linicrypt program, let $\mathcal {A}$ be an oracle machine, and consider the following canonical simulation of $\mathcal {P}$.

(1)

The idea is to simply sample all of the base variables upfront, instead of deriving some of them via calls to the random oracle. But then to make the simulation of the random oracle consistent, we “patch” the random oracle so that when queried on $(t, \mathcal {Q}{\varvec{v}}_{\textsf {base}})$, the consistent result $\varvec{a}\cdot {\varvec{v}}_{\textsf {base}}$ is simulated (lines 7–8). The simulation aborts when two oracle constraints are in conflict (lines 5–6).

Lemma 1

(Canonical Simulation). Let $\mathcal {P}$ be an input-less (i.e., $\mathsf {in}=0$) Linicrypt program that executes n hash-commands. Then for all oracle machines $\mathcal {A}$:

$$ \Pr \Big [ \mathcal {S}^{\mathcal {A}}_{\mathcal {P}}() = 1 \Big ] - \Pr _H\Big [ \mathcal {A} ^H(\mathcal {P} ^H()) = 1 \Big ] \le \frac{n(n+1)}{2|\mathbb {F} |}. $$

We emphasize that $\mathcal {A}$ here is an arbitrary program. It need not be linear, it may be computationally unbounded, and (at least for this lemma) it is even unrestricted in the number of oracle queries it makes.

Proof

(Sketch). Conditioned on the simulation not aborting in line 6, the simulation is perfect. Essentially, each query to H answered in lines 7–8 is answered with a randomly chosen base variable (since each $\varvec{a}$ is a canonical basis vector), exactly matching how queries are answered by an honest random oracle. Hence, the error in the simulation is the probability that the condition in line 5 is true. This happens if $\mathcal {Q}{\varvec{v}}_{\textsf {base}} = \mathcal {Q}' {\varvec{v}}_{\textsf {base}}$ for some distinct constraints $\langle t, \mathcal {Q}, \varvec{a} \rangle , \langle t, \mathcal {Q}', \varvec{a}' \rangle \in \mathcal {C}$. Since WLOG no two constraints share $(t, \mathcal {Q})$, we have that $\mathcal {Q}- \mathcal {Q}'$ is a nonzero matrix, and therefore that

$$\mathcal {Q}{\varvec{v}}_{\textsf {base}} = \mathcal {Q}' {\varvec{v}}_{\textsf {base}} \Longleftrightarrow (\mathcal {Q}- \mathcal {Q}') {\varvec{v}}_{\textsf {base}} = 0 \Longleftrightarrow {\varvec{v}}_{\textsf {base}} \in \textsf {kernel}(\mathcal {Q}- \mathcal {Q}').$$

Note that $\textsf {kernel}(\mathcal {Q}- \mathcal {Q}')$ is a proper subspace of $\mathbb {F} ^\mathsf {base}$ with maximum dimension $(\mathsf {base}-1)$. Then, when ${\varvec{v}}_{\textsf {base}}$ is chosen uniformly from $\mathbb {F} ^\mathsf {base}$, the probability that it is in a particular proper subspace is at most $|\mathbb {F} |^{\mathsf {base}-1} / |\mathbb {F} |^\mathsf {base}= 1 / |\mathbb {F} |$. Recall that $\mathcal {P}$ executes n hash-commands. Then there are ${n \atopwithdelims ()2} = n(n+1)/2$ possible pairs of distinct oracle constraints. By the union bound, the probability that there exist some pair of oracle constraints with $\mathcal {Q}$ and $\mathcal {Q}'$ for which ${\varvec{v}}_{\textsf {base}} \in \textsf {kernel}(\mathcal {Q}-\mathcal {Q}')$ is at most $n(n+1)/2|\mathbb {F} |$.

2.4 Linear Transformations, Basis Changes and Composition

The algebraic representation for Linicrypt programs turns out to be convenient, as we can perform linear-algebraic manipulations to Linicrypt programs.

For instance, consider applying a linear transformation to a Linicrypt program. Let $\mathcal {P} = (\mathcal {M},\mathcal {C})$ be a Linicrypt program. Recall that the width of the vectors in $\mathcal {M}$ and $\mathcal {C}$ is $\mathsf {base}$. Now let B be a $\mathsf {base}\times \mathsf {base}$ matrix with entries in $\mathbb {F}$ and consider the Linicrypt representation $(\mathcal {M} B, \mathcal {C} B)$, where

$$ \mathcal {C} B \overset{\textsf {def}}{=} \{ \langle t, \mathcal {Q}B, \varvec{a}B \rangle \mid \langle t, \mathcal {Q}, \varvec{a} \rangle \in \mathcal {C} \}. $$

When B is an invertible matrix, we refer to $(\mathcal {M} B, \mathcal {C} B)$ as a basis change of B applied to $(\mathcal {M},\mathcal {C})$. Such a basis change has no effect on the output distribution of the Linicrypt program. More precisely:

Proposition 2

Let $\mathcal {P} = (\mathcal {M},\mathcal {C})$ be an input-less Linicrypt program, and let $\mathcal {P} ' = (\mathcal {M} B, \mathcal {C} B)$ for some invertible matrix B. Then for all oracle machines $\mathcal {A}$, we have:

$$ \Pr \Big [ \mathcal {S}^{\mathcal {A}}_{\mathcal {P}}() = 1 \Big ] = \Pr \Big [ \mathcal {S}^{\mathcal {A}}_{\mathcal {P} '}() = 1 \Big ]. $$

Proof

A basis change by B is equivalent to adding a statement “${\varvec{v}}_{\textsf {base}}:= B {\varvec{v}}_{\textsf {base}}$” between lines 1 and 2 in Eq. 1. Since B is invertible, this additional statement has no effect on the distribution of ${\varvec{v}}_{\textsf {base}}$.

Composition. We can use the idea of a linear transformation to reason algebraically about the composition of two Linicrypt programs. Let $\mathcal {P} = (\mathcal {M},\mathcal {C})$ be a Linicrypt program with no input and $\mathsf {out}$ outputs, and let $\mathcal {P} ' = (\mathcal {M} ', \mathcal {C} ')$ be a Linicrypt program with $\mathsf {out}$ inputs, so that it makes sense to feed the output of $\mathcal {P}$ as input to $\mathcal {P} '$. Without loss of generality, we make the following assumptions:

• Both programs have the same number of base variables (so that $\mathcal {M}$, $\mathcal {M} '$ have the same number of columns and so on).

• The first $\mathsf {out}$ base variables of $\mathcal {P} '$ are identified with its input variables.

The algebraic representation of $\mathcal {P} '$ implicitly treats all of its input variables as linearly independent. So the case when $\mathcal {M}$ has full rank is easiest. To compose the programs, one simply applies a basis change to either program to align $\mathcal {P}$’s output variables ($\mathcal {M}$) and $\mathcal {P} '$’s input variables (expressed as $[ I \mid \varvec{0} ]$, where I is the $\mathsf {out}\times \mathsf {out}$ identity matrix), and similarly align the oracle constraints of the programs. If such a basis change has been applied, then the composed program’s output is characterized by $\mathcal {M} '$ and its oracle constraints are simply $\mathcal {C} \cup \mathcal {C} '$.

However, in general the output of $\mathcal {P}$ may have linear correlations, and this can have a serious effect on the behavior of $\mathcal {P} '$. Take for example the case where $\mathcal {P} '$ takes two input variables $(v_1, v_2)$ and outputs $H(v_1) - H(v_2)$. Then the behavior of $\mathcal {P} '$ is qualitatively different when $v_1$ and $v_2$ are linearly independent vs. when they are correlated as $v_1 = v_2$, for instance.

In general, we consider applying a linear transformation to $\mathcal {P} '$ that “collapses” the appropriate base variables (they become associated with the same vector in the algebraic representation). Collapsing input base variables may result in the collapse of oracle queries that use these variables. In the example above, $H(v_1)$ and $H(v_2)$ are themselves base variables which are linearly independent in general; yet they collapse to the same base variable when $v_1 = v_2$.

Hence, to compose $\mathcal {P}$ with $\mathcal {P} '$ we consider a linear transformation $\varGamma$ applied to $\mathcal {P} '$, with the following properties:

• 1. $\varGamma$ aligns the input variables of $\mathcal {P} '$ (the first $\mathsf {out}$ base variables) with the output $\mathcal {M}$ of $\mathcal {P}$. That is, $\mathcal {M} = [ I \mid \varvec{0} ] \times \varGamma$ where I is the $\mathsf {out}\times \mathsf {out}$ identity matrix.

• 2. $\varGamma$ consistently aligns the oracle queries of $\mathcal {P} '$ to those in $\mathcal {P}$. That is, if $\langle t, \mathcal {Q}, \varvec{a} \rangle \in \mathcal {C} ' \varGamma$, and $\langle t, \mathcal {Q}, \varvec{a}' \rangle \in \mathcal {C}$, then $\varvec{a}= \varvec{a}'$.

• 3. $\varGamma$ collapses appropriate oracle constraints in $\mathcal {P} '$: that is, if $\varGamma$ causes (previously distinct) oracle constraints to now share the same t and $\mathcal {Q}$ components, then they must now also share the same $\varvec{a}$ component. More formally, the constraints in $\mathcal {C} ' \varGamma$ should all have distinct $t, \mathcal {Q}$ values. However, note that $\mathcal {C} ' \varGamma$ may have fewer constraints than $\mathcal {C} '$ due to collapses induced by $\varGamma$.

• 4. $\varGamma$ should only collapse base variables that are absolutely required by the above conditions. In other words, the rank of $\varGamma$ should be as large as possible given the above constraints. Note that if $\mathcal {M}$ has full rank, then $\varGamma$ will indeed be a basis change. However, in general $\varGamma$ may not be a basis change — this is consistent with the fact that feeding linearly correlated values into $\mathcal {P} '$ may indeed fundamentally change its behavior. A basis change exactly preserves behavior.

Given such a transformation $\varGamma$, then $(\mathcal {M} ' \varGamma , \mathcal {C} \cup \mathcal {C} ' \varGamma )$ is an algebraic representation for the composition of programs $\mathcal {P} ' \circ \mathcal {P}$.

2.5 Indistinguishability vs. Unpredictability

When we consider Linicrypt programs that implement cryptographic primitives, the most fundamental question is: when do two Linicrypt programs induce indistinguishable distributions (in the random oracle model)?

Definition 3

Let $\mathcal {P} _1$ and $\mathcal {P} _2$ be two input-less Linicrypt programs over $\mathbb {F}$. Let $\lambda = \log |\mathbb {F} |$ be the security parameter. We say that $\mathcal {P} _1$ and $\mathcal {P} _2$ are indistinguishable, and write $\mathcal {P} _1 \cong \mathcal {P} _2$, if for every (possibly computationally unbounded) oracle machine $\mathcal {A}$ that queries its oracle a polynomial (in $\lambda$) number of times, we have

$$\begin{aligned} \Pr [ \mathcal {A} ^H( \mathcal {P} _1^H ()) = 1 ] - \Pr [ \mathcal {A} ^H( \mathcal {P} _2^H()) = 1]\ is\ negligible\ in\ \lambda . \end{aligned}$$

The probabilities are over the choice of random oracle H and the coins of $\mathcal {P} _1$, $\mathcal {P} _2$, and $\mathcal {A}$.

We point out that indistinguishability can be used to reason about unforgeability properties as well. Suppose $\mathcal {P}$ is a Linicrypt program that has some special internal variable $v^*$, and we wish to formalize the idea that “$v^*$ is hard to predict (in the random oracle model) given the output of $\mathcal {P}$”. Now define the following two related programs:

• $\mathcal {P} _1$ runs $\mathcal {P}$ and outputs whatever $\mathcal {P}$ outputs, along with an additional output $v_{\textsf {extra}} = H(t^*; v^*)$, where $t^*$ is a “tweak” that is not used in $\mathcal {P}$.

• $\mathcal {P} _2$ runs $\mathcal {P}$ and outputs whatever $\mathcal {P}$ outputs, along with an additional output $v_{\textsf {extra}} \overset{\$}{\leftarrow }\mathbb {F}$.

Note that $\mathcal {P} _1$ and $\mathcal {P} _2$ are a Linicrypt programs if $\mathcal {P}$ is. Now observe that the following statements are equivalent:

• 1. Given the output of $\mathcal {P}$, the probability that an adversary (with access to the random oracle) outputs $v^*$ is negligible.

• 2. Given the output of $\mathcal {P}$, the probability that an adversary queries the random oracle on $H(t^*; v^*)$ is negligible.

• 3. Given the output of $\mathcal {P}$, the value $H(t^*; v^*)$ is indistinguishable from uniform. This follows simply from the definition of the random oracle model, and the fact that $\mathcal {P}$ itself does not use any values of the form $H(t^*;\cdot )$.

• 4. $\mathcal {P} _1 \cong \mathcal {P} _2$.

Hence, standard unforgeability properties of a Linicrypt program can be expressed as the indistinguishability of two Linicrypt programs. From now on, we therefore focus on indistinguishability only. And indeed, our main characterization theorem will include reasoning like that above, regarding which oracle queries can be made by an adversary with non-negligible probability.

2.6 Normalization

We now describe a procedure for “normalizing” a Linicrypt program. Specifically, normalizing corresponds to removing “unnecessary” calls to the oracle. We illustrate the ideas with a brief example, below:

This program has 3 oracle queries, two of which are “unnecessary” in some sense.

• It is instructive to consider what information the adversary can collect about the base variables ${\varvec{v}}_{\textsf {base}}$. From the output of $\mathcal {P}$, one obtains $v_3 = [1~{-1}~0~0] \cdot {\varvec{v}}_{\textsf {base}}$ and $v_5 = [0~0~0~1]\cdot {\varvec{v}}_{\textsf {base}}$. Then one can call the oracle as $H(\texttt {bar}, v_3)$ to obtain $v_4 = [0~0~1~0]\cdot {\varvec{v}}_{\textsf {base}}$. However, it is hard to predict $v_1 = [1~0~0~0]\cdot {\varvec{v}}_{\textsf {base}}$ given just the output of $\mathcal {P}$. More specifically, [1 0 0 0] is not in the span of $\{ [1~{-1}~0~0], [0~0~1~0], [0~0~0~1]\}$.

  In other words, the probability of an adversary querying H on $v_1$ is negligible, so we call this oracle query unreachable. Conditioned on the adversary not querying H on $v_1$, its output $v_2 = H(\texttt {foo}, v_1)$ looks uniformly random. Removing the corresponding oracle constraint therefore has negligible effect. Note that removing the oracle constraint corresponds to replacing “$v_2 := H(\texttt {foo}, v_1)$” with “$v_2 \overset{\$}{\leftarrow }\mathbb {F}$”; i.e., changing $\mathsf {cmds}[2]$ from $(\textsc {hash}, \texttt {foo}, 1)$ to $(\textsc {samp})$.

• Oracle query $H(\texttt {bar}, v_3)$ is reachable, since the output of $\mathcal {P}$ includes $v_3$. However, its result is $v_4$ which is not used anywhere else in the program. This can be seen by observing that all other row vectors in the algebraic representation have a zero in the position corresponding to $v_4$. Hence this oracle call can be replaced with “$v_4 \overset{\$}{\leftarrow }\mathbb {F}$” with no effect on the adversary. We call this query useless.

• Oracle query $H(\texttt {baz}, v_3)$ is similarly reachable, but it is useful. The result of this query is $H(\texttt {baz}, v_3)= v_5$ which is included in the output of $\mathcal {P}$ and hence visible to the adversary. It cannot be removed because an adversary could query $H(\texttt {baz}, v_3)$ and check that it matches $v_5$ from the output.

More generally, we normalize a Linicrypt program by computing which oracle queries/constraints are reachable and which are useless in the above sense.

To compute which oracle queries are reachable, we perform the following procedure until it reaches a fixed point: Given Linicrypt program $\mathcal {P} = (\mathcal {M},\mathcal {C})$, mark the rows of $\mathcal {M}$ as reachable. Then, if any oracle constraint $\langle t, \mathcal {Q}, \varvec{a} \rangle \in \mathcal {C}$ has every row of $\mathcal {Q}$ in the span of reachable vectors, then mark $\varvec{a}$ as reachable.

Instead of computing which queries are useful, it is more straight-forward to compute which queries are useless, one by one. Intuitively, a constraint $\langle t, \mathcal {Q}, \varvec{a} \rangle$ is useless if $\varvec{a}$ is linearly independent of all other vectors appearing in $\mathcal {M}$ and $\mathcal {C} '$ (either as rows of $\mathcal {M}$ or rows of some $\mathcal {Q}'$ or as an $\varvec{a}'$). After removing one useless constraint, other constraints might become useless. For instance, consider a Linicrypt program that outputs v but also internally computes H(H(H(v))). Only the outermost call to H is initially useless. After it is removed, the “new” outermost call is marked useless, and so on, until a fixed point is reached.

The details of the normalize procedure are given in Fig. 2. In the full version we prove the following:

Fig. 2.

Procedure to normalize a Linicrypt program. Since V is a multiset, we clarify that “$V \setminus \{\varvec{a}\}$” means to decrease the multiplicity of $\varvec{a}$ in multiset V by only one. So $V \setminus \{\varvec{a}\}$ may yet include $\varvec{a}$. One reason for $\varvec{a}$ to have high multiplicity in V is if $\varvec{a}$ appears both in an oracle constraint and as a row of $\mathcal {M}$.

Lemma 4

If $\mathcal {P}$ is an input-less Linicrypt program, then $\mathsf{normalize} (\mathcal {P}) \cong \mathcal {P}$ (Fig. 2).

2.7 Main Characterization

We can now present our main technical theorem about Linicrypt programs:

Theorem 5

(Linicrypt Characterization). Let $\mathcal {P} _1$ and $\mathcal {P} _2$ be two input-less Linicrypt programs over $\mathbb {F}$. Then $\mathcal {P} _1 \cong \mathcal {P} _2$ if and only if $\mathsf{normalize} (\mathcal {P} _1)$ and $\mathsf{normalize} (\mathcal {P} _2)$ differ by a basis change.

Proof

(Proof Sketch). The nontrivial case is to show the $\Rightarrow$ direction. Without loss of generality assume that $\mathcal {P} _1$ and $\mathcal {P} _2$ are normalized, and suppose they do not differ by a basis change. The idea is to first construct a “profile” for $\mathcal {P} _1$ and for $\mathcal {P} _2$. In the code of $\mathsf{normalize}$, we compute the reachable subspace of a program; the profile simply refers to the order in which reachable oracle constraints are activated during this process.

We use the profile to construct a family of canonical distinguishers for $\mathcal {P} _1$. It processes oracle constraints in the order determined by the profile. It maintains the invariant that at all stages of the computation, if $\mathcal {R}$ is the set of currently reachable vectors, the distinguisher holds $\mathbf {r} = \mathcal {R} \times {\varvec{v}}_{\textsf {base}}$, where ${\varvec{v}}_{\textsf {base}}$ refers to the base variables in the canonical simulation of $\mathcal {P} _1$.

A side-effect of normalization is that all oracle constraints are reachable and useful. Because of this, the set of reachable vectors will eventually contain non-trivial linear relations — as a matrix, the set of reachable vectors has a nontrivial kernel. A canonical distinguisher chooses some element $\mathbf {z}$ from this kernel and tests whether $\mathbf {z}^\top \mathbf {r} = 0$. By construction, $\mathbf {z}^\top \mathbf {r} = \mathbf {z}^\top \mathcal {R} {\varvec{v}}_{\textsf {base}}$. Since $\mathbf {z} \in \ker (\mathcal {R})$, the distinguisher always outputs true in the presence of $\mathcal {P} _1$.

Now the challenge is to show that, for some choice of $\mathbf {z} \in \ker (\mathcal {R})$, the distinguisher outputs false with overwhelming probability in the presence of $\mathcal {P} _2$. To see why, we consider the first point at which the profiles of $\mathcal {P} _1$ and $\mathcal {P} _2$ disagree (if the profiles agree fully, then it is easy to obtain a basis change relating $\mathcal {P} _1$ to $\mathcal {P} _2$). The most nontrivial case is when $\mathcal {P} _1$ contains an oracle constraint that no basis change can bring into alignment with $\mathcal {P} _2$. This implies that when the distinguisher makes the query in the presence of $\mathcal {P} _2$, it will not trigger any oracle constraint and the result will be random and independent of everything else in the system. But because this oracle constraint was useful in $\mathcal {P} _1$, we can eventually choose a final kernel-test $\mathbf {z}$ that is “sensitive” to the result in the following way: While in $\mathcal {P} _1$, the kernel-test always results in zero, in $\mathcal {P} _2$ the kernel test will be independently random.

The actual proof is considerably more involved concerning the different cases for why the profiles of $\mathcal {P} _1$ and $\mathcal {P} _2$ disagree.

3 Synthesizing Linicrypt Garbled Circuits

In this section we describe how to express the security of garbled circuits in the language of Linicrypt, culminating in a method to leverage an SMT solver to automatically synthesize secure schemes. We assume some familiarity with the classical (textbook) Yao garbling scheme. Roughly speaking, each wire in the circuit is associated with two labels (bitstrings) $W^0$ and $W^1$, encoding $\textsc {false}$ and $\textsc {true}$, respectively. The evaluator will learn exactly one of these two labels for each wire. Then, for each gate in the circuit, the evaluator uses the labels for the input wires, along with garbled gate information (classically, the garbled truth table), to compute the appropriate label on the output wire. We restrict our synthesis technique to the context of two basic garbled circuit techniques: Free-XOR and Point-and-Permute.

Free-XOR. In the Free-XOR garbling technique of Kolesnikov and Schneider [30], the garbler chooses a random $\varDelta$ that is global, and arranges for $W^0 \oplus W^1 = \varDelta$ on every wire. Hereafter, we typically write the $\textsc {false}$ label simply as W and the $\textsc {true}$ wirelabel as $W \oplus \varDelta$; more generally, the wirelabel encoding b is $W \oplus b\varDelta$.

Using Free-XOR, no ciphertexts are necessary to garble an $\textsc {xor}$ gate. For instance, let A and B be the $\textsc {false}$ input wirelabels. Set the $\textsc {false}$ output wirelabel to $C = A \oplus B$. Then when the evaluator holds wirelabels $A^* = A \oplus a\varDelta$ and $B^* = B \oplus b\varDelta$ (encoding a and b, respectively), she can compute $A^* \oplus B^* = A \oplus a\varDelta \oplus B \oplus b\varDelta = C \oplus (a\oplus b)\varDelta$. That is, the result will be the wirelabel correctly encoding truth value $a \oplus b$. We note that no garbled gate information is required in the garbled circuit, nor must the evaluator perform any cryptographic operations to evaluate the gate — just an $\textsc {xor}$ of strings.

Free-XOR is ubiquitous in practical implementations of garbled circuits. For that reason (and because it conveniently reduces degrees of freedom over choice of wirelabels), we restrict our attention to garbling schemes that are compatible with Free-XOR.

Point-and-Permute and Non-linearity. The point-and-permute optimization of [8] is used in all practical garbling schemes. The idea is to append to each wirelabel a random bit $\chi$ (which we call the “color bit”). The two labels on each wire have opposite (but random) color bits.

Now consider the naive/classical garbling of an $\textsc {and}$ gate, in which the garbler generates 4 ciphertexts. Because color bits are independent of truth values, the garbler can arrange the ciphertexts in order of the color bits of the input wirelabels. The evaluator selects and decrypts the correct ciphertext indicated by the color bits of the input wirelabels she holds. Importantly, this makes the color bits non-linear inputs with respect to Linicrypt! The color bits determine which linear combination the evaluator will apply.

Similarly, the garbler’s behavior is non-linear in a complementary way. We refer to $\sigma$ as the “select bit” such that the wirelabel encoding truth value v has color $\chi = v \oplus \sigma$. Equivalently, $\sigma$ is the (random) color bit of the $\textsc {false}$ wire. We emphasize that $\sigma$ is known only to the garbler, and $\chi$ is known only to the evaluator, effectively hiding the truth value v. In typical garbling schemes, the garbler’s behavior depends non-linearly on $\sigma$ but is otherwise within the Linicrypt model.

We treat garbling schemes as mixed Linicrypt programs, as in Sect. 2.2. Then, a mixed Linicrypt garbling scheme is a collection of pure Linicrypt garbling programs indexed by color bits and select bits.

Restricting to Linicrypt with $\textsc {xor}$ as the Linear Operation. Technically speaking, a Linicrypt program is an infinite family of programs, one for each value of the security parameter. Unfortunately, we can only synthesize an object of finite size. Hence we restrict our focus to single Linicrypt programs that are compatible with an infinite family of fields/security parameters, in the following way.

Suppose a Linicrypt program uses field GF(p) for prime p. Then that Linicrypt program is also compatible with field $GF(p^\lambda )$ for any $\lambda$, since $GF(p) \subseteq GF(p^\lambda )$ in a natural way. A very natural special case is $p=2$, which corresponds to Linicrypt programs that use $GF(2^\lambda )$ and use only linear combinations with coefficients from $\{0,1\}$ — in other words, Linicrypt programs that are restricted to using $\textsc {xor}$ as their only linear operation. Hereafter we restrict our attention to $\textsc {xor}$-only Linicrypt programs.

3.1 Gate-Garbling

A garbling scheme for an entire circuit is a non-trivially large object — much too large to synthesize using a SAT/SMT solver. We instead focus on techniques for garbling individual gates in a way that allows them to be securely composed with other gates and the Free-XOR technique to yield a garbling scheme for arbitrary circuits.

Notation. A wirelabel that carries the truth-value $\textsc {false}$ is always signified W, a wirelabel that carries $\textsc {true}$ is always $W \oplus \varDelta$, and a wirelabel carrying unknown truth-value is always $W^*$. We collect wirelabels into vectors notated as follows: $\mathbf {W} = W_1, \ldots , W_n$. Operations over vectors are computed componentwise. For instance, $\mathbf {A} \oplus \mathbf {B} = A_1 \oplus B_1, \ldots , A_n \oplus B_n$. When $\varDelta \in GF(2^\lambda )$ and x is a string of n bits, we write $x \varDelta$ to mean the vector $x_1 \varDelta , \ldots , x_n \varDelta$. For example, if $\mathbf {W} = W_1, \ldots , W_n$ are a vector of $\textsc {false}$ wirelabels, then $\mathbf {W} \oplus x \varDelta$ is a vector of wirelabels encoding truth values x.

Syntax. Let $\tau : \{0,1\}^m \rightarrow \{0,1\}^n$ be the functionality of an m-ary boolean gate that we wish to garble. Let $\sigma = \sigma _1 \,||\, \ldots \,||\, \sigma _m$ be a string of select bits and $\chi = \chi _1 \,||\, \ldots \,||\, \chi _m$ be a string of color bits. Then, a free-XOR compatible garbled gate consists of algorithms:

$$\begin{aligned}&\textsf {GateGb} (\sigma ;\, A_{1}, \ldots , A_{m}, \varDelta ) \rightarrow (C_{1}, \ldots , C_{n};\, G_1, \ldots , G_\ell )\\&\textsf {GateEv} (\chi ;\, A^*_{1}, \ldots , A^*_{m}, G_1, \ldots , G_\ell ) \rightarrow (C^*_{1}, \ldots , C^*_{n}) \end{aligned}$$

The semantics are as follows. $\textsf {GateGb}$ takes m $\textsc {false}$ input wirelabels $\mathbf {A} = A_1, \ldots , A_m$, their select bits $\sigma$, and global constant $\varDelta$. It returns the n $\textsc {false}$ output wirelabels $\mathbf {C} = C_1, \ldots , C_m$, and garbled gate information $\mathbf {G} = G_1, \ldots , G_\ell$. The evaluator takes m input wirelabels with unknown truth values $\mathbf {A^*} = A^*_1, \ldots , A^*_m$, their color bits $\chi$, and the garbled gate information $\mathbf {G}$. It returns output wirelabels with unknown truth values $\mathbf {C^*} = C^*_1, \ldots , C^*_n$.

We emphasize that when $\textsf {GateGb}$ and $\textsf {GateEv}$ are Linicrypt programs, all inputs and outputs besides $\sigma$ and $\chi$ are field elements in $GF(2^\lambda )$.

Correctness. If a gate garbling scheme is correct, then the evaluator can always produce the correct output wirelabels according to $\tau$. That is, when the evaluator holds wirelabels encoding x on the input wires, the result of evaluating the gate is the wirelabels encoding $\tau (x)$ on the output wires.

Definition 6

A Free-XOR-compatible garbled gate $(\textsf {GateGb}, \textsf {GateEv})$ correctly computes functionality $\tau : \{0,1\}^m \rightarrow \{0,1\}^n$ if for all inputs $x \in \{0,1\}^m$, select bit strings $\sigma \in \{0,1\}^m$, and color bit string $\chi \in \{0,1\}^m$, with $x = \sigma \oplus \chi$, false input wirelabels $\mathbf {A} = A_1, \ldots , A_m$, global Free-XOR constant $\varDelta$:

$$ (\mathbf {C}, \mathbf {G}) \leftarrow \textsf {GateGb} (\sigma ;\, \mathbf {A}, \varDelta ) \implies \textsf {GateEv} (\chi ;\, \mathbf {A} \oplus x \varDelta ,\, \mathbf {G}) = \mathbf {C} \oplus \tau (x) \varDelta $$

Security. One important consideration is that in the free-XOR setting, the labels of different wires can have linear correlations. The gate should be secure even for such correlated input wirelabels.²

We define security in terms of the evaluator’s view in a typical garbling scenario. Then we define $\textsf {View}_R^H(\chi ,x)$ to encapsulate the information the evaluator sees for this gate, when the visible color bits are $\chi$, the logical gate inputs are x, and the input wirelabels have correlations described by an $m \times m$ matrix R.

We call R non-degenerate if no row of R is all-zeroes, as that would lead to a zero wirelabel (whose complementary wirelabel would immediately leak $\varDelta$). In particular, if $R = I$ then the wirelabels are independent.

Importantly, if $\textsf {GateGb} ^H$ is a Linicrypt program and parameters $\chi$ and x are fixed, then $\textsf {View}_R^H(\chi ,x)$ is a input-less Linicrypt program. We can therefore apply the results of Sect. 2 to reason about the indistinguishability and unforgeability properties required of $\textsf {View}^H$. The fact that these properties can be expressed algebraically is the core of our synthesis technique.

We define the following security property for a Free-XOR compatible garbled gate scheme:

Definition 7

A Free-XOR compatible garbled gate is secure if:

• 1. for all $\chi ,\, x \in \{0,1\}^m$, all non-degenerate $R \in \{0,1\}^{m \times m}$, and all polynomial-time oracle algorithms A, the probability $\Pr [\, A^H(\textsf {View}_R^H(\chi ,x)) = \varDelta \,]\ is negligible\ in\ \lambda ,$

• 2. for all $\chi , x, x' \in \{0,1\}^m$ and all non-degenerate $R \in \{0,1\}^{m \times m}$, we have $\textsf {View}_R^H(\chi ,x) \cong \textsf {View}_R^H(\chi ,x').$

In other words, the garbled gate should not leak $\varDelta$ to the evaluator (this is important for arguing that such garbled gates compose to yield a garbling scheme for circuits), and the garbled gates should hide the truth value. Furthermore, this should hold for all ways that the input wire labels could be correlated.

Composition. We now discuss how (free-XOR-compatible) gate-level garbling procedures can be combined to yield a circuit garbling scheme. The details are given in Fig. 3. Roughly speaking, we follow the general approach of Free-XOR garbling, first choosing a global offset $\varDelta$. Recall that for each wire i we associate a wirelabel $W_i$ encoding $\textsc {false}$; $W_i \oplus \varDelta$ will encode $\textsc {true}$. These false wirelabels are chosen uniformly for input wires. Thereafter, we process gates in topological order. Each gate-garbling operation determines the garbled-gate information $\mathbf {G}$ as well as the false wirelabels of the gate’s output wires.

For each wire we choose a random select bit $\sigma _i$ as described above. For each gate, the garbling scheme must provide a way for the evaluator to learn the correct color bits for the output wires. In many practical schemes, the random oracle calls used to evaluate the gate can serve double-duty and also be made to convey the color bits. However, in our case, we aim for complete generality so our scheme manually encrypts the color bits (the $G'$ values in Fig. 3). In more detail, if the evaluator has color bits $\chi$ on the input wires, then she should obtain color bits $\sigma ^{(out)} \oplus \tau (\sigma ^{(in)} \oplus \chi )$ for the output wires, where $\sigma ^{(in)}$ and $\sigma ^{(out)}$ are the select bits for the input/output wires of this gate, respectively. We use the wirelabels encoding truth value $\sigma ^{(in)} \oplus \chi ^{(in)}$ as the key to a one-time encryption that encodes the output color bits.

We point out that these color-ciphertexts are of constant size — $2^m$ of them, each n bits long (e.g., for a traditional boolean gate with fan-in 2, the cost is 4 bits). As mentioned above, in specific cases it may be possible to eliminate the extra random oracle calls used for these color-bit encryptions.

One subtlety we point out is that each call to a gate-level garbling scheme is restriced to a disjoint set of possible random oracle calls — the gth gate is instructed to use $H(g;\cdot )$ as its random oracle. This domain separation is crucially important in arguing that the gate-level security properties are inherited by the circuit-level garbling scheme.

Fig. 3.

Gate-level garbling composed into a circuit garbling scheme.

Lemma 8

Let $\mathbb B$ be a set of boolean functions. Suppose for each $\tau \in \mathbb B$, $(\textsf {GateGb} _\tau , \textsf {GateEv} _\tau )$ is a correct and secure free-XOR-compatible gate garbling scheme for gate functionality $\tau$ (according to Definitions 6 and 7).

Then the garbling scheme in Fig. 3 satisfies the prv, aut, and obv security definitions of [10] in the random oracle model, for circuits expressed in terms of $\mathbb B$-gates.

Proof

(Proof Sketch). We sketch here the proof of prv-security; that is, if $f(x) = f(x')$ then (F, X, d) collectively hide whether they were generated with $X = \textsf {En}(e,x)$ or $X = \textsf {En}(e,x')$. The proofs of the other security properties obv & aut follow using standard modifications.

We show a sequence of hybrids, beginning with an interaction in which (F, X, d) are generated with $X = \textsf {En}(e,x)$. In this initial hybrid, $\textsf {Gb}$ is written in terms of what the garbler sees/knows. The only “persistent” values maintained throughout the main loop are the false wirelabels $W_i$ and select bits $\sigma _i$. We rearrange $\textsf {Gb}$ to instead be in terms of what the evaluator sees: the “visible” wirelabels $W^*$ and their color bits $\chi _i$. We achieve this change by using x to compute the truth value $v_i$ on each wire i. Then we replace all references to $W_i^{v_i}$ with $W_i^*$; references to $W_i^{\overline{v_i}}$ with $W_i^* \oplus \varDelta$; references to $\sigma _i$ with $\chi _i \oplus v_i$. The adversary’s view in this modified hybrid is unchanged.

After this change, each main loop is a Linicrypt program that takes the previously-computed visible wirelabels, along with $\varDelta$, and computes the next garbled gate and output wirelabels (we ignore the encryptions of color bits for now). In fact, such a computation is precisely $\textsf {View}_R(\chi ,v)$ defined above, for some appropriate R that describes the correlations among previous input wirelabels.

The security of the $\textsf {GateGb}$ components (Definition 6) says that $\textsf {View}(\chi ;v)$ and $\textsf {View}(\chi ;v')$ are indistinguishable. But this statement only applies when $\varDelta$ is a local variable to these views, whereas in the garbling scheme $\varDelta$ is shared among all gates. So first we must argue that this shared state is not a problem. To do this, we prove a general composition lemma which shows that, if several programs individually satisfy Definition 6, and they use guaranteed disjoint calls to the random oracle, then their composition also satisfies Definition 6. It is in this composition lemma that we use the fact that the output of each $\textsf {View}$ also hides $\varDelta$. We ensure disjointness of oracle queries by using random oracle $H(g;\cdot )$ when garbling gate g.

We use similar reasoning to handle the color bits, since they are not strictly within the scope of Linicrypt (they use distinct oracle calls and do not leak $\varDelta$). Collectively the entire output given to the adversary’s view hides the truth values $v_i$ which are used to select which $\textsf {View}$ to run. The only other place where the $v_i$ truth values are used is in the computation of the garbled decoding information d. And in this case, $v_i$ are required only for the output wirelabels, which are the same when garbling either x or $x'$. Hence, we can replace x with $x'$ with negligible effect on the adversary’s view, and the proof is complete.

3.2 Synthesis Approach

One of our motivating goals for Linicrypt is the ability to synthesize secure cryptographic constructions. We do precisely that for free-XOR-compatible gate garbling schemes.

We have written a synthesis tool, Linisynth which takes as input the desired parameters of a garbled gate construction. These parameters include:

• The gate functionality $\tau : \{0,1\}^m \rightarrow \{0,1\}^n$

• The arity of the random oracle $\textsf {arity} \in \mathbb {N}$ (e.g., whether the oracle is called with 1 or 2 field elements, etc.)

• The number of oracle queries made by $\textsf {GateGb}$ and $\textsf {GateEv}$: $\textsf {calls}_{\textsf {gb}}, \textsf {calls}_{\textsf {ev}} \in \mathbb {N}$

• The size (in field elements) of the garbled gate information $\textsf {size} \in \mathbb {N}$

• Whether adaptive queries to the oracle are allowed $\textsf {adaptive} \in \{0,1\}$ (see below).

Given such parameters, Linisynth constructs an appropriate SMT formula encoding the required security properties, invokes an SMT solver, and finally interprets the witness (if any) as a human-readable garbled gate construction.

High-Level Outline. Gate garbling schemes as defined in Definitions 6 and 7 are meant to be nonlinear in their use of inputs $\sigma$ and $\chi$. Hence, to synthesize a complete gate-garbling scheme, we must actually synthesize a collection of $\textsf {GateGb} (\sigma ; \cdots )$ and $\textsf {GateEv} (\chi ; \cdots )$ — one for each choice of $\sigma$ and $\chi$ — each of which is a pure Linicrypt program.

We now describe roughly how the gate-garbling search problem is expressed as an existential SAT/SMT formula. Recall that pure Linicrypt programs can be represented algebraically as an output matrix $\mathcal {M}$ and a set of oracle constraints $\mathcal {C}$. When restricted to Free-XOR compatible garbling, the entries in these matrices are single bits. These bits comprise the existentially quantified variables of our SMT formula.

Not every bit in the oracle constraints $\mathcal {C}$ has to be an unconstrained variable. Specifically, if the Linicrypt program in question has k input variables, then we identify these with the first k base variables. This means that the first oracle query made by the program can be a linear combination only of these first k base variables. For the corresponding oracle constraint $\langle t, \mathcal {Q}, \varvec{a} \rangle$, this means that each row of $\mathcal {Q}$ must end in a certain number of zeroes — say, i zeroes. Then we can associate the output of this oracle query with the $(k+1)$th base variable, fixing $\varvec{a}$ to be $[\underbrace{0~\cdots ~0}_k~1~0~\cdots ~0]$. Then the next oracle query can be a linear combination of only the first $k+1$ variables, and so on. Overall, many of the existential variables comprising the oracle constraints can be fixed in this way. Furthermore, we can seamlessly enforce non-adaptive oracle queries by forcing all constraints $\langle t, \mathcal {Q}, \varvec{a} \rangle$ to have $\mathcal {Q}$ depending only on the input variables, and not on further base variables. This is what is referred to by the $\textsf {adaptive}$ parameter.

We then express the requirements of Definitions 6 and 7 as clauses over the variables that comprise the programs themselves. The formula is satisfiable if and only if a secure gate-garbling scheme exists with the given parameters.

Correctness. Correctness (Definition 6) can be expressed in terms of composing $\textsf {View}_R(\chi ,x)$ (which generates input wirelabels along with the garbled gate information) with $\textsf {GateEv} (\chi ,\cdot )$ in a particular way. We can apply the concepts of Sect. 2.4 to reason about their composition.

We make some simplifiying observations that lead us to synthesize only “minimal” gate garbling schemes:

• Correctness needs to hold only for independently distributed input wirelabels ($R=I$). In this setting, the wirelabel inputs to $\textsf {GateEv}$ will have full rank.

• We can assume the garbled gate information has full rank. If any linear dependencies existed, then the same dependencies must exist in $\textsf {GateGb} (\sigma ,\cdot )$ for all $\sigma$, or else security is trivially violated (malicious evaluator can obtain information about $\sigma$ by detecting a linear dependency among garbled gate info). Hence the correlations can be removed from all $\textsf {GateGb} (\sigma ,\cdot )$ and reconstructed if needed in all $\textsf {GateGb} (\chi ,\cdot )$. The result would be a smaller but equivalent & secure scheme.

• The entire input to $\textsf {GateEv}$ (garbled gate information and input wirelabels together) has full rank. If there is a linear dependency between garbled gate information and input wirelabels, then the same dependency must exist regardless of $\sigma$, or else security will be trivially violated. Then again, the dependency could be removed from all $\textsf {GateGb} (\sigma ,\cdot )$ and reconstructed by all $\textsf {GateGb} (\chi ,\cdot )$, resulting in a smaller scheme.

We therefore consider a composition of $\textsf {View}_R(\chi ,x)$ and $\textsf {GateEv} (\chi ,\cdot )$ in which the input to $\textsf {GateEv}$ is of full rank. This simplifies the task, since it now suffices to find a basis change to $\textsf {GateEv}$ that aligns it with the corresponding output of $\textsf {View}_R(\chi ,x)$.

Let $\mathcal {M} _{R,\chi ,x}$ denote the output matrix of $\textsf {View}_R(\chi ,x)$. We split this matrix into a top and bottom: $\mathcal {M} _{R,\chi ,x}^{top}, \mathcal {M} _{R,\chi ,x}^{bot}$, where the top matrix corresponds to the input wirelabels for x along with garbled gate information, while the bottom matrix corresponds to the output wirelabels for the result $\tau (x)$.

Following Sect. 2.4, we seek a basis change B such that $\mathcal {M} _{R,\chi ,x}^{top} = [ I \mid 0] \times B$, which represents the input base variables of $\textsf {GateEv} (\chi ,\cdot )$. The basis change must also bring all oracle constraints between the two programs into alignment. We assume that every oracle query made by $\textsf {GateEv}$ is also made by $\textsf {GateGb}$. This is without loss of generality if we assume that $\textsf {GateEv}$ is “minimal”, since such oracle queries can be removed with no effect (if not, it is easy to see that correctness or security is violated). Hence, we check that for every oracle constraint in $\textsf {GateEv}$, the basis change brings one of the constraints of $\textsf {GateGb}$ into agreement.

Having identified the correct basis change, we simply check that the output matrix of $\textsf {GateEv}$ equals the output matrix $\mathcal {M} _{R,\chi ,x}^{bot}$ (under the basis change). In other words, the wirelabels that $\textsf {GateEv}$ outputs always coincide with the “correct” wirelabels specified by $\textsf {View}_R$.

We also must ensure that B is invertible. To do so we simply guess its inverse $B^{-1}$ and check that $B \times B^{-1}$ is the identity matrix. We point out that multiplication of boolean matrices is straight-forward to express in an SMT formula.

Putting it all together, the clause is as follows. Recall that the input $x = \sigma \oplus \chi$, and that we have restricted $R = I$. We use $(\mathcal {M} _{R,\chi ,x}, \mathcal {C} _{R,\chi ,x})$ to refer to the algebraic representation of $\textsf {View}_R(\chi ,x)$, and use $(\mathcal {M} _{\textsf {GateEv},\chi }, \mathcal {C} _{\textsf {GateEv},\chi })$ to denote the algebraic representation of $\textsf {GateEv} (\chi ,\cdot )$.

$$\begin{aligned} \forall \sigma , \chi \in \{0,1\}^m : \exists B, B^{-1} :&~B \times B^{-1} = I \\&\wedge \big [\forall \langle t, \mathcal {Q}, \varvec{a} \rangle \in \mathcal {C} _{\textsf {GateEv},\chi } : \langle t, \mathcal {Q}\times B, \varvec{a}\times B \rangle \in \mathcal {C} _{R,\chi ,x} \big ] \\&\wedge \mathcal {M} _{\textsf {GateEv},\chi } \times B = \mathcal {M} ^{bot}_{R,\chi ,x} \wedge [ I \mid 0] \times B = \mathcal {M} _{R,\chi ,x}^{top} \end{aligned}$$

We point out that the universal quantifiers are over a constant number of terms ($2^{2m}$ choices of $(\sigma ,\chi )$ and $\textsf {calls}_{\textsf {ev}}$ constraints) and are explicitly expanded in the formula we pass to the SMT solver. Likewise, the test for $\langle t, \mathcal {Q}\times B, \varvec{a}\times B \rangle \in \mathcal {C} _{R,\chi ,x}$ is expressed as a logical-OR of $\textsf {calls}_{\textsf {gb}}$ equality checks.

Security, Condition 1. The first condition of Definition 7 is that $\mathsf {row}(\varDelta )$ is unreachable (in the sense of Fig. 2). If the SAT solver could discover the linear subspace $\mathcal {R}$ of reachable vectors, it could simply test whether this subspace includes $\mathsf {row}(\varDelta )$. However, to do this iteratively as in Fig. 2 is impractical in a SAT formula, so we employ a trick.

Our idea is to guess a basis change B that maps the reachable space to some canonical form that is easily testable by the SAT solver. In particular, consider a basis change B under which the reachable vectors are exactly those that have zero in their rightmost several positions. The SAT formula can easily check for such a condition. To check that our guess for B indeed maps the reachable subspace to the desired canonical form, we observe that the reachable space is characterized by the following properties:

• Every row of the output matrix $\mathcal {M}$ is contained in the reachable space

• For every oracle constraint $\langle t, \mathcal {Q}, \varvec{a} \rangle \in \mathcal {C}$, if every row of $\mathcal {Q}$ is in the reachable space, then so is $\varvec{a}$.

For the reachable space after the basis change, the membership condition is simply that the vector ends in the correct number of zeroes.

We note that from the input parameters, we can compute the dimension of the reachable space (and from that derive the required number of trailing zeroes in the vectors) as $d = m + \textsf {calls}_{\textsf {ev}} + \textsf {size}$, where m is the number of inputs, $\textsf {calls}_{\textsf {ev}}$ is the number of oracle queries allowed the evaluator, and $\textsf {size}$ is the size of the garbled gate information. This assumes that each oracle query of $\textsf {GateEv}$ increases the dimension of the reachable space — an assumption that is without loss of generality for “minimal” schemes since oracle queries not of this kind are superfluous.

Putting everything together, the formula is as follows. We write $(\mathcal {M} _{R,\chi ,x}, \mathcal {C} _{R,\chi ,x})$ to denote the algebraic representation of $\textsf {View}_R(\chi ,x)$, which can be obtained in a systematic way from the algebraic representation of $\textsf {GateGb} (\chi ;\cdot )$ (which comprise the existentially quantified variables of the SAT formula). We use $\mathsf {row}(\varDelta )$ to refer to the appropriate vector in this representation.

(2)

Here $\textsf {RightZeroes}$ simply means that the argument vector/matrix has the appropriate number of zeroes in its rightmost columns. The universal quantifiers are over a constant number of terms ($2^{2m}$ choices of $(\sigma ,\chi )$, $2^{m^2}$ choices of R, and $\textsf {calls}_{\textsf {gb}}$ constraints) and are explicitly expanded in the formula we pass to the SMT solver.

Security, Condition 2. The second condition of Definition 7 is that $\textsf {View}_R(\chi ,x)$ and $\textsf {View}_R(\chi ,x_0)$ are indistinguishable. Here we fix $x_0$ and show indistinguishability with respect to this fixed $\textsf {View}_R(\chi ,x_0)$. Since the programs involved are inputless Linicrypt programs, from Theorem 5 it suffices to show that they differ by a basis change after normalization (unreachable and useless oracle queries removed).

We make an assumption that all reachable oracle constraints in $\textsf {View}_R(\chi ,x)$ are in fact useful, and hence we can only synthesize gate-garbling schemes with this property. However, if a secure scheme has reachable and useless constraints in some $\textsf {View}_R(\chi ,x = \chi \oplus \sigma )$, then the same constraint must be also reachable and useless in all $\textsf {View}_R(\chi ,x' = \chi \oplus \sigma ')$ by security. Hence it can be removed from every $\textsf {GateGb} (\sigma ;\cdot )$ resulting in an even less expensive yet equivalent and secure gate-garbling scheme.

To show that $\textsf {View}_R(\chi ,x)$ and $\textsf {View}_R(\chi ,x_0)$ are indistinguishable, we therefore only need to find a basis change aligning their output matrices and their reachable oracle constraints. Note that from the previous clause, the SAT solver has already obtained a basis B that maps the reachable subspace of $\textsf {View}_R(\chi ,x)$ to a canonical form (vectors ending in some number of zeroes). Hence we can easily check whether a given oracle constraint is reachable. Also note that B is not constrained in how it operates within the reachable subspace. Hence we can let this B basis serve double-duty and ask for it to also align the reachable subspace of $\textsf {View}_R(\chi ,x)$ to that of $\textsf {View}_R(\chi ,x_0)$.

In more detail, let $B_{R,\chi ,x}$ be the basis matrix that is already quantified corresponding to $\textsf {View}_R(\chi ,x)$ from security condition 1. We want $\mathcal {M} _{R,\chi ,x} \times B_{R,\chi ,x}$ and $\mathcal {M} _{R,\chi ,x_0} \times B_{R,\chi ,x_0}$ to coincide, and we want $\mathcal {C} _{R,\chi ,x} B_{R,\chi ,x}$ and $\mathcal {C} _{R,\chi ,x_0} B_{R,\chi ,x_0}$ to coincide, but only for reachable constraints. Hence:

$$\begin{aligned} \mathcal {M} _{R,\chi ,x} \times B_{R,\chi ,x}&= \mathcal {M} _{R,\chi ,x_0} \times B_{R,\chi ,x_0} \wedge {} \\ \Big [\forall \langle t, \mathcal {Q}, \varvec{a} \rangle \in \mathcal {C} _{R,\chi ,x}&: \textsf {RightZeroes}(\mathcal {Q}\times B_{R,\chi ,x}) \\&\Rightarrow \langle t, \mathcal {Q}\times B_{R,\chi ,x} \times B^{-1}_{R,\chi ,x_0}, \varvec{a}\times B_{R,\chi ,x} \times B^{-1}_{R,\chi ,x_0} \rangle \in \mathcal {C} _{R,\chi ,x_0} \Big ] \end{aligned}$$

Note that $\langle t, \mathcal {Q}\times B_{R,\chi ,x} \times B^{-1}_{R,\chi ,x_0}, \varvec{a}\times B_{R,\chi ,x} \times B^{-1}_{R,\chi ,x_0} \rangle \in \mathcal {C} _{R,\chi ,x_0}$ is equivalent to saying $\langle t, \mathcal {Q}B_{R,\chi ,x}, \varvec{a}B_{R,\chi ,x} \rangle \in \mathcal {C} _{R,\chi ,x_0} B_{R,\chi ,x_0}$. Hence the bracketed expression captures the requirement that $\mathcal {C} _{R,\chi ,x} B_{R,\chi ,x}$ and $\mathcal {C} _{R,\chi ,x_0} B_{R,\chi ,x_0}$ coincide for reachable constraints.

As usual, the quantifications over constraints are expanded within the formula.

3.3 Implementation Results

We implemented Linisynth using Python and the SMT solver Z3³. Linisynth extracts the resulting witness and prints it as a human-readable garbling scheme. We used Linisynth to successfully synthesize variants of known gate garbling schemes as well as some of our own creations (i.e., garbled LT gates and garbled EQ gates). Linicrypt can also enumerate constructions that satisfy given parameters. Our code is available at https://github.com/osu-crypto/linisynth.

Linisynth works as follows. For each value in the algebraic representation of $\textsf {GateGb}$ and $\textsf {GateEv}$, it creates a boolean variable. After it has created all the variables, it makes a formula that constrains them in the following way. For each combination of $\sigma$ and $\chi$, the invertiblity, correctness, and security conditions from Sect. 3.2 hold (expressed as boolean formulas over the variables). This often results in rather large formulas (see Fig. 4). Linisynth then hands the formula over to Z3. If Z3 finds a solution, it maps the satisfying assignment back to the garbling scheme and prints it.

Synthesis Results. We rediscovered known constructions. For example, our tool was able to discover that xor gates can be garbled for free. It also rediscovered many garbled and-gate constructions that are equivalent to the half-gates construction of Zahur et al. [53] (costing 2 ciphertexts). An example of such a garbled and-gate is given in Fig. 5. We synthesized garbling schemes for a number of different gates (garbled <, garbled $=$, garbled mux, etc.), but they all had comparable performance to $\textsc {and}$, explained below. A summary is presented in Fig. 4.

Fig. 4.

Selection of our synthesis results on an Intel Xeon 3.4 GHz processor with 16 GB memory. Satisfiable schemes are listed in the full version. Notation: “$f : m \rightarrow n$” is shorthand for a function with m bits of input and n bits of output that performs the operation f on the input, “vars” and “p-size” refer to the number of variables and nodes in the security & correctness formula. “sat” refers to whether the formula was satisfiable.

Fig. 5.

An example of one of our synthesized schemes. This scheme is an alternative to the half-gates $\textsc {and}$ gate of [53], with identical parameters (number of ciphertexts, and number of calls to H). The notation is as follows: $\textsf {GateGb}$: When S is a set of indices, “[S]W” refers to nonlinear behavior “if $\sigma \in S$ then W else $0^\lambda$” $\textsf {GateEv}$: When S is a set of indices, “[S]W” refers to nonlinear behavior “if $\chi \in S$ then W else $0^\lambda$”

We were not able to synthesize a garbling scheme better than 2 ciphertexts per $\textsc {and}$ gate. We suspect that this may be a hard limit (if compatibility with free-XOR is required), in support of the half-gates lower-bound presented in [53]. We formalize that hypothesis here. First, note that $\mathbb {B} = \{\, \textsc {and}, \textsc {not}, \textsc {xor} \,\}$ is a universal basis for boolean circuits. Then take any boolean gate $\tau$ and decompose it into some combination of $\textsc {and}$, $\textsc {not}$, and $\textsc {xor}$. Let $\textsf {circ-min}_{\textsc {and}} (\tau )$ be the minimum number of $\textsc {and}$ gates necessary to construct $\tau$ with basis $\mathbb {B}$. Our hypothesis is this: for all gates $\tau$, the minimum number of ciphertexts to garble $\tau$ with full security and compatibility with free-XOR is $2 \times \textsf {circ-min}_{\textsc {and}} (\tau )$. Verification of this hypothesis is left as future work.

Enumeration of Solutions. Linisynth can also enumerate schemes. Let p be a formula generated according to Sect. 3.2 and let w be a satisfying assignment with $p(w) = 1$. When Linisynth gets w from the solver, it prints the corresponding scheme, sets $p := \lnot w \wedge p$, and asks the solver to find a new solution. Since pysmt provides access to an active instance of Z3, we can use Z3’s push/pop functionality to add an assertion without causing the solver to restart. Each new scheme is found in a fraction of the time it takes to find the first one. Using enumeration, we found thousands of schemes equivalent to half-gates (with parameters $\textsf {size} = 4, \textsf {arity} = 1, \textsf {calls}_{\textsf {gb}} = 4$, $\textsf {calls}_{\textsf {ev}} = 2$, and $\textsf {adaptive} = 0$).