Card-Based Cryptography MeetsFormal Verification★

Alexander Koch, Michael Schrempp, and Michael Kirsten

Karlsruhe Institute of Technology (KIT), Karlsruhe, Germanyalexander.koch@kit.edu, michi.schrempp@freenet.de, kirsten@kit.edu

Abstract. Card-based cryptography provides simple and practicableprotocols for performing secure multi-party computation (MPC) withjust a deck of cards. For the sake of simplicity, this is often done usingcards with only two symbols, e.g., ♣ and ♡. Within this paper, we targetthe setting where all cards carry distinct symbols, catering for use-caseswith commonly available standard decks and a weaker indistinguishabilityassumption. As of yet, the literature provides for only three protocols andno proofs for non-trivial lower bounds on the number of cards. As suchcomplex proofs (handling very large combinatorial state spaces) tendto be involved and error-prone, we propose using formal verification forfinding protocols and proving lower bounds. In this paper, we employ thetechnique of software bounded model checking (SBMC), which reducesthe problem to a bounded state space, which is automatically searchedexhaustively using a SAT solver as a backend.Our contribution is twofold: (a) We identify two protocols for convertingbetween different bit encodings with overlapping bases, and then showthem to be card-minimal. This completes the picture of tight lower boundson the number of cards with respect to runtime behavior and shuffleproperties of conversion protocols. For computing AND, we show that thereis no protocol with finite runtime using four cards with distinguishablesymbols and fixed output encoding, and give a four-card protocol with anexpected finite runtime using only random cuts. (b) We provide a generaltranslation of proofs for lower bounds to a bounded model checkingframework for automatically finding card- and length-minimal protocolsand to give additional confidence in lower bounds. We apply this tovalidate our method and, as an example, confirm our new AND protocolto have a shortest run for protocols using this number of cards.

Keywords: secure multiparty computation · card-based cryptography ·formal verification · bounded model checking · standard decks

1 Introduction

Card-based cryptographic protocols allow to perform secure multi-party com-putation (MPC), i.e., jointly computing a function while not revealing more

★ © IACR 2019. This article is a minor revision of the version published by Springer-Verlag available at doi: 10.1007/978-3-030-34578-5 18.

https://doi.org/10.1007/978-3-030-34578-5_18

information about each individual input than absolutely necessary, with justa (regular) deck of playing cards, as long as they have indistinguishable backs.Let us start with an example. Assume that Alice and Bob meet in a bar andspend the evening together. After quite some chat, they would like to find outwhether to have a second date. They are faced with the following problem: Incase only one of them likes to meet again, this would cause an uncomfortableembarrassment, if he or she is the first to come out.1 Fortunately, Alice is anotable cryptographer and likes card games, so she has with her a standard deckof cards. She remembers the protocol by Niemi and Renvall [NR99] for computingthe AND function of two bits, here for outputting “yes”, if both players sharethis mutual interest, and “no” otherwise. Doing so using an MPC protocol hidesthe input of the respective other player, unless it is obvious from their own inputand output, hence hiding a “yes”-choice given of only one player, from the other.

In order to get a feeling for how such card-based protocols work, let usintroduce the said protocol by Niemi and Renvall. It uses five cards with distin-guishable symbols, which we denote – for simplicity2 – as 1 2 3 4 and 5 . It isessential that the cards’ backs are indistinguishable, such that when they are putface-down on the table, the only thing observable is . With thesecards, the two players can encode a commitment to a bit (yes or no) by the orderof two cards i j , i, j ∈ {1, . . . , 5} (with i ̸= j) via the encoding

i j =̂

{0, if i < j,

1, if i > j.

Alice inputs her bit by putting the cards 1 2 face-down and in the respective

order on the table (she puts 1 2 for input 0, and 2 1 for input 1), while Bob

does the same using his cards 3 4 . We need an additional helper-card, here a

5 , which is put to the left of the players’ cards.The protocol starts by swapping Alice’s second card with Bob’s first card

in the card sequence (pile) on the table. The resulting card configuration hasan interesting property, namely that the order of the cards 1 and 4 in this

sequence already encodes the output of the protocol, i.e., it reads 4 1 if the

output is 1, and 1 4 otherwise. Hence, by securely removing the cards 2 and

3 (which is explained below), one directly obtains the output. We see this byinspecting all possible cases:

Bits Input sequence After swap Removing 2 + 3

(0, 0) 5 1 2 3 4 5 1 3 2 4 5 1 x x 4

(0, 1) 5 1 2 4 3 5 1 4 2 3 5 1 4 x x

(1, 0) 5 2 1 3 4 5 2 3 1 4 5 x x 1 4

(1, 1) 5 2 1 4 3 5 2 4 1 3 5 x 4 1 x

1 This is known as the “dating problem”.2 Alice and Bob in the story might, e.g., use 7, 8, 9, 10 and a queen with any symbol.

2

We can remove the cards 2 and 3 , while keeping the relative order of all cardsin the sequence intact, by cutting the cards, i.e., rotating the sequence by arandom offset which is unknown to the players. We can then securely turn thefirst card and remove it in case it is 2 or 3 . Due to the cut, the turned cardis random, and hence it does not reveal anything about the inputs. When bothcards are removed, we reach a configuration where 5 is the first card by thesame procedure where the two remaining cards encode the AND result. Here,the 5 played the crucial role of a separator that keeps the relative order of theremaining cards, starting from the separator, intact when doing a random cut.(A formal version of this protocol is given in Protocol 2 and Figure 7.)

In this paper, we are interested in whether we can do away with the helpingcard 5 , and whether there are simpler protocols. Moreover, in order to handlethe increasing combinatorial state space (relative to protocols on decks of just ♣and ♡), we introduce formal verification to the field of card-based cryptography.

1.1 Secure Multiparty Computation with Cards

In combining different protocols, one can do much more than just computing theAND function. For example, it is possible to compute arbitrary Boolean circuitsby combining the well-known fact that any circuit can be expressed using onlyNOT and AND gates, with a method to duplicate the physically encoded bit incase of forking wires, which we make explicit by a COPY gate. In the encodingabove, NOT simply inverts the order of the two cards, and a COPY-protocol isgiven, e.g., in [M16]. Using this setup, we can do general MPC for any functionwithout needing to trust a possibly corrupted computer.

A particular advantage of protocols using physical assumptions is that theycan provide a bridge to reality. Examples of this are given in [GBG14; FFN14],where the authors give a protocol for proving in zero-knowledge that a nuclearwarhead (to be disarmed due to an international treaty) conforms to a prescribedtemplate, without giving away anything about its internal design. In our settingof cryptography with cards, this bridge is used if the cryptographic protocol isembedded in a real card game, e.g., to prevent cheating3. Here, using computersis not only cumbersome, but there is no guarantee that the card sequence on myhand is the one I input into the software, hence no bridge to the physical world.

Another application of such protocols is to explain MPC in an interesting andmotivating way to students in cryptography lectures. Card-based cryptographytries to find protocols for the above-mentioned AND and COPY functionalitieswhich are card-minimal, simple and practicable. For simplicity, many protocolsin card-based cryptography work with specially constructed decks, e.g., of onlytwo symbols, ♣ and ♡. This is easy for explanation, and there are nice and easilydescribable protocols, such as the five-card trick by den Boer [dB89] and thesix-card AND protocol by Mizuki and Sone [MS09].

3 As an example, in a Duplicate Bridge tournament, one might prove that all sessionsare handed the same cards, eliminating the need of a trusted dealer (no pun intended).

3

However, the setting where all cards are distinguishable, as described above,has several advantages. Firstly, we assume little about the indistinguishabilityof cards, which leads to stronger security guarantees. (This is more similar tothe indistinguishable version of tamper-evident seals, such as scratch-off cards,by Moran and Naor [MN10].) We only need the backs (or envelopes wrappingthe cards, if one wishes) to be indistinguishable. Secondly, these standard decksare more commonly available, in contrast to constructed decks. If one were touse standard decks for the protocols above, they would need multiple copies ofthe same card. Thirdly, considering this setting may lead to protocols using lesscards than the optimal ones in the two-symbol deck setting. In fact, as our papershows, one may use less cards than in the two-symbol deck setting. For example,our new four-card Las Vegas AND protocol presented in Section 5 uses only avery basic, practicable shuffling mechanism, namely random cuts, and uses onecard less than the provably card-minimal Las Vegas AND protocol (restrictedto certain types of practical shuffles) in the two-symbol deck setting. As of yet,there has only been little research in this direction, with [NR99; M16] being theonly works that consider the setting where all cards have distinguishable symbols,called “standard deck” setting. Nothing is known about non-trivial lower boundson the number of cards. This is likely due to the large state space, as there aremany more distinguishable card re-orderings compared to the two-symbol case.

Within this paper, our interest is to find an automatic way of constructingcompact card-based protocols which are secure and correct, based on only thetwo standard operations turn and shuffle, given the desired number of cards.We exploit the observation that, to the best of our knowledge, all findings inthe literature employ only protocols of comparatively small length using only asmall number of cards. Based on the hypothesis that we may always find somenumber n which is greater than or equal to any length-minimal card-protocol, weapply the automatic off-the-shelf formal program-verification technique softwarebounded model checking (SBMC) [BCC+99]. This technique allows, given sucha bound n, to encode a program verification task into a decidable set of logicalequations, which can then be solved by a SAT or an SMT solver. In this work, wepropose an automatic method based on SBMC that, given the desired numbersof cards and protocol length, either constructs such a protocol if and only if oneexists, or proves the underlying SAT formula to be unsatisfiable, i.e., shows thatno such protocol exists. Based thereon, we propose that the cumbersome anderror-prone task of finding such protocols or proving their non-existence by handmay be supported or complemented by such an automatic approach which isflexibly adaptable to a variety of card-based protocols and desired restrictions.

Prior to our work, it was not yet clear which role the input encoding playswhen devising new protocols. This is the question on whether it can make adifference regarding the possibility of a protocol if we provide, e.g., 1 2 to Alice

and 3 4 to Bob, or 1 3 to Alice and 2 4 to Bob. We provide an analysis ofthis question, showing that with certain restrictions, there is a relatively largefreedom in choosing the input (and/or output) bases. This is a useful prerequisitein proving the impossibility of a protocol with a given number of cards.

4

1.2 Contribution

Our contribution consists in providing interesting new protocols and impossibilityresults, as well as a fully automatic method based on formal verification tosupport such findings. The specific advances therein are the following (cf. alsoTable 1 for a comparison to the literature):

(1) A four-card AND protocol in the standard deck setting, improving upon[NR99] by one card, and reaching the theoretical minimum on the numberof cards. W.r.t. shuffling, this protocol only uses an expected number of 6random cuts, compared to 7.5 random cuts in a (shortened) variant of [NR99].Additionally, it has a natural interpretation and using only random cutsmakes it particularly easy to implement in an actively secure way, cf. [KW17].

(2) We show that under certain conditions the cards for encoding input or outputcan be chosen freely. For one-bit output protocols and if five or more cardsare available, we can freely choose both input and output bases by onlyextending the protocol by expected three shuffle and three turn steps. Forthis matter, we identify two protocols for converting a bit encoding if thenew encoding shares one card with the old one.

(3) We show that there is no finite-runtime protocol for converting between baseswith non-empty intersection using four cards. Moreover, there cannot be afinite-runtime AND protocol with four cards if we fix the basis in advance.

(4) We introduce formal verification to card-based cryptography by providing atechnique which automatically finds new protocols using as few as possibleoperations and searches for lowest bounds on card-minimal protocols.

Table 1. Minimum number of cards required by AND and basis conversion protocols,subject to the running time and shuffle restrictions specified in the first two columns.Note that random cuts are a subclass of uniform closed shuffles.

Running Time Shuffle Restr. #Cards Protocol Lower Bound

AND Protocols:

Las Vegas random cuts 4 Theorem 3 – (trivial)finite – }≥ 5a,≤ 8 [M16, Sect. 3.4] Theorem 2finite uniform closed

Disjoint Basis Convert Protocols:

finite uniform closed 4 [M16, Sect. 3.2] – (trivial)

Overlapping Basis Convert Protocols:

Las Vegas random cuts 3 Theorem 4 – (trivial)finite – }

5 Theorem 5 Theorem 1finite uniform closeda Lower bound result only holds for fixed output basis, flexible case is still open.

5

1.3 Related Work

The feasibility of card-based cryptographic MPC is due to [dB89; CK93; NR98],with a formal model given by [MS14]. The only two papers looking at standarddeck solutions are [NR99; M16]. Lower bounds on card-based cryptographicprotocols are given by [KWH15; KKW+17; K18] for the two-symbol deck setting.The card-minimal protocol for this setting, using only practicable (i.e., uniformclosed) shuffles, is given by [AHM+18] and uses five cards. The state trees usedfor protocols in this paper are devised by [KWH15; KKW+17].

To the best of our knowledge, this is the first work which applies formalmethods to the field of card-based cryptography. However, a large range of researchhas been done using formal methods in the more general field of secure two-partyand multiparty computations. This can be clustered into either analyzing securityprotocols given as high-level, abstract (and usually idealized) models, or program-based approaches targeting real(istic) protocol (software) implementations. Avalle,Pironti, and Sisto [APS14] further structure this into the two main approachesof automated model extraction and automated code generation. We refer theinterested reader to overviews as given by Blanchet [B12] or Avalle, Pironti, andSisto, and only go into a few selected works for which we identified closer links toour approach, e.g., using software bounded model checking (SBMC), SAT solverson real(istic) protocol implementations, or relating in the analyzed securitymodel. Standard cryptographic assumptions using lower-level computationalmodels are – albeit more realistic – usually harder to formalize and automate.One notable line of research is CBMC-GC [FHK+14] which builds on top of thetool CBMC [CKL04]. It uses SBMC in a compiler framework translating securecomputations of ANSI C programs into an optimized Boolean circuit which cansubsequently be implemented securely utilizing the garbled circuit approach.Another similar setting to ours is analyzed in [RSH19], where also an “honest-but-curious” attacker model is assumed. Therein, a domain-specific language isbuilt on top of the F★ language, a full-featured, verification-oriented, effectfulprogramming language [SHK+16]. Swamy et al. then implement MPC programswith enabled formal verification provided by the semantics of the language.

1.4 Outline

We give the computational model of card-based protocols, security definitions, etc.and the necessary preliminaries as well as a basic setup for software bounded modelchecking in Section 2. Section 3 discusses which freedom one has when choosingthe specific cards for encoding inputs and outputs to card-based protocols andintroduces a formal relabeling operation. We give lower bounds on the numberof cards for AND and basis-conversion protocols in Section 4. A four-card LasVegas AND protocol and two basis-conversion protocols are presented in Section 5and Section 6, respectively. Section 7 gives results from applying our formalverification setup based on SBMC to our new AND protocol.

6

2 Preliminaries

In this section, we first formally introduce card-based protocols with their com-putational model (including some basic required notions), a convenient formalprotocol representation, a suitable security notion, and the formal requirementsfor proving lower bounds. Secondly, we introduce our applied formal techniquecalled software bounded model checking, on which, thirdly, we establish ourgeneral technique for automatically finding card- and length-minimal protocols.

2.1 Card-Based Protocols

Formally, a deck D of cards is a multiset over a (deck) alphabet or symbol setΣ. We denote multisets by ⟦·⟧, e.g., ⟦♡,♡,♣,♣⟧ is a deck over {♡,♣}. In thispaper, we focus mainly on decks D = ⟦1, . . . , n⟧, n ∈ N, where each symbol occursexactly once. Following [M16], we call these decks standard decks, because decksof common card games are a good representation of such formal decks.

For encoding a bit, we additionally assume a linear order on the card symbolsin Σ, which is the usual order on N for standard decks, and ♣ < ♡ for simpletwo-element decks. Two face-down cards with distinct symbols s1, s2 ∈ Σ thenencode a bit via the following encoding rule introduced in [NR99]:

s1 s2 =̂

{0, if s1 < s2,

1, if s1 > s2.

Card-based protocols proceed by mainly two actions on the sequence or pile ofcards: We can introduce uncertainty (about which card is which) by shufflingthem in arbitrary or in certain controlled ways, e.g., by cutting the cards inquick succession, so that players do not know which card ended up where in thecard sequence (or pile). Slightly more formal, a (uniform) shuffle is specified bya permutation set, from which one element is drawn uniformly at random andapplied to the cards, without the players learning which one it was. Secondly, wemay turn over cards and publicly learn their symbol, and act on the basis of thisinformation. Moreover, we may deterministically permute the cards.

Permutations and Groups. Let Sn denote the symmetric group on {1, . . . , n}.For elements x1, . . . , xk ∈ {1, . . . , n} the cycle (x1 x2 . . . xk) is the cyclicpermutation π with π(xi) = xi+1 for 1 ≤ i < k, π(xk) = x1 and π(x) = x for allx not occurring in the cycle. Every permutation can be written as a compositionof pairwise disjoint cycles. For example, (1 3 2)(4 5) maps 1 ↦→ 3, 3 ↦→ 2, 2 ↦→1, 4 ↦→ 5, and 5 ↦→ 4. The identity permutation is denoted as id.

Given permutations π1, . . . , πk ∈ Sn, ⟨π1, . . . , πk⟩ denotes the group generatedby π1, . . . , πk. A shuffle is a random cut if its permutation set is the group ⟨π⟩ ={π0, . . . , πl−1} generated by a single element π which is a cycle (x1 x2 . . . xl).A shuffle is called a random bisection cut if its permutation set is generatedby a π which is the composition of pairwise disjoint cycles of length 2. Finally,an Sk-shuffle is a shuffle with permutation set Sk.

7

1234 X00 +X011243 X102134 X11

1234 1/2(X00 +X01 +X10)1243 1/2(X00 +X01 +X10)2134 1/2X112143 1/2X11

(shuffle, {id, (3 4)})

s1 µ(s1)...

...sℓ µ(sℓ)

s′1 1/|Π|∑

π∈Π µ(π−1(s′1))

......

s′k 1/|Π|∑

π∈Π µ(π−1(s′k))

(shuffle,Π)

Fig. 1. A shuffle operation, given by example (left), and via the general rule (right).

Computational Model and Protocol Tree Representation. For our formaldescriptions, we make heavy use of the KWH trees introduced in [KWH15] andshown to be equivalent to the computational model of [MS14; MS17] in [KKW+17].We start by the start node

12 34 X0012 43 X0121 34 X1021 43 X11

and add eventually needed further cards ( 5 , 6 , . . . ) to the right of the playersbits. The state (or KWH) tree is directed, with annotations at the outgoing edgesof the state, specifying the action that is performed next. Let µ be the state withthe outgoing annotation, then the actions are defined as:

1. (shuffle, Π) leads to a µ′ as in Figure 1, where Π ⊆ S|D| is a permutation set.2. (turn, T ) branches the tree into states µv for each observation v possible by

revealing the cards at positions from the set T ⊆ {1, . . . , |D|}, as in Figure 2.µv contains the sequences from µ which are compatible with the observationv. For each sequence s compatible with v, we have µv(s) := µ(s)/Pr[v], wherePr[v] ∈ (0, 1] is the probability of observing v.

3. (perm, π) permutes the sequences of µ according to π.4. (result, p1, p2) stops the computation and returns the cards at p1, p2 as output.

We start by a state that encodes the input sequences attached to theirrespective symbolic input probabilities, see [KKW+17] for a thorough explanation:

12 34 X0012 43 X0121 34 X1021 43 X11

A protocol computes a Boolean function f : {0, 1}2 → {0, 1} if the start state(tree root) encodes each b ∈ {0, 1}2 in the first four cards (the remaining cardsbeing at fixed positions), and in the leaf nodes of the protocol’s state tree, it holds

8

s1 µ(s1)...

...sℓ µ(sℓ)

s1,1 1/Pr[v1] · µ(s1,1)...

...s1,ℓ1 1/Pr[v1] · µ(s1,ℓ1)

sn,1 1/Pr[vn] · µ(sn,1)...

...sn,ℓn 1/Pr[vn] · µ(sn,ℓn)

(turn, T )v1 vn. . .

Fig. 2. A turn operation. Here, v1, . . . , vn, are the possible observation by turning thecards at positions in T . For each i ∈ {1, . . . , n} the si,1, . . . , si,ℓi are the sequences froms1, . . . , sℓ which are compatible with vi. Note that in secure protocols, the probabilityof observing vi, denoted as Pr[vi], is constant.

for the positions given by the result operation that the cards at these positionsencode a value o ∈ {0, 1} if all Xi occurring in µ(s) for sequence s satisfy f(i) = o(Correctness). We say that a protocol has finite runtime if its tree is finite. It isa Las Vegas protocol, if it is not finite runtime, but the expected length of anypath in its tree is finite. Note that while we consider looping protocols, we do notconsider the case where a complete restart is necessary. For self-similar infinitetrees, we simplify by drawing edges to earlier states.

Security of Card-Based Protocols. We slightly adjust the security notionfrom the literature to standard decks. For more details, we refer to [K19]. Sincedifferent encodings for the same bit are possible, we want the encoding basisof the output bit to not give away anything about the inputs. We say that aprotocol is secure if at any turn operation the probability for each observation vis a constant ρ ∈ [0, 1] (using ∑i∈{0,1}2 Xi = 1), and additionally if at any resultoperation the probability of each output basis is constant in the same sense.

As in [KKW+17], for our impossibility proofs and formalizations with boundedmodel checkers, it is useful to consider a weaker form of security, which is anecessary criterion for security as defined above: A protocol is possibilisticallyoutput-secure, if at any state of the protocol, every output can still be possible.This weakens the normal security guarantee, as the probability for a given inputsequence could be higher in this state. One could even be able to exclude aspecific input sequence, if the corresponding output can still be possible throughanother input sequence. Together with possibilistic input-security, this discussionleads to the following formal definition:

Definition 1 (cf. [KKW+17]). A protocol P = (D, U,Q,A) computing afunction f : {0, 1}2 → {0, 1} has possibilistic input security (possibilistic outputsecurity) if it is correct, i.e., output O = f(I) almost surely and for uniformly4

4 Actually, the distribution does not matter, as long as Pr[I = i] > 0 for all i ∈ {0, 1}k.

9

random input I and any visible sequence trace v with Pr[v] > 0 as well as any inputi ∈ {0, 1}2 (any output o ∈ {0, 1}) we have Pr[v |I = i] > 0 (Pr[v |f(I) = o]).

Proving Lower Bounds. We call two states, µ and µ′, similar, if µ is equal toµ′ up to row or column permutation. This is an interesting equivalence relationfor reducing the state space and we make use of it in our impossibility results.

As in [KKW+17, Definition 3], we define reduced states, where states are notannotated by their symbolic probabilities, but by the result that is specified bytheir inputs. This simplifies impossibility proofs by reducing information andthe state space. Any such reduced tree captures only a weak form of security,possibilistic security, as discussed above where each output (reachable in principle)needs to be still possible. Showing that a protocol is impossible even in this weaksetting implies its general impossibility.

To obtain a reduced state tree, we project all the symbolic probabilitiesof the sequences in a state tree to a type (representing the possible futureoutput associated with the sequence in a correct protocol, see below), whichcan be any o ∈ {0, 1}. For this, let P be a protocol computing a functionf : {0, 1}2 → {0, 1} and µ be a state in the state tree. For any sequence s withµ(s) being a polynomial with positive coefficients for the variables Xb1 , . . . , Xbi(i ≥ 1), set µ̂(s) := o ∈ {0, 1} if o = f(b1) = f(b2) = . . . = f(bi) in the resultingreduced state µ̂. We call sequences in µ̂ according to their type o-sequences.

For proving impossibility results, we make use of the backwards calculus asgiven in [K18]. We highlight the main ideas here, but refer to it for reference.Denote by shuf−1(G), for a set of states G, the set of states that are transformedinto a state in G by a shuffle. The trivial shuffle is allowed, i.e., G ⊆ shuf−1(G).Moreover, turn−1f (G) is the set of states being in G or having a turnable positioni such that all immediate successor states from a turn at i are in G. Define byclf(G) the closure of turn−1f (·) and shuf−1(·) operations on G. We call turn−1f (·)and shuf−1(·) backwards turn and backwards shuffle. Hence, it holds that if thestart state is not in clf(G), then no finite-runtime protocol can exist.

2.2 Automatic Formal Verification Using SBMC

In the following, we introduce an automatic technique from formal programverification, namely software bounded model checking (SBMC), to the field ofcard-based cryptography. We first describe the general technique of using SBMCto check for software properties, before we explain how we apply it to searchfor cryptographically secure card-based protocols. In a nutshell, we translatethe task to a reachability problem in software programs (which will later-on bea program encoding operations on an abstract state tree as described above),which the SBMC tool encodes into an instance of the SAT problem.

We assume we are given an imperatively defined function f under the form ofan imperative program (for example, written in the C language), that uses someparameter values taken among a set of possible start values I. An entry i ∈ I is alist of values, one value for each such parameter: it gives a value to everything that

10

a run of f depends on, such as its input variables, or anything that is considerednon-deterministic (i.e., of arbitrary, but fixed, value for any concrete evaluationof f) from the point of view of f . For this reason, those parameters are qualifiedas “non-deterministic”, to distinguish them from normal parameters used in aprogramming language to pass information around. Moreover, some values canbe “derived”, thus, computed in f from the non-deterministic parameter values,or declared as constants in f , and both values of non-deterministic parametersor derived values can then be used as normal parameters in the program. We arealso given a software property to be checked about f , in the form Cant ⇒ Ccons,where ant and cons stand for antecedent and consequence respectively. Both Cant

and Ccons are sets of Boolean statements. A Boolean statement is a statement off that evaluates to a Boolean value, for example, a simple statement checkingthat some computed intermediate value is positive. An entry i is said to satisfya set of Boolean statements if and only if all Boolean statements in the setevaluate to true during the execution of f using the non-deterministic parametervalues i, and is said to fail the set of Boolean statements otherwise. The propertyCant ⇒ Ccons requires that for all possible entries i ∈ I, if i satisfies Cant, theni satisfies Ccons. As an example, assume f computes, given i, two intermediateinteger values v1 and v2, and then returns a third value v3. The property to bechecked could, e.g., be: if v1 is negative, then v2 is positive and v3 is odd. Asolver that is asked to check a software property Cant ⇒ Ccons thus exhaustivelysearches for an entry i that satisfies Cant but fails Ccons. The property is valid ifand only if there does not exist any such entry i, i.e., it is impossible to find.

SBMC is a fully-automatic static program analysis technique used to verifywhether such a software property is valid, given a function and a property to bechecked. It covers all possible inputs within a specified bound. It is static in thesense that programs are analyzed without executing them on concrete values orconsidering any side channels. Instead, programs are symbolically executed andexhaustively checked for errors up to a certain bound, restricting the numberof loop iterations to limit runs through the program to a bounded length. Thisis done by unrolling the control flow graph of the program and translating itinto a formula in a decidable logic that is satisfiable if and only if a program runexists which satisfies Cant and fails Ccons. The variables in the formula are thenon-deterministic parameters of f , and their possible values are taken from I.

This reduces the problem to a decidable satisfiability problem. Modern SAT-solving technology can then be used to verify whether such a program run exists,in which case an erroneous input has been found, and the run is presented tothe user. If the solver cannot find such a program run, it may be either becausethe property is valid, or because it is invalid only for some run which exceedsthe bound. In some cases, SBMC is also able to infer statically which bound issufficient to bring a definitive conclusion.

2.3 Automatic Formal Verification for Card-Based Protocols

Our approach employs a standardized program representation of the KWH treesintroduced in [KWH15] (and described in the beginning of this section). This

11

allows a general programmatic encoding of both shuffle and turn operations, aswell as of the fixed input state (indicated by the input card sequences from thetable in the very beginning of this paper), the non-deterministic reachable states,and the logical function to be computed securely.

The input state is trivially derived from the specified numbers of cards asthe size and order of the players’ commitments is fixed and the (without loss ofgenerality) consecutively ordered card sequence of (distinguishable) helper-cardsis simply prepended to the input card sequence, annotated with their respectiveinput probabilities. Any input state thus consists of exactly four distinguishablecard sequences. Based on this input state, the program performs a loop, whichsuccessively performs turn or shuffle operations based on the input state andcomputes the resulting states from which it continues performing turn or shuffleoperations. The loop ends when the specified bound (representing the length ofthe protocol to be found) is reached, checks whether the final state is indeeda valid computation of the secure function, and (if and only if the check issuccessful) the found protocol is then presented to the user.

However, this task involves multiple computational complexities, most notablyboth the number of (possibly) reachable states, and the choice of the nextoperation, i.e., either choosing the card(s) to be turned or which shuffle to perform.We partially overcome the first computational complexity by not considering LasVegas protocols as this relieves us from checking every reachable sequence of statesto be finite. In fact, we compute all reachable states after every protocol operation,but only check each of them to be valid, and then proceed our operationson only one of them, which is non-deterministically chosen among them. Thesecond computational complexity consists in first non-deterministically choosingwhether to shuffle or to turn, and then to perform the respective operation. Theturn operation is less interesting as it is mostly the obvious implementationfor updating the computed state and its probabilities using mostly standardimperative program operations, except that the turn observations are againnon-deterministically chosen, hence making the SBMC tool consider any of themto be possible. The more interesting operation is the shuffle operation, as it mustrandomly draw a set of permutations on which the thereby reachable statesare computed. We implement this by non-deterministically choosing a set ofpermutations from a precomputed set of all generally possible permutations.Both the amount5 and the choices of the respective permutations are chosen non-deterministically. Moreover, we restrict our experiments to only closed shufflesand proceed by restricting the computed set of permutations to be either closedor of size one (i.e., a simple permutation).

Finally, after iterating the afore-mentioned loop for the specified bound numberwith the described operations and restricting that final state indeed computesthe secure function, we specify the software property Ccons to be checked simplyas the Boolean value false. This trivially unsatisfiable property implies thatthe verification task always fails once there exist input and non-deterministic

5 In order to keep the execution times still manageable for our experiments, we boundthis amount by the (arguably quite reasonable) number 8.

12

parameters such that the respective program run reaches the statement in theprogram which checks this property. The SBMC tool exhaustively searches for arun of the specified length through the program which leads from the startingstate to a correct and secure state which satisfies the given security notion, i.e.,reaches the above-metioned statement. Hence, if there exists any protocol of thespecified length which computes the secure function and for which the specifiedoperations and valid intermediate states (representing KWH-trees) exist, sucha protocol is presented by our method. If no such protocol can be found, weknow there is no card-based protocol of the specified length satisfying all ourrestrictions on permitted turn and shuffle operations, as well as intermediate andfinal states. This means there exists no model for the SAT formula which encodesthe set of all permitted program runs given our specified requirements.

Hence, assuming our translation of KWH trees and respective protocol op-erations into a simple imperative program are correct, this method can thenbe used in an iterative manner to strengthen the bounds from the literature.Note that this is largely based on the so-called “small-scope hypothesis”, i.e., alarge number of bugs are already exposed for small program runs. We apply thishypothesis to the setting of card-based security protocols as all protocols in theliterature only use a small number of turn and shuffle operations and the lengthof any found protocol is below ten operations.

This approach can be generalized to search for card-based protocols using apre-defined number of actions and adhering to a given formal security notion.We have written a general program6 to search for such situations parameterizedin the desired restrictions on actions and security notions. Note that, in orderto cope with the still considerable state space size, we use the refined securitynotion of output-possibilistic security.

3 On the Choice of Cards for Input and Output

We essentially show that the choice of input basis (or output basis, but notnecessarily both) is irrelevant for the functioning of the protocol. In rare cases,one has to append two operations to existing protocols to make them fully basisflexible. In the Niemi–Renvall protocol shown above, the protocol descriptionspecifies Alice’s cards to be of symbols 1, 2, and Bob’s to be of symbols 3, 4and the helping card to be a 5. To simplify later proofs and to demonstratean interesting symmetry in card-based protocols, we show that this choice isirrelevant for the functioning of the protocol.

For this, we define a relabeling from deck alphabet Σ to a deck alphabet Σ′, i.e.,a bijective function λ : Σ → Σ′.7 A relabeling of a sequence s = (s1, . . . , sn) is arelabeling of each of its symbols, i.e., λ(s) := (λ(s1), . . . , λ(sn)). A relabeling of astate is given by the relabeling of all its sequences, a relabeling of a protocol/state(sub)tree is the relabeling of all its states as described by Figures 3 and 5.

6 The source code is available under https://github.com/mi-ki/cardCryptoVerification.7 In case of the decks being a subset of N, we may use usual permutation notation. Werequire that if λ maps x to y, that the cardinalities of x and y are equal in the deck.

13

https://github.com/mi-ki/cardCryptoVerification

...

1324 X02134 X01342 X12143 X1

3123 X04312 X03124 X14321 X1

relabel : (1 3)(2 4)

3142 X03124 X1

4312 X04321 X1

(turn, {1, 2})31?? 43??

(result, 4, 3)

✓(result, 3, 4)

✓

...

1324 X02134 X01342 X12143 X1

1324 X01342 X1

2134 X02143 X1

(turn, {1, 2})13?? 21??

(result, 3, 4)

✓(result, 3, 4)

✓

Fig. 3. Example of the relabel action, swapping the card symbols of 1 and 3, and of2 and 4, respectively. This action is for abbreviated writing only, it does not actuallyrelabel the physical cards, which seems impossible without learning their symbols.Hence, the tree on the left is virtually translated to the right. Note that the relabelingonly affects the sequences, the observations at edges belonging to turn actions and mayswap the order of the indices in result operations.

Lemma 1. If P is a protocol with deterministic output basis, one can relabelthe cards without affecting the functioning.

Note that the deterministic output basis restriction is important, because ifwe have a randomized output encoding such as in Figure 4 on the left, a relabelingmight affect the monotonicity of the encoding of only one of the possible outputbases. In this case, we make use of the following lemma, as illustrated Figure 4.

Lemma 2. Every protocol with one-bit output and a randomized output basiscan be transformed into a protocol with deterministic output basis, by inserting ashuffle and a turn before any result operation with randomized output basis.

4 Impossibility of Finite-Runtime Four-Card AND andBasis Conversion with Overlapping Bases

In this section we give our main impossibility results.

Theorem 1. There is no four-card finite-runtime basis conversion protocol foroverlapping bases with deck D = ⟦1, 2, 3, 4⟧.

Proof. We proceed by using the backwards calculus technique from [K18], asdescribed in Section 2.1. That is, we start with the set of final states G of basis

14

...

43 21 1/2X121 34 1/2X134 12 1/2X012 34 1/2X0

(result, 1, 2)

✓

...

43 21 1/2X121 34 1/2X134 12 1/2X012 34 1/2X0

43 12 1/4X143 21 1/4X121 34 1/4X121 43 1/4X134 12 1/4X034 21 1/4X012 34 1/4X012 43 1/4X0

(shuffle, ⟨(3 4)⟩), i.e. shufflearbitrary on remaining cards

43 12 X134 12 X0

43 21 X134 21 X0

21 34 X112 34 X0

21 43 X112 43 X0

(turn, {3, 4})??12

??21 ??34??43

(result, 1, 2)

✓(result, 1, 2)

✓(result, 1, 2)

✓(result, 1, 2)

✓

Fig. 4. Example of making the basis deterministic, cf. Lemma 2. On the left you see atree part with one-bit output and randomized basis, i.e., the output basis may be {1, 2}or {3, 4}, each with a probability of 1/2. We can make it known to the players, i.e.,deterministic, by splitting up the state via an Sk-shuffle (here: k = 2) on the remainingcards (so that they no longer contain any information), turning these and then doingthe result operation. By what is visible in the turn, one can derive the output basis.

conversion protocols. Then, we iteratively build a (possibly) larger set by addingstates which reach the states of the current set by a shuffle or a turn, in order toobtain the closure clf(G). As we consider only reduced states (cf. Section 2.1), theset of possible states is finite, hence, applying turn−1f (·) and shuf−1(·) operationsto the (growing) set of states, starting from G, will become stationary. Finally, itremains to be shown that the start state is not contained in the derived closure.

We assume w.l.o.g. the input basis {1, 2} with helping cards 3 and 4, and theoutput basis {o1 < o2} ⊂ {1, 2, 3, 4}. For the basis conversion impossibility, wewill require |{1, 2} ∩ {o1, o2}| = 1 (which we call basis intersection requirementin the following). However, whether we use this requirement or not, the closureclf(G) remains the same8. Hence, we will use this requirement only in the laststep of the proof when we show that the start state is not in clf(G), and reusethe closure for the AND protocol impossibility proof in Theorem 2.

8 This is the (reduced-state) closure on the final states of arbitrary one-bit-outputfunctions for the given deck.

15

s1 µ(s1)...

...sℓ µ(sℓ)

λ(s1) µ(s1)...

...λ(sℓ) µ(sℓ)

relabel : λ : Σ → Σ′

(result, τ(i), τ(j)),with τ ∈ {id, (i j)}

✓

s1 µ(s1)...

...sℓ µ(sℓ)

(result, i, j)

✓

Fig. 5. The formal rule for relabeling leaf nodes of one-bit output protocols. Letr1 = sk[i], r2 = sk[j] ∈ D be the output symbols (before relabeling) of some arbitrarysequence sk of µ. Then, τ = id, if r1 < r2 implies λ(r1) < λ(r2) (λ is monotone on r1,r2) and τ = (i j) otherwise.

After setting the stage, we start by describing the set G0 from which wewill derive the closure clf(G0) according to the backwards calculus techniquedescribed above. Let o3 < o4 be the remaining two symbols, i.e., {o3, o4} ={1, 2, 3, 4} \ {o1, o2}. Thus, the final state is, up to similarity, any choice of atleast one 1-sequence and one 0-sequence of the state on the left9:

o1o2 o3o4 0o1o2 o4o3 0o2o1 o3o4 1o2o1 o4o3 1

o3o4 o1o2 0o3o4 o2o1 0o4o3 o1o2 1o4o3 o2o1 1

The state on the right is the template (up to similarity) for final states withoutput basis {o3 < o4}, which we will include in the starting set G0, as they arereachable from final states with output basis {o1, o2} by the backwards calculusanyway, due to the existence of the disjoint basis conversion protocol from [M16](again, with any choice of at least one 1- and one 0-sequence). As long as we canstill show that the start state is not in clf(G0), it is okay to enlarge G0, since ourclaim is only made stronger (using the monotonicity property of the backwardsoperations turn−1f (·) and shuf−1(·)).

We have shuf−1(G0) = G0, because any subset of a state from G0 whichcontains at least one 1-sequence and one 0-sequence (which is required as otherwise1-/0-sequences cannot be generated out of thin air by a shuffle) is already inG0. Hence, we consider G1 := turn−1f (G0), i.e., the states which are turnableat a position i, where all immediate child nodes after turning at i are in G0.W.l.o.g. we fix the turn to be at position 4. By [K18, Lemma 3], we use that

9 with the output being encoded in positions 1, 2.

16

G1 = turn−1f (G0) = G0 ∪ turn−1f (cc(G0)) holds, where cc(G0) is the set of states inG0 that have a constant column, i.e., up to similarity:

o1o2 o3o4 0o2o1 o3o4 1

o1o2 o4o3 0o2o1 o4o3 1

o3o4 o1o2 0o4o3 o1o2 1

o3o4 o2o1 0o4o3 o2o1 1

The states from G1 \ G0 look as follows:

. . . a 0

. . . a 1

. . . b 0

. . . b 1

. . . c 0

. . . c 1

. . . d 0

. . . d 1, (∗)

where at least two of the four (two-sequence) blocks are present, and a, b, c, d ∈ Dare pairwise distinct. We show that a further backwards turn does not enlargethe set by showing cc(G1) = cc(G0). For this, note that the states from cc(G0)(i.e., the blocks, considered in isolation) have exactly two constant columns, butwith the specific pairing that if one of the constant columns consists of o1, theother one consists of o2 and vice versa, or if one consists of o3, the other oneconsists of o4 and vice versa.

Using this structure, we can deduce that states from G1 \ G0 with a constantcolumn, say w.l.o.g. at position 3, have the respective paired symbol (of the o1-o2or o3-o4 constant-column symbol pairing) in the fourth column. Therefore

10,these states can have at most two sequences in total, i.e., they are already in G0.This shows turn−1f (G1) = G1.

Now, for the main step of the proof, we define G2 := shuf−1(G1) and G3 :=turn−1f (G2). Since the shuffling is unrestricted, applying another backwards shuffleto G2 cannot produce a larger set, as we can always replace two consecutiveshuffles by an equivalent single shuffle. The remaining proof will show G3 = G2,in which case no further enlargement is possible. Finally, showing that the startstate is not in G2 finishes the proof.

10 As both sequences in a block have identical symbols in column 4, and given thepairwise distinctiveness of these symbols between blocks, there are at most two suchsequences within a state.

17

As G2’s states are subsets of G1’s states11, cc(G2)’s general form is as on theleft:

. . . da 0

. . . da 1

. . . db t1

. . . dc t2

. . . da 0

. . . da 1

. . . db t1(. . . ab t1)

. . . dc t2(. . . ac t2)

(. . . xd t3)(. . . yd t3) , (★)

where ti ∈ {0, 1} (i = 1, 2, 3) are the types of the sequences and ti = 1− ti theirinverses. To see this, observe that states of the form on the left (from which wecan leave out further sequences, as long as we still have at least one 1-sequenceand one 0-sequence) are subsets of the form on the right, where x, y are eitherboth set to a, or one is set to b and the other to c, and, where we leave out atleast all sequences interfering with our wish of a constant column in this position(i.e., the sequences in parentheses in the form on the right). With the variablesintroduced above, we assume a (constant-column symbol) pairing between a andd, and between b and c. This is the only way to obtain a maximal number ofsequences with a d in column 3 for a state in G1. Hence, states in cc(G2) have atleast 2 but at most 4 sequences.

Our aim is to show that the set of these states is cc(G0) again, i.e., it isimpossible to reach any state in G1 via a shuffle from these states. In the following,we do a case distinction on the number of sequences of states µ ∈ cc(G2).

Let us prepend this case distinction with two general observations that willbe used in the following. First, every shuffle set Π that is used to map µ ∈ cc(G2)to a state µ′ ∈ G1 will contain a permutation π with π(3) ̸= 3, i.e., one thatmoves the constant (third) column, as otherwise we cannot generate necessaryadditional sequences with a non-d symbol at position 3. As in [KWH15], we calla state i/j-state if it has i 0-sequences and j 1-sequences. Using this notation,we have that, if µ ∈ cc(G2) is an i/j-state, then the reached µ′ ∈ G1 after theshuffle will be a i′/j′-state with i′ ≥ 2i and j′ ≥ 2j, as the shuffle generates i+ jnew sequences with d at a position π(3) ̸= 3.

Now, let us first consider (a) the case that µ has three or four sequences. Inthis case, there cannot be a permutation π ∈ Π with π(3) = 4, as there are onlytwo possible sequences with a d in position 4 in states of G1, and this (i.e., havinga permutation that maps the d-column to column 4) is the only way to obtainthese two sequences ending with d, as no other column contains a d in µ. Hence,in this case, we have i′+ j′ ≤ 6 due to the two unreachable sequences ending withd. Moreover, as G1 is built from blocks with one 0- and one 1-sequence, we knowthat i′ = j′. But this allows us already to exclude the case of i+ j > 2, because

11 We assume w.l.o.g. that any shuffle contains the id permutation, hence, non-trivialshuffling generates new sequences. Consequently, backwards shuffling then only leavesout sequences, which we describe in set-theoretic terms, by abuse of notation.

18

if, e.g., i = 1 and j = 2 (or vice versa), then i′ ≥ 2 and j′ ≥ 4, but j′ = i′ yieldsi′ + j′ = 8, and if i = j = 2, then we also have i′ + j′ = 8, both contradictingi′ + j′ ≤ 6. Hence, cc(G2) cannot contain any state with three or four sequences.

Now, let (b) µ contain two sequences. For this case, we consider choices oftwo sequences from a state in G1 \ G0 of (∗) with d in column 3. If we chooseboth sequences to end with da, the state would be in cc(G0), which is, however,inconsistent with the state being in G1 \ G0. Hence, there is at most one sequenceof each of the following types: sequences ending with da, with db and with dc.If we choose to include a sequence ending with da, then it is inconsequentialwhether we choose one ending with db or with dc (only the d-a constant-columnsymbol pairing assigns a a special role). W.l.o.g. we choose a sequence endingwith db in the following. This leaves us with two choices, either to include asequence ending with da or to exclude it. In total, we can obtain three statesthat are not already in cc(G0):

bcda 0acdb 1

bcda tcadb t

acdb tbadc t

,

where t ∈ {0, 1} is the type of the sequence. However, the third state is similar tothe second one via the permutation (1 4), so we do not need to consider this case.Each of these states needs one 1- and one 0-sequence, which we can fix w.l.o.g.in the first state. This is because the first state is similar to the first state withswapped 0 and 1 types, also via the permutation (1 4).

We want to show that there is no way to shuffle these two states into a state ofG1 \ G0 as given in (∗). As a first step, we show that, more specifically, we shufflethese into states of the form on the right of (★) (including the sequences withparentheses), where there are up to four d’s in column 3. As the two-sequencestates considered here each have a sequence ending with da, our shuffle needs toreach the other sequence ending with da, in order to complete the block endingwith a in G1\G0. Because of the d-a pairing, this sequence also has a d in the thirdcolumn. Hence, the state reached by the shuffle has at least three ds in the thirdcolumn. However, as we start with two sequences with distinct types (and allsymbols are distinct in the standard deck setting) any permutation π ∈ Π \ {id}that increases the number of ds in that column (by π(3) = 3) at least doublesthe number of sequences. Hence, the resulting state in G1 \ G0 has at least fourds in column 3 and is therefore of the form in (★).

Consequently, for the first state, we have the following scenario:

bcda 0cbda 1

acdb 1dcab 0

(. . . dc ?)(. . . ac ?)

(. . . xd ?)(. . . yd ?)

bcda 0acdb 1

id

(1 4 3)

(1 4 2)

id

19

Reaching the state on the left by a shuffle contains at least {id, (1 4 3), (1 4 2)}.But applying (1 4 2) to the first sequence yields a sequence cadb, which is notpossible in the scheme on the left side due to being the third sequence with atrailing b.

The case of the second state is as follows:

bcda tcbda t

cadb tcdab t

(. . . dc ?)(. . . ac ?)

(. . . xd ?)(. . . yd ?)

bcda tcadb t

id

(1 4 3 2)

(2 4)

id

Reaching the state on the left by a shuffle contains at least {id, (2 4), (1 4 3 2)}.But if we apply (2 4) to the first sequence, we obtain badc, and if we apply(1 4 3 2) to the second sequence, this gives the sequence adbc. The two additionalsequences both end with a c, hence they would form a block in the scheme on theleft, which is not possible, as the resulting block would miss a constant b-column.This shows that cc(G2) = cc(G0).

The start state of base conversion protocols is (up to similarity)

12 34 021 34 1

with the basis intersection requirement |{1, 2} ∩ {o1, o2}| = 1. Because of this,the state is not in G0. As it has a constant column, it would need to be in cc(G2)which is equal to cc(G0) by the argument above. Hence, the state is not in G2. ⊓⊔

Theorem 2. There is no four-card finite-runtime AND protocol with deck D =⟦1, 2, 3, 4⟧ with fixed-in-advance output basis.

Proof. As the final states are (without the basis intersection requirement) thesame as in the proof of Theorem 1, we use the closure clf(G0) derived there, andshow that the start state of an AND protocol is not contained in clf(G0). For this,observe that the start state of an AND protocol is, up to similarity, as follows:

12 34 021 34 012 43 021 43 1

In particular, it has three 0-sequences and one 1-sequence, which excludes it frombeing in G0 or G1 (derived in the proof of Theorem 1 above), as the numbers of 0-and 1-sequences differ. Moreover, observe that it has in each column exactly two

20

distinct symbols, each exactly twice. For states in G2 (which are subsets of G1) itholds that each symbol occurs at most twice in the turn column 4, where each(two-sequence) block ending with one such symbol consists of one 1-sequenceand/or one 0-sequence. If we try to leave out sequences from the G1 template (forthe subsets of G2) to obtain a state of type 3/1, we lose the property of havingeach occurring symbol exactly twice. Hence, the start state cannot be in G2. ⊓⊔

5 Card-Minimal Protocols for AND

Theorem 3. There is a four-card Las Vegas AND protocol with deck D =⟦1, 2, 3, 4⟧ using only random cuts.

Proof. See Figure 6 and Protocol 1.

Table 2. The different states of Protocol 1 after 1 was revealed in the first turn. Thepermutation to be applied in this case is (3 4). The situation is similar in all other cases.

Bits Sequence After permutation Removing 3

(0, 0) 1 2 3 4 1 2 4 3 1 2 4 x

(0, 1) 1 2 4 3 1 2 3 4 1 2 x 4

(1, 0) 1 3 4 2 1 3 2 4 1 x 2 4

(1, 1) 1 4 3 2 1 4 2 3 1 4 2 x

To get a better understanding of why the protocol works and how it is relatedto the protocol of [NR99], let us consider exemplarily the case that the first cardto be revealed is a 1, the other cases are analogous. In this situation, let us look atthe different cases, given in Table 2. Using the method as before, we can remove3 by performing a random cut while leaving the relative order intact ( 1 here is

assigned the role of the 5 in Niemi and Renvall’s protocol) and waiting until

it appears when turning. Later we can remove the 1 from the remaining cards,

to get the output encoded using the cards 2 and 4 . A closer analysis of the

situation after removing 3 shows that one can take a shortcut when one is not

bound to the output being cards 2 4 (which is not our goal, because in theother cases besides the first turn being 1 it is different anyway, and one wouldhave to add conversion protocols to ensure this). The situation is as follows: Theremaining three cards are either a cyclic rotation (cut) of the sequence 1 2 4 ,

if the output is 0, or a cyclic rotation of the sequence 1 4 2 , otherwise. A cutcannot rotate a sequence of the former type to become the other, or vice versa.After the cut we can safely turn any card and, from the resulting symbol, deducein which order the other cards must be output to encode the protocol result.

21

1234 X001243 X012134 X102143 X11

1234 1/4X001243 1/4X012134 1/4X102143 1/4X114123 1/4X003124 1/4X014213 1/4X103214 1/4X11

3412 1/4X004312 1/4X013421 1/4X104321 1/4X112341 1/4X002431 1/4X011342 1/4X101432 1/4X11

(shuffle, 〈(1 2 3 4)〉)

1234 X001243 X011342 X101432 X11

2341 X002431 X012134 X102143 X11

2134 X002143 X012413 X102314 X11

(perm, (2 3 4))

3412 X003124 X013421 X103214 X11

3124 X003241 X013214 X103142 X11

(perm, (2 4 3))

4123 X004312 X014213 X104321 X11

1243 X001234 X011324 X101423 X11

(perm, (3 4))

4213 X004132 X014123 X104231 X11

(perm, (2 3))

(turn, {1})1???

2??? 3???4???

relabel : (1 2)(3 4) relabel : (1 2)(3 4)

1243 1/4X001234 1/4X011324 1/4X101423 1/4X113124 1/4X004123 1/4X014132 1/4X103142 1/4X11

4312 1/4X003412 1/4X012413 1/4X102314 1/4X112431 1/4X002341 1/4X013241 1/4X104231 1/4X11

(shuffle, 〈(1 2 3 4)〉)

2431 X002341 X012413 X102314 X11

4312 X004123 X014132 X104231 X11

3124 X003412 X013241 X103142 X11

(turn, {1})

1???

2??? 3??? 4???

(shuffle, 〈(1 2 3 4)〉)(shuffle, 〈(1 2 3 4)〉)

3124 1/3X03412 1/3X03241 1/3X03142 1/3X13214 1/3X13421 1/3X1

(shuffle, 〈(2 3 4)〉)

3124 X03142 X1

3241 X03214 X1

3412 X03421 X1

(turn, {2})

?1?? ?2?? ?4??

(result, 3, 4)

X(result, 4, 3)

X(result, 3, 4)

X

4213 1/4X004132 1/4X014123 1/4X104231 1/4X113421 1/4X002413 1/4X013412 1/4X101423 1/4X11

1342 1/4X003241 1/4X012341 1/4X103142 1/4X112134 1/4X001324 1/4X011234 1/4X102314 1/4X11

(shuffle, 〈(1 2 3 4)〉)

2134 X002413 X012341 X102314 X11

1342 X001324 X011234 X101423 X11

3421 X003241 X013412 X103142 X11

(turn, {1})

1??? 2??? 3???

4???

(shuffle, 〈(1 2 3 4)〉)(shuffle, 〈(1 2 3 4)〉)

2134 1/3X02413 1/3X02341 1/3X02314 1/3X12431 1/3X12143 1/3X1

(shuffle, 〈(2 3 4)〉)

2134 X02143 X1

2341 X02314 X1

2413 X02431 X1

(turn, {2})

?1?? ?3?? ?4??

(result, 3, 4)

X(result, 4, 3)

X(result, 3, 4)

X

Fig. 6. Four-card Las Vegas AND protocol using random cuts, cf. Protocol 1. Here,X0 := X00 +X01 +X10 and X1 := X11. The relabel operations are not actual actionsto be performed but help abbreviate the write-up of the protocol, see Section 3.

22

Protocol 1. Our four-card AND protocol. The first bit is in basis {1, 2},the second in {3, 4}, and the output in {1, 2, 3, 4}\{v2, v3}, where v2, v3 arethe last two revealed symbols. See Figure 6 for a KWH tree representation.

(shuffle, ⟨(1 2 3 4)⟩)v1 := (turn, {1})if v1 = 1 then (perm, (3 4))else if v1 = 2 then (perm, (2 3 4))else if v1 = 3 then (perm, (2 4 3))else if v1 = 4 then (perm, (2 3))

Let π := (1 3)(2 4)repeat

(shuffle, ⟨(1 2 3 4)⟩)v2 := (turn, {1})

until v2 = π(v1)

(shuffle, ⟨(2 3 4)⟩)v3 := (turn, {2})Let σ := (1 4)(2 3)if v3 = σ(v2) then (result, 4, 3)else (result, 3, 4)

For an analysis of the number of shuffle steps in the protocol, observe thatwe have performed two shuffles until we reach the loop condition, which holdswith probability 1/4. After the loop, we have one additional shuffle step. Hence,the expected number of shuffles is 3 +

∑∞n=1

(1− 14

)n= 6.

Comparison to [NR99]. The previous protocol, using five cards, was describedin the introduction. For a pseudo-code description, see Protocol 2.

As Niemi and Renvall state, their running time in the number of shuffle stepsis calculated as follows: Their protocol starts with a shuffle and repeats thiswith probability 3/5. The second loop contains a shuffle and has a repeatingprobability of 3/4. The shuffle in the final loop is repeated with probability 2/3. Intotal, the expected running time is 3 +

∑∞n=1

(35

)n+∑∞

n=1

(34

)n+∑∞

n=1

(23

)n=

3+1.5+3+2 = 9.5. However, for a fair comparison to our protocol, we eliminatethe last loop from their protocol, as its only function is to ensure that the outputis in basis {1, 4}, which our protocol does not guarantee. In this case, the modifiedNiemi–Renvall protocol has an expected number of 3 + 1.5 + 3 = 7.5 shufflesteps. Hence, our four-card AND protocol needs one card less and outperformsthe Niemi–Renvall protocol by an expected number of 1.5 shuffle steps.

23

12 34 5 X0012 43 5 X0121 34 5 X1021 43 5 X11

51324 1/5X0051423 1/5X0152314 1/5X1052413 1/5X1113245 1/5X0014235 1/5X0123145 1/5X1024135 1/5X1132451 1/5X0042351 1/5X01

31452 1/5X1041352 1/5X1124513 1/5X0023514 1/5X0114523 1/5X1013524 1/5X1145132 1/5X0035142 1/5X0145231 1/5X1035241 1/5X11

(perm, (1 2 4 5))(shuffle, 〈(1 2 3 4 5)〉)

1 3245 X001 4235 X011 4523 X101 3524 X11

2 4513 X002 3514 X012 3145 X102 4135 X11

3 2451 X003 5142 X013 1452 X103 5241 X11

4 5132 X004 2351 X014 5231 X104 1352 X11

5 1324 X005 1423 X015 2314 X105 2413 X11

(turn, {1})

1????2???? 3????

4????5????

(shuffle, 〈(1 2 3 4 5)〉) (shuffle, 〈(1 2 3 4 5)〉)

2 4513 1/4X002 3514 1/4X012 3145 1/4X102 4135 1/4X112 3451 1/4X002 4351 1/4X012 5314 1/4X102 5413 1/4X11

2 1345 1/4X002 1435 1/4X012 4531 1/4X102 3541 1/4X112 5134 1/4X002 5143 1/4X012 1453 1/4X102 1354 1/4X11

(shuffle, 〈(2 3 4 5)〉)

21 345 X0021 435 X0121 453 X1021 354 X11

23 451 X0023 514 X0123 145 X1023 541 X11

24 513 X0024 351 X0124 531 X1024 135 X11

25 134 X0025 143 X0125 314 X1025 413 X11

(turn, {2})?1???

?3??? ?4????5???

(shuffle, 〈(2 3 4 5)〉) (shuffle, 〈(2 3 4 5)〉)

23 451 1/3X023 514 1/3X023 145 1/3X023 541 1/3X123 154 1/3X123 415 1/3X1

(shuffle, 〈(3 4 5)〉)

231 45 X0231 54 X1

234 51 X0234 15 X1

235 14 X0235 41 X1

(turn, {3})

??1?? ??4?? ??5??

(shuffle, 〈(3 4 5)〉)

(result, 4, 5)

X

3 2451 X003 5142 X013 1452 X103 5241 X113 1245 X003 2514 X013 2145 X103 1524 X11

3 4512 X003 1425 X013 4521 X103 2415 X113 5124 X003 4215 X013 5214 X103 4152 X11

(shuffle, 〈(2 3 4 5)〉)

31 245 X0031 425 X0131 452 X1031 524 X11

32 451 X0032 514 X0132 145 X1032 415 X11

34 512 X0034 215 X0134 521 X1034 152 X11

35 124 X0035 142 X0135 214 X1035 241 X11

(turn, {2})?1???

?2??? ?4????5???

(shuffle, 〈(2 3 4 5)〉) (shuffle, 〈(2 3 4 5)〉)

32 451 X032 514 X032 145 X032 415 X132 154 X132 541 X1

(shuffle, 〈(3 4 5)〉)

321 45 X0321 54 X1

324 51 X0324 15 X1

325 14 X0325 41 X1

(turn, {3})

??1?? ??4?? ??5??

(shuffle, 〈(3 4 5)〉)

(result, 4, 5)

X

Fig. 7. KWH tree of the five-card AND protocol of [NR99] with D = ⟦1, 2, 3, 4, 5⟧ usingonly random cuts, cf. Protocol 2. Note that X0 := X00 +X01 +X10 and X1 := X11.The output is in basis {1, 4}.

24

Protocol 2. Five-card AND protocol by Niemi and Renvall [NR99]. Thefirst bit is in basis {1, 2}, the second in basis {3, 4}. The output basis is{1, 4}. See also Figure 7 for a KWH tree representation.(perm, (3 4))repeat

(shuffle, ⟨(1 2 3 4 5)⟩)v := (turn, {1})

until v = 2 or v = 3repeat

(shuffle, ⟨(2 3 4 5)⟩)v := (turn, {2})

until v = 2 or v = 3repeat

(shuffle, ⟨(3 4 5)⟩)v := (turn, {3})

until v = 5(result, 4, 5)

6 Card-Minimal Protocols for Basis Conversion withOverlapping Bases

In this section, we give two protocols for converting a basis encoding in the casewhere the old and the new encoding share a card. The first protocol has anexpected (finite) running time of three shuffle and turn operations. While it hasnot been explicit in the literature, it is in a way implicit in the protocol by Niemiand Renvall [NR99], as the authors aimed to get a fixed-in-advance output basis.

213 X1123 X0

213 1/3X1123 1/3X0321 1/3X1312 1/3X0132 1/3X1231 1/3X0

(shuffle, 〈(1 2 3)〉)

132 X1123 X0

213 X1231 X0

321 X1312 X0

(turn, {1})

1?? 2?? 3??

(shuffle, 〈(1 2 3)〉) (shuffle, 〈(1 2 3)〉)

(result, 3, 2)

X

Fig. 8. Three-card Las Vegas basis convert for D = ⟦1, 2, 3⟧ with uniform closed shuffles.

25

Theorem 4. There is a three-card Las Vegas basis-conversion protocol for over-lapping bases with deck D = ⟦1, 2, 3⟧ and uniform closed shuffles.

Proof. See Figure 8 and Protocol 3.

Protocol 3. Three-card Las Vegas basis conversion protocol as given inFigure 8 with D = ⟦1, 2, 3⟧, input basis {1, 2} and output basis {1, 3}repeat

(shuffle, ⟨(1 2 3)⟩)v := (turn, {1})

until v = 2(result, 3, 2)

Theorem 5. There is a five-card finite-runtime basis conversion protocol foroverlapping bases with deck D = ⟦1, 2, 3, 4, 5⟧. It only uses two random bisectioncuts as shuffle operations.

Protocol 4. Five-card finite-runtime conversion protocol with overlappingbases for D = ⟦1, 2, 3, 4, 5⟧, input basis {1, 2} and output basis {1, 3}(shuffle, ⟨(1 2)(4 5)⟩)v := (turn, {1})if v = 2 then (perm, (1 2)(4 5))

(shuffle, ⟨(1 3)(4 5)⟩)v := (turn, {4})if v = 4 then (result, 1, 3)else (result, 3, 1)

Proof. This is just applying the basis conversion of [M16] twice, cf. Protocol 4.

7 An Illustration of Our Verification Methodology

In the following, we exemplify our translation of card-based cryptographic proto-cols using standard decks to a specific the bounded model checker CBMC whichtakes programs in the C language, and compute a secure AND function. Forour experiments, we used CBMC 5.11 [CKL04] with the built-in solver basedon the SAT-solver MiniSat 2.2.0 [ES03]. All experiments are performed on anAMD Opteron(tm) 2431 CPU at 2.40 GHz with 6 cores and 32 GB of RAM.

26

1 struct sequence {

2 uint val[numberOfCards];

3 struct fractions probs;

4 };

Listing 1. C struct holding the state trees.

1 uint permSetSize = nondet_uint();

2 __CPROVER_assume (0 < permSetSize);

3 __CPROVER_assume (permSetSize

bounded model checker to restrict all program runs passing this statement tosatisfy the specified (Boolean) condition. By assigning values using the spe-cial function nondet_uint(), we assign a non-deterministic non-negative integernumber, which is restricted to values greater than zero and at most of valueNUM_POSS_SEQ (which is a variable computed by the pre-processor and is themaximum number of sequences possible with the given deck) in the followingprogram statement. In the shown example, the non-determinism is used to con-struct a set of permitted permutation sets (to be used by the shuffle operation),which makes the SBMC tool inspect the following program code for all possibleassignments of this value. If necessary, this may result in a fully exhaustive search,however, the prover is often able to restrict the domain based on further programstatements and dependencies seen in the rest of the program. A similar trickis used when computing the concrete permutations using the non-deterministicvalue of permIndex in order to check all possible permutations which possiblymove the values, but preserve all existing numbers in the sequence itself. This isdone using the int-array takenPermutations, which is first initialized to zero and,when choosing a concrete permutation, assumed to be zero at position permIndex,however set to the number one right afterwards (such that it is not permitted tobe chosen again). In the subsequent inner loop, the permutations are assignedchoosing the according cards from the sequences in the start state using thenon-deterministic value permIndex. Finally, the shuffle is applied, resulting in thestate variable result, which is then checked using a further method isBottomFreeto not contain any sequences with impermissible values for Xi, which wouldresult in incorrect computations of the AND function.

We applied our approach to the computation of a secure AND protocol usingfour cards in order to, firstly, substantiate our proof that no protocol of a lengthbelow six can be found, and, secondly, automatically find a permitted protocolusing six operations. Using our approach, we were able to show that no four-card protocol exists using five operations within 57 hours and constructed anoutput-possibilistic protocol using six operations within 31 hours. The sizes ofthe constructed formulas consisted of between 150 and 180 million SAT clauses.

8 Conclusion

In this paper, we proposed a new method to search card-based protocols forany secure computation, by giving a general formal translation applicable to beused by the formal technique of software bounded model checking (SBMC). Thismethod allows us to find new protocols automatically, and prove lower boundson required shuffle and turn operations for any protocol, and provide an examplefor the computation of a minimal AND protocol. We also found a new protocolthat only uses the theoretical minimum of four distinguishable cards for an ANDcomputation. Moreover, we supported this finding by our automatic method inshowing the impossibility of any protocol using less shuffle and turn operationsusing only practicable shuffles (random cuts). The protocol is hence optimal w.r.t.the running time restriction “restart-free Las-Vegas”. For the four-card standard

28

deck setting, we showed that there is no finite runtime protocol, regardless of theshuffle operations used. This result completes the picture of tight lower bounds forthe four-card setting. Finally, we showed tight lower bounds on basis conversionsfor single bits and proposed the missing protocols, and establish the theoremthat using a minimum of five cards, both input- and output-bases can be chosenfreely, which fosters our impossibility result for the four-card setting.

Open Problems. Let us point out some open problems in the card-basedsecurity area that could be approached based on the findings in this paper:(1) For finite-runtime protocols, there exist no proven tight lower bounds on therequired number of cards (five to eight cards). We recommend more researchapplying computer-aided formal methods at this point, as the state space forfive or more cards is very large. (2) Our verification approach is fast for findingprotocols and/or lower bounds on the operations needed in a protocol for givenshuffle-restrictions. However, this is based on the assumption that protocolsexist already for a given predefined length to find or confirm impossibilityresults. Investigating computer-aided formal methods for universal impossibilityresults might be worthwhile. (3) The two most common settings in card-basedcryptography are the standard deck setting with only distinguishable cards andthe two-color decks using ♣ and ♡. However, it may be possible that by mixingthese settings (e.g., only distinguishable cards with one pair of identical cards),we might find more efficient protocols (especially in the finite runtime setting).For such a mixed setting, [SM19] provide nice results to use in further research.

29

Appendix: Further Protocols

This appendix contains the 8-card AND protocol of [M16] (Figure 9) and a secondfour-card protocol which uses a number of 4.5 shuffles in expectation, which are,however, non-closed and hence, more impractical to implement, cf. Figure 10.

21 43 56 78 X1121 34 56 78 X1012 43 56 78 X0112 34 56 78 X00

21 43 56 78 1/2X1121 34 56 78 1/2X1012 43 56 78 1/2X0112 34 56 78 1/2X00

21 43 78 56 1/2X1121 34 78 56 1/2X1012 43 78 56 1/2X0112 34 78 56 1/2X00

(shuffle, 〈(5 7)(6 8)〉)

21 43 56 78 1/4X1121 34 56 78 1/4X1012 43 56 78 1/4X0112 34 56 78 1/4X0021 43 78 56 1/4X1121 34 78 56 1/4X1012 43 78 56 1/4X0112 34 78 56 1/4X00

21 34 65 78 1/4X1121 43 65 78 1/4X1012 34 65 78 1/4X0112 43 65 78 1/4X0021 34 87 56 1/4X1121 43 87 56 1/4X1012 34 87 56 1/4X0112 43 87 56 1/4X00

(shuffle, 〈(3 4)(5 6)〉)

21 34 56 78 1/2X1012 34 56 78 1/2X0021 34 78 56 1/2X1012 34 78 56 1/2X0021 34 65 78 1/2X1112 34 65 78 1/2X0121 34 87 56 1/2X1112 34 87 56 1/2X01

21 43 56 78 1/4X1112 43 56 78 1/4X0121 43 78 56 1/4X1112 43 78 56 1/4X0121 43 65 78 1/4X1012 43 65 78 1/4X0021 43 87 56 1/4X1012 43 87 56 1/4X00

(turn, {3, 4})??34???? ??43????

(perm, (3 4)(5 6))

12 34 87 56 1/4X0121 34 87 56 1/4X1112 34 65 78 1/4X0121 34 65 78 1/4X11

12 34 78 56 1/4(X10 + X00)21 34 78 56 1/4(X10 + X00)12 34 56 78 1/4(X10 + X00)21 34 56 78 1/4(X10 + X00)

12 34 78 65 1/4X1121 34 78 65 1/4X0112 34 56 87 1/4X1121 34 56 87 1/4X01

(shuffle, 〈(1 2)(5 7)(6 8)〉)

12 34 87 56 1/2X0112 34 65 78 1/2X0112 34 78 56 1/2(X10 + X00)12 34 56 78 1/2(X10 + X00)12 34 78 65 1/2X1112 34 56 87 1/2X11

(result, 7, 8)

X

21 34 87 56 1/2X1121 34 65 78 1/2X1121 34 78 56 1/2(X10 + X00)21 34 56 78 1/2(X10 + X00)21 34 78 65 1/2X0121 34 56 87 1/2X01

(result, 5, 6)

X

(turn, {1, 2})12?????? 21??????

Fig. 9. The eight-card finite-runtime AND protocol of [M16], with D = ⟦1, . . . , 8⟧ anduniform-closed shuffles. Output is in basis {5, 6} or {7, 8}, each with probability 1/2.

30

1234 X001243 X012134 X102143 X11

1234 1/2X001243 1/2X012134 1/2X102143 1/2X112341 1/2X002431 1/2X011342 1/2X101432 1/2X11

(shuffle, {id, (1 4 3 2)})

1234 X001243 X011342 X101432 X11

2341 X002431 X012134 X102143 X11

(turn, {1})1??? 2???

1234 1/3(X00 +X01)1243 1/3(X00 +X01)1342 1/3X101432 1/3X111324 1/3X101423 1/3X113421 1/3X004321 1/3X014231 1/3X103241 1/3X11

(shuffle, {id, (3 4), (1 4 2 3)})

3421 X004321 X011324 X101423 X11

1234 X00 +X014231 X101432 X11

1243 X00 +X011342 X103241 X11

(turn, {3})??4?

??3???2?

2341 1/3(X00 +X01)2431 1/3(X00 +X01)2134 1/3X102143 1/3X112314 1/3X102413 1/3X114213 1/3X003214 1/3X013241 1/3X104231 1/3X11

(shuffle, {id, (2 3), (1 2 4 3)})

4213 X003214 X012314 X102413 X11

2341 X00 +X013241 X102143 X11

2431 X00 +X012134 X104231 X11

(turn, {3})

??1? ??3???4?

(perm, (1 2 3))(perm, (1 4 3))

1243 1/3X01342 1/3X03241 1/3X13142 1/3X114132 1/3(X00 +X01)4123 1/3X104312 1/3X1

(shuffle, {id, (2 4), (1 2 4 3)})

1342 X04312 X1

1243 X03241 X1

4132 X00 +X014123 X103142 X11

(turn, {2})?1??

?2???3??

(result, 1, 4)

X(result, 1, 3)

X

4132 1/3X04123 1/3X03142 1/3X113124 1/3X11342 1/3(X00 +X01)1243 1/3X101432 1/3X1

(shuffle, {id, (3 4), (1 3 2)})

1342 X00 +X011243 X103142 X11

4132 X01432 X1

4123 X03124 X1

(turn, {3})??4?

??3? ??2?

(result, 2, 1)

X(result, 4, 1)

X

(perm, (2 4))

1234 1/3X04231 1/3X01432 1/3X12431 1/3X112341 1/3(X00 +X01)2314 1/3X104321 1/3X1

(shuffle, {(1 2 4), (1 2), (2 3)})

4231 X04321 X1

1234 X01432 X1

2341 X00 +X012314 X102431 X11

(turn, {1})2???

1??? 4???

(result, 2, 4)

X(result, 2, 3)

X

2341 1/3X02314 1/3X02431 1/3X112413 1/3X14231 1/3(X00 +X01)1234 1/3X103241 1/3X1

(shuffle, {id, (3 4), (1 2 3)})

4231 X00 +X011234 X102431 X11

2314 X02413 X1

2341 X03241 X1

(turn, {3})??3?

??1???4?

(result, 2, 4)

X(result, 1, 2)

X

(perm, (1 2))

(perm, (1 4 2))(perm, (1 2 4))

Fig. 10. A four-card Las Vegas AND protocol with deck D = ⟦1, 2, 3, 4⟧ and uniformshuffles. Note that X0 := X00 +X01 +X10 and X1 := X11. The output is in one of thebases {1, 3}, {1, 4}, {2, 3}, {3, 4}, determined by the position of the final state in thetree, and can be converted as needed.

31

References

[AHM+18] Y. Abe, Y.-i. Hayashi, T. Mizuki, and H. Sone. “Five-Card ANDProtocol in Committed Format Using Only Practical Shuffles”. In:APKC@AsiaCCS 2018. Ed. by K. Emura et al. ACM, 2018, pp. 3–8.doi: 10.1145/3197507.3197510.

[APS14] M. Avalle, A. Pironti, and R. Sisto. “Formal verification of securityprotocol implementations: a survey”. In: Formal Asp. Comput. 26.1(2014), pp. 99–123. doi: 10.1007/s00165-012-0269-9.

[B12] B. Blanchet. “Security Protocol Verification: Symbolic and Com-putational Models”. In: POST 2012. Ed. by P. Degano and J. D.Guttman. LNCS 7215. Springer, 2012, pp. 3–29. doi: 10.1007/978-3-642-28641-4 2.

[BCC+99] A. Biere, A. Cimatti, E. M. Clarke, and Y. Zhu. “Symbolic ModelChecking without BDDs”. In: TACAS 1999. Ed. by W. R. Cleaveland.LNCS 1579. Springer, 1999, pp. 193–207. doi: 10.1007/3-540-49059-0 14.

[CK93] C. Crépeau and J. Kilian. “Discreet Solitary Games”. In: CRYPTO’93. Ed. by D. R. Stinson. LNCS 773. Springer, 1993, pp. 319–330.doi: 10.1007/3-540-48329-2 27.

[CKL04] E. M. Clarke, D. Kroening, and F. Lerda. “A Tool for CheckingANSI-C Programs”. In: TACAS 2004. Ed. by K. Jensen and A.Podelski. LNCS 2988. Springer, 2004, pp. 168–176. doi: 10.1007/978-3-540-24730-2 15.

[dB89] B. den Boer. “More Efficient Match-Making and Satisfiability: TheFive Card Trick”. In: EUROCRYPT ’89. Ed. by J. Quisquater andJ. Vandewalle. LNCS 434. Springer, 1989, pp. 208–217. doi: 10.1007/3-540-46885-4 23.

[ES03] N. Eén and N. Sörensson. “An Extensible SAT-solver”. In: SAT2003. Ed. by E. Giunchiglia and A. Tacchella. LNCS 2919. Springer,2003, pp. 502–518. doi: 10.1007/978-3-540-24605-3 37.

[FFN14] B. Fisch, D. Freund, and M. Naor. “Physical Zero-Knowledge Proofsof Physical Properties”. In: CRYPTO 2014. Ed. by J. A. Garayand R. Gennaro. LNCS 8617. Springer, 2014, pp. 313–336. doi:10.1007/978-3-662-44381-1 18.

[FHK+14] M. Franz, A. Holzer, S. Katzenbeisser, C. Schallhart, and H. Veith.“CBMC-GC: An ANSI C Compiler for Secure Two-Party Computa-tions”. In: CC 2014. Ed. by A. Cohen. LNCS 8409. Springer, 2014,pp. 244–249. doi: 10.1007/978-3-642-54807-9 15.

[GBG14] A. Glaser, B. Barak, and R. J. Goldston. “A zero-knowledge protocolfor nuclear warhead verification”. In: Nature 510 (2014), pp. 497–502.doi: 10.1038/nature13457.

[K18] A. Koch. The Landscape of Optimal Card-based Protocols. 2018.Cryptology ePrint Archive, Report 2018/951.

[K19] A. Koch. “Cryptographic Protocols from Physical Assumptions”.PhD thesis. Karlsruhe: KIT, 2019. doi: 10.5445/IR/1000097756.

32

https://doi.org/10.1145/3197507.3197510https://doi.org/10.1007/s00165-012-0269-9https://doi.org/10.1007/978-3-642-28641-4_2https://doi.org/10.1007/978-3-642-28641-4_2https://doi.org/10.1007/3-540-49059-0_14https://doi.org/10.1007/3-540-49059-0_14https://doi.org/10.1007/3-540-48329-2_27https://doi.org/10.1007/978-3-540-24730-2_15https://doi.org/10.1007/978-3-540-24730-2_15https://doi.org/10.1007/3-540-46885-4_23https://doi.org/10.1007/3-540-46885-4_23https://doi.org/10.1007/978-3-540-24605-3_37https://doi.org/10.1007/978-3-662-44381-1_18https://doi.org/10.1007/978-3-642-54807-9_15https://doi.org/10.1038/nature13457https://eprint.iacr.org/2018/951https://doi.org/10.5445/IR/1000097756

[KKW+17] J. Kastner, A. Koch, S. Walzer, D. Miyahara, Y.-i. Hayashi, T.Mizuki, and H. Sone. “The Minimum Number of Cards in PracticalCard-based Protocols”. In: ASIACRYPT 2017. Ed. by T. Takagi andT. Peyrin. LNCS 10626. Springer, 2017, pp. 126–155. doi: 10.1007/978-3-319-70700-6 5.

[KW17] A. Koch and S. Walzer. Foundations for Actively Secure Card-basedCryptography. 2017. Cryptology ePrint Archive, Report 2017/423.

[KWH15] A. Koch, S. Walzer, and K. Härtel. “Card-based CryptographicProtocols Using a Minimal Number of Cards”. In: ASIACRYPT2015. Ed. by T. Iwata and J. H. Cheon. LNCS 9452. Springer, 2015,pp. 783–807. doi: 10.1007/978-3-662-48797-6 32.

[M16] T. Mizuki. “Efficient and Secure Multiparty Computations Using aStandard Deck of Playing Cards”. In: CANS 2016. Ed. by S. Forestiand G. Persiano. LNCS 10052. Springer, 2016, pp. 484–499. doi:10.1007/978-3-319-48965-0 29.

[MN10] T. Moran and M. Naor. “Basing cryptographic protocols on tamper-evident seals”. In: Theor. Comput. Sci. 411.10 (2010), pp. 1283–1310.doi: 10.1016/j.tcs.2009.10.023.

[MS09] T. Mizuki and H. Sone. “Six-Card Secure AND and Four-CardSecure XOR”. In: FAW 2009. Ed. by X. Deng et al. LNCS 5598.Springer, 2009, pp. 358–369. doi: 10.1007/978-3-642-02270-8 36.

[MS14] T. Mizuki and H. Shizuya. “A formalization of card-based crypto-graphic protocols via abstract machine”. In: Int. J. Inf. Sec. 13.1(2014), pp. 15–23. doi: 10.1007/s10207-013-0219-4.

[MS17] T. Mizuki and H. Shizuya. “Computational Model of Card-BasedCryptographic Protocols and Its Applications”. In: IEICE Transac-tions 100-A.1 (2017), pp. 3–11. doi: 10.1587/transfun.E100.A.3.

[NR98] V. Niemi and A. Renvall. “Secure Multiparty Computations WithoutComputers”. In: Theor. Comput. Sci. 191.1-2 (1998), pp. 173–183.doi: 10.1016/S0304-3975(97)00107-2.

[NR99] V. Niemi and A. Renvall. “Solitaire Zero-knowledge”. In: Fundam.Inform. 38.1-2 (1999), pp. 181–188. doi: 10.3233/FI-1999-381214.

[RSH19] A. Rastogi, N. Swamy, and M. Hicks. “Wys★: A DSL for VerifiedSecure Multi-party Computations”. In: POST 2019. Ed. by F. Niel-son and D. Sands. LNCS 11426. Springer, 2019, pp. 99–122. doi:10.1007/978-3-030-17138-4 5.

[SHK+16] N. Swamy, C. Hritcu, C. Keller, A. Rastogi, A. Delignat-Lavaud,S. Forest, K. Bhargavan, C. Fournet, P. Strub, M. Kohlweiss, J. K.Zinzindohoue, and S. Z. Béguelin. “Dependent types and multi-monadic effects in F”. In: POPL 2016. Ed. by R. Bodık and R.Majumdar. ACM, 2016, pp. 256–270. doi: 10.1145/2837614.2837655.

[SM19] K. Shinagawa and T. Mizuki. “Secure Computation of Any BooleanFunction Based on Any Deck of Cards”. In: FAW 2019. Ed. by Y.Chen et al. LNCS 11458. Springer, 2019, pp. 63–75. doi: 10.1007/978-3-030-18126-0 6.

33

https://doi.org/10.1007/978-3-319-70700-6_5https://doi.org/10.1007/978-3-319-70700-6_5https://eprint.iacr.org/2017/423https://doi.org/10.1007/978-3-662-48797-6_32https://doi.org/10.1007/978-3-319-48965-0_29https://doi.org/10.1016/j.tcs.2009.10.023https://doi.org/10.1007/978-3-642-02270-8_36https://doi.org/10.1007/s10207-013-0219-4https://doi.org/10.1587/transfun.E100.A.3https://doi.org/10.1016/S0304-3975(97)00107-2https://doi.org/10.3233/FI-1999-381214https://doi.org/10.1007/978-3-030-17138-4_5https://doi.org/10.1145/2837614.2837655https://doi.org/10.1007/978-3-030-18126-0_6https://doi.org/10.1007/978-3-030-18126-0_6

Card-Based Cryptography Meets Formal Verification