 On this whiteboard session, we'll be talking about the subject of secure gambling. Secure gambling is the area of research inside cryptography where you look at protocols that allow you to play card games and other forms of gambling securely. It has been a subject on the cryptographic research literature for about 30 or 40 years since the dawn of modern cryptography. So first let's talk a little bit about what is secure gambling and especially mental poker. In the early 80s, right after inventing the RSA encryption scheme, the same altars proposed to use encryption and public use encryption especially to play a game of poker in such a way that several people can come together from different places in the world and just by communicating and while mistrust in each other play a game of poker where their cards are represented in some encrypted fashion in such a way that in the end of the game they can prove to each other who won without enabling an adversary to gain an advantage in the game. This kind of research at the time was still very in its beginning so the first results had several security and efficiency issues. Throughout the years several different protocols for the problem of playing poker games have been proposed and they have improved both on the security guarantees and the efficiency of the protocols themselves. However, we noticed that in none of these protocols people have actually provided full security proofs. So let's now have a brief discussion on related works and the problems that they present. So the first issue with related works is the lack of security or formal security guarantees. Even though mental poker has been a subject of cryptographic research for so long, no proper security model has been proposed in the literature up to this day. So all these previous protocols had heuristic security guarantees that were not properly formally defined. This is a problem in the world of cryptographic research because without such formal models it is impossible for us to know exactly what level of security these protocols are giving us and also without analyzing these protocols under a full formal model it can happen that the protocols might have flaws that go on foreseeing for years which is actually the case. So in some related works we have actually found concrete security issues apart from the lack of formal guarantees. These concrete security issues range from problems that would actually let an adversary fully control the game to issues that would let an adversary gain some advantage in biasing the output of the game. None of those are good and they are not easy to be solved with the protocols that have been proposed previously. So this is one big point to be addressed in this talk and in the work that we did on secure gambling. We need to analyze our protocols to make sure that such flaws cannot happen and that's what we're going to be doing. Another problem with these protocols is that even if they were fully secure and proven under formal models they still cannot handle the distribution of financial rewards that can be gained in a game of cards or a game of poker itself. So here is one important aspect on how to distribute financial rewards. As well as serving as rewards, financial incentives can also be used to mitigate cheating. In a recent work Stefan Zimbalski and others proposed the protocol where cheaters get financially penalized using the Bitcoin protocol and cryptocurrency. This idea can be extended to other situations where you want to punish an adversary that actively tries to disrupt the protocol when he is detected doing so. This is important to deal with yet another problem that previous works had, which is the situation of aborts. Basically an adversary that learns the output of the game before the other players and sees that it's not advantageous for himself could simply abort the execution of the protocol in such a way that he's not made to pay the rewards to the actual winner. This is a big problem since adversaries could easily disrupt the games in order to avoid paying rewards and that would make the game completely uninteresting for the honest players playing this. Now how can we hope to solve this? As I said we can penalize financially people who abort or who misbehave in different ways. Now for the rest of this talk I'm going to walk you through the basic building blocks that we'll be using to construct a secure poker protocol. These building blocks are threshold encryption, which is a variation of public key encryption, the discrete logarithm non-interactive zero-knowledge proofs and non-interactive zero-knowledge proofs for shuffles. After introducing these building blocks I'm going to show how they can be combined to construct the protocol we call kaleidoscope. This is a protocol that can be used to play a game of poker with financial rewards and penalties. So this protocol is analyzed for the first time in a formal model where we have a simulation based security guarantee which is the golden standard for cryptographic protocol security analysis and it also provides support to financial rewards and penalization for abort and other adversarial techniques. So first I'm going to start by describing threshold encryption. We are going to use a threshold version of the famous El Gamal cryptosystem. Threshold encryption itself was first proposed by Ivo Desmet and other researchers in order to allow the power of decrypting a message to be distributed over a set of people as opposed to just one person who holds the secret key of a public key encryption scheme. In this kind of schemes you start by generating the key pairs with a distributed algorithm. In this distributed algorithm all the parties who will be sharing the power of decrypting a message run the following protocol. They first locally do key generation in order to obtain secret key shares to generate secret key shares. These secret key shares are basically secret keys of the regular El Gamal cryptosystem. So this is done by the following. You generate for each party PI a secret key SKI and a public key share SKI by running the standard key generation algorithm that takes as input a security parameter. The secret key share as in the El Gamal encryption is basically a random element from ZP while the public key share PKI is equal to a generator of a group where the DDH assumption holds to the power of the secret key. This will be what each party will run locally in the process of generating the key in a distributed fashion. Now all the parties broadcast these shares. They broadcast PKI meaning the public key share that they have generated plus a NISC, a non-interactive zero knowledge proof that this public key share was generated correctly so that adversaries cannot cheat and obtain the actual secret key that will be generated, the distributed secret key. After receiving the secret key, the public key shares from all the parties, then they will again locally compute the aggregated public key. They will aggregate the PKI shares simply by multiplying them. They multiply public key share 1 by public key share 2 up to public key share N supposing you have N parties in order to obtain the aggregated public key PK which as you can see is basically the same generator to the power of the sum of all secret key shares. Now they have what looks like exactly a Elgamal secret key and public key pair but no single party will actually know the secret key. They will just know additive shares of the secret key. Having this public key and secret key pair, they can easily encrypt by using the same algorithm as standard Elgamal. In this algorithm you take as input a message and encrypt it under the aggregated public key generating a ciphertext. Now this ciphertext will look like exactly an Elgamal ciphertext. Same generator G to randomness, to fresh randomness and then the message times the public key to the power of the same randomness. This will be parsed and understood just as a usual Elgamal ciphertext. Now apart from these standard operations and later on distributed decryption, rule also needs a property called re-randomization. Now this property basically lets us refresh the randomness of a ciphertext. So assume you have a ciphertext that looks as before G to the R, message times public key to the R. We want to generate another ciphertext that encrypts the same message but with a different randomness R prime. So how do we do that? We first sample a random R prime from Zp and then we basically raise each of the terms of the ciphertext to the new R prime, obtaining a ciphertext C prime that looks like this. Now this ciphertext is still encrypts exactly the same message as before. This is equal but the randomness is different. The final randomness in the ciphertext will be such that you cannot identify that this ciphertext, this re-randomized ciphertext C prime was actually generated from the initial C. This is a property we'll call unlinkability, unlinkability is this property under which given a ciphertext C and then another ciphertext C prime, you cannot detect that C prime was generated by re-randomizing C and this property will come in handy when we have to do shuffling of cards. We'll be representing cards as algomile ciphertext, I mean the threshold version of algomile ciphertext and re-randomization will play an important role in shuffling these ciphertexts. Now another important algorithm in threshold encryption is distributed decryption by which parties can come together to decrypt the given ciphertext without revealing to each other their secret key shares. Now distributed decryption will look a little bit like distributed key generation in that it's basically running the, locally running the standard algomile decryption and then broadcasting decryption shares. So the first step is to locally run the following algorithm where you get a ciphertext C, let's recap G to the R, M times Pk to the R and you compute G to the R to the power of the secret key share generating Di which we'll call a decryption share. Now this decryption share is broadcast by all those parties that generated them locally so that they can be aggregated in order to decrypt the actual ciphertext. How can you use this to decrypt the actual ciphertext? First you aggregate all the these in order to obtain G to the R times the sum of all secret key shares which can be used to decrypt using the standard algomile decryption algorithm which will give us the final message. Now in this process you also need to generate a NISC, a non-interactive zero-knowledge proof proving that this decryption share was indeed generated correctly meaning that it was generated from the ciphertext that's being decrypted and from the secret key share held by the party that's proving decryption share validity. This is important so that malicious parties cannot cheat and try to make the other honest parties think that the decrypted message is different from what it actually is. Now having this tool will also need the non-interactive zero-knowledge proofs used in both distributed decryption and distributed key generation plus non-interactive zero-knowledge proofs for the validity of shuffles which we'll look at now. What we're looking at here is a non-interactive version of a zero-knowledge proof for discrete logarithm relations for the log. To shorten this really big expression we use the acronym N-I-Z-K or NISC and we do have constructions that can be used to prove the relations that we need in the distributed decryption and key generation algorithms. The first relation we need is knowledge of a discrete logarithm. You need to prove that you know the discrete logarithm of a given group element in relation to a generator. This the first proof for this not the first but the most efficient and widely used one was proposed by Shinor in the 80s and it lets you show that given a public Y and a public base G you can prove that you know this secret witness. This is that you never leak the exponent E while both Y and G are public but still this proof allows you to convince verifier that you actually know the right E given both Y and G that are public. Apart from that we also need to prove the equality of discrete logarithms of different values under different bases. So how this is going to look like? This proof will be used for decryption. We are going to be using the proof proposed by Chow and Pilsen in 92 which allows us to prove a relation that looks like this. Given A and given B that are public we want to show that the discrete log of A under bases G is equal to the discrete log of B under bases G prime. So in this case we know publicly G, G prime, A and B those are public while the actual discrete logs meaning E and E prime where G to the E prime is equal to B and G to the E is equal to A are secret. This proof will allow us to complete distributed decryption correctly. The next non-directives or knowledge proof that we are going to need in order to build our gambling protocol is proof that shows that the process of shuffling ciphertexts has been executed correctly. This is a tool that has been used a lot in the literature of mix nets and voting and there are several such nisks that can actually be employed. The one we chose to employ was proposed by Bayer and Roth in 2012 and it's a proof of shuffle correctness that scales well with large numbers of ciphertexts and large numbers of parties even though in our case we'll be dealing with a regime where we have just 52 ciphertexts representing the 52 cards in a standard deck. Now first of all before we talk about this nisk we have to define what is the process of shuffling ciphertexts of a public encryption scheme. So we'll start by answering the question of what's a shuffle? What do we talk about when we talk about shuffling ciphertexts? First let's say we have a number of ciphertexts that we have generated using the regular encryption scheme C1 up to CN. The ciphertexts are just perfectly normal public key encryption ciphertexts and we want to generate another set of ciphertexts such that their orders are permuted and they cannot be related traced back to the original order. How do we do that? First we'll start by re-randomizing the initial ciphertexts obtaining C1' which is obtained through re-randomization of C1 up to CN' which we obtained by re-randomizing CN itself. Now we remember that the re-randomized ciphertexts cannot be linked back to the original ciphertexts. So if I give you a random C, Cj', let's say you cannot say which C of the original ciphertexts was related to it. So now how can we achieve the actual shuffle? We're going to permute these re-randomized ciphertexts. Now we say we have C1', C2', C3', C4', up to CN'. We are going to permute them in a random way by choosing a random permutation such that we get C1', C2', C3', C4', up to CN'. We simply permute them in a totally random way and by the process of re-randomization and permutation and the unlinkability guarantee we cannot tell which of these final ciphertexts in the set of final ciphertexts is related to each of the original ciphertexts in the first set. So we basically say that this set and this set are unlinkable. You cannot reverse the process of shuffling. Now if we do this correctly we get a perfectly shuffled version of the original ciphertexts where the same messages are still inside of these final ciphertexts but we just don't know which ciphertext contains each message. The problem is that a malicious adversary could simply cheat and not re-randomize the original ciphertexts but input ciphertexts with messages of his choosing. We have to deal with this kind of attack by requesting each party who does such a shuffling process to provide a non-interactive zero-knowledge proof that this process was done exactly in this way. Now this proof will basically show us that this was executed. This NISC will prove that this whole process as I have described has been executed exactly as I have described and an adversary couldn't have just picked random messages to input in these ciphertexts or substituted ciphertexts or basically given invalid values. So we will need this NISC of shuffle together with this process of shuffling to actually build the shuffling process of kaleidoscope or poker protocol. Now that we have all the tools that we need, let's look at how we actually build the poker protocol we call kaleidoscope. Just a little bit on the history of the name. We have named this protocol thinking of a sixties movie where a cheater actually manages to identify which cards are being played by tainting each of the cards in the deck. And what we want to achieve is exactly a protocol where this is not possible, where this cannot happen, where you could catch such a guy. Now the main idea of this protocol intuitively is to represent each cards as ciphertexts. This ciphertext will just encrypt a card number say one from one to fifty two and then they can be shuffled and distributively decrypted in order to open a card towards a single person or to the public. And throughout the whole process we're also going to make sure that witnesses are generated, proving that the protocol has been executed up to a certain point such that if somebody later tries to cheat we can cheaply have a public discussion where people post to the blockchain, short witnesses showing up to where the protocol has actually worked and then the cheaters are forced to reveal themselves if they want to proceed with cheating by providing an invalid message in the blockchain or simply failing to provide one. And when that happens we can penalize them in order to prevent people from having incentives to actually do these attacks. So they basically will know that if they cheat, if they abort they will be penalized. That's the whole idea of the protocol and also we need to deal with the size of these messages that were posted in the blockchain. The interesting thing is that most of the protocol will just run without any interaction with the blockchain. So now let's look at the phases in which this protocol is executed. First of all we have a check-in phase which is a phase where basically the parties will lock their coins, use both as collateral in case they cheat and bets. Now this locking is the first process that actually requires interaction with the blockchain. You have to post a transaction saying you're entering the protocol and this amount of coins are locked to be used to punish you in case you cheat or for you to bet inside the game. After this the protocol will not touch the blockchain anymore unless somebody cheats. So this is important to remark, this goes on the blockchain but all the rest from here on won't go on the blockchain and I'm going to remark again the phase, the recovery phase that would require blockchain interaction. Apart from this in the checking phase completely off-chain, let me even make a big mark here, this is going to be off-chain, the parties will use the distributed generation algorithm to generate a public key and secret key pair of a threshold algama such that each party has a secret key share and they all obtain a private key, I mean a public key, distributed key generation and also they broadcast signature keys that will be used for generating their, let's call them VK for verification keys because all the messages in the protocol will be signed by the party generating its messages. From the distributed key generation procedure everybody will obtain an aggregated public key PK and a secret key share SKI for each party. Now with this setup we are ready to play any number of games that we want without having to regenerate keys or a lot more coins. So basically after we do this checking phase we can play poker ten, a hundred, a thousand times as long as we still have a positive balance of bad coins that we can use to bet on the game and that we wish to remain. Of course at any point the players can choose to leave the game and they can do so by posting a message in the end of one hand. It's just important to remark that this phase the one with the key generation and key broadcasts will not be required for every single individual game. Now the next phase is the actual shuffle. For the shuffle we'll basically use the same procedure that I have just described for shuffling ciphertexts and we will use the following round robbing strategy. First we're going to represent cards as follows. C1 is going to be an encryption of 1. Up to C52 is going to be an encryption of 52. All these encryptions are done under the public key that was distributedly generated in the checking phase. Now we'll start from this encryption and each party, each party PI runs the shuffle. The shuffle procedure we just described. This will generate a new set of ciphertexts. C1 prime i for each party, PI up to Cn prime i. Which will be broadcast together with a NISC showing that this shuffle has been done correctly. Apart from these, of course, all parties check the NISC validity, allowing them to detect if one of the parties has tried to cheat. The idea is that by having each of the parties run the shuffle procedure, none of them in the end actually know what is contained in the last set of ciphertexts. Except that all the card IDs from 1 to 52 are actually contained in the ciphertexts. The idea is similar to what is done in MixNet protocols and is well understood and well analyzed. So we know that it's a good way to do this kind of shuffling. Once we have a shuffle set of cards in place, we can start actually playing the game by revealing community cards and giving to each people their private cards, which we'll look at right now. In order to actually open a card, what we have to do is to distributively decrypt the ciphertext representing the card we want to reveal, of course, because that ciphertext will contain the card number and tell us which card we actually got. So first let's look at how we can open a card towards one specific person, which I'll call the opening of a private card towards a specific party PJ. So first all players PI, but the player PJ, compute their decryption shares, which will be due to the R to SKI. And they broadcast this decryption share so that PJ receives it. And other people can also check it later for validity when PJ decides to reveal his card. Now PJ itself computes his own decryption share, DJ equal to the R to the SKJ, and he aggregates all the decryption shares, D1 to DN, using them to decrypt the ciphertext. He obtains his card number. Now notice that the ciphertext representing the card can only be decrypted if you know all of the decryption shares. And in this case the only party who knows all the decryption shares is PJ. The other party is no almost solid decryption shares, but PJ shares, so they cannot learn anything about this card. But PJ can of course learn the value of the ciphertext, thus the number of the card. Notice that even though I have left it implicit here, all the PIs but PJ also generate a non-interactive or knowledge proof, showing that this decryption share was correctly generated. And PJ is going to check these proofs as well as the other parties will check each other's proofs to see if somebody is trying to cheat in the game and provide bad decryption shares, which would cause the recovery procedure to be activated and then the cheater would be penalized. Now if we want to open a private card, we do this procedure where only PJ learns it, but we need to have a procedure where we can prove publicly the value of a card, meaning the content, proof that we know the content of a given ciphertext that we generated in our shuffle, which we call opening public cards. The procedure for opening a public card is basically the same we have described. All PIs generate and broadcast their decryption shares for decrypting the ciphertext representing the card that's being opened publicly. All of the parties then aggregate the DIs and decrypt the card ciphertext. Again, in this case, they also generate and broadcast a proof that the DIs are correct. So just to make it clear, we have an isque here that shows that this decryption shares have been correctly generated. The only difference from the public opening of a card and the private opening of a card is that in the private opening of a card, the person who is receiving this card privately does not review their own decryption share, leaving the other people in the dark. But in the public opening, all people can be convinced that the card was correctly opened, including people who are observing the protocol execution. With these procedures in place, we basically need one more component to have a full game of poker, which is a procedure for taking bets. We need to have a way for the players to say if they want to raise a bet or drop out of the game or any actions, betting actions that they can have in the poker game. We do that by broadcasting signatures. So in this procedure, every party PI broadcasts a signature on the betting action they are taking. This signature can be verified by everyone and later used against a cheater if he claims that he did not take a betting action. Notice that the signature will call SIG will be generated under the signing key corresponding to the verification key that was publicly broadcast in the checking phase. So all people participating in the protocol know how to actually verify that the signature is correct. Now, this is basically all run off-chain, but we're gonna have to describe the protocol process for recovery that will be run on-chain. Again, to remark, this is off-chain, but the next procedure will require blockchain interaction. In this procedure, we will penalize a cheater or a person who tries to abort during the game. The idea is the following. If a party PJ suspects cheating, cheating, meaning that PJ received an invalid message or PJ failed to receive a message from another party, PJ will complain publicly. What is this complaint? It's a message on the blockchain. This message will say what round PJ's view of the protocol is, what is the current round, and also it will contain a proof that everything up to the previous round was executed correctly, and we will initiate the so-called recovery process. Notice that after every single of these procedures of taking bets or opening a card publicly or opening a card privately or generating a shuffle, we have a set of information that we can use to later prove that the protocol has been executed correctly. The interesting thing is that instead of simply posting on the blockchain, the whole content of the messages generated in each of these procedures, we generate a compact checkpoint witness. Check point witness. Now, what is this checkpoint witness? This is a signature or rather a set of signatures that can be aggregated with a motor signature scheme, saying that the phase has been completed satisfactorily. Signatures agreeing on successful completion. In order to have a valid checkpoint witness, you need to have signatures under the keys of all the parties involved in the protocol, by all parties PI. Apart from the signatures, we also save other information such as the ciphertext representing cards and zero-knowledge proofs that the ciphertext have been correctly generated, for example. We can actually drop these proofs in case we have a full checkpoint witness saying that the shuffle was correctly generated, but we still need to post the ciphertext to show that decryptions of those ciphertexts were correctly generated. Now, notice that this significantly reduces the on-chain complexity of this protocol on the one on-chain heavy phase. Remember that before we have only used the chain in order to lock coins, just standard transactions lock in a bunch of coins for the game to proceed. But now we are actually going to post protocol information, meaning checkpoint witnesses and other silver information apart from the next message that should be generated. Once a complaint occurs, all the other parties PI, including PJ who complained, will have to post the next message of the protocol after this checkpoint was generated. Let's say we have failed at a betting round where somebody should have sent a signature saying they're betting action and they didn't send. Well, all the parties will then have to actually post on the blockchain the message for this round, which is their signature on their betting action. After all the parties have posted their next round message to the blockchain, allowing everybody, including third party observers to verify that the protocol was actually executed correctly, then we can check whether these messages that were posted are valid or not. If one of the messages is invalid, the person who posted the invalid message is penalized and loses their collateral deposit. On the other hand, if everything is fine, if all the messages are posted on the blockchain and they're all valid, then we can proceed with the protocol. So if valid, we proceed. If not, we penalize the cheater. That's basically the mechanic of the recovery procedure. Now that we have constructed procedures for shuffling cards, opening cards, and basic card operations, as well as the recovery procedure to be run to penalize cheaters, we actually have to show how to finish a poker game in the showdown phase, where people either review or mug their cards and determine who won the game. This procedure will be run as follows. Each of the players has two choices, either to mug or to review. So in the order that the game has been played, the players will take their actions. They will either broadcast an opening of their cards with which they can show that they had a given card using the public opening procedure that we have established before. Basically, they don't have to run the whole public opening procedure from scratch because the decryption shares by all the other parties are already publicly known. So the party PI revealing only has to send its decryption share plus the NISC. Or you broadcast a signed MUC action. Basically, we'll require a party who wants to MUC to broadcast a signature SIG on a MUC action under the signing key related to the verification key from the check-in such that everyone can verify that this party is actually MUC-ing. Based on the cards that were revealed and on the rules of poker, then we establish who won the game. This winner will then have its balance increased or the set of winners who have their balance recalculated so that you know how much money each person still has in this game. In order to do this in a publicly verifiable fashion, all the parties PI will sign the new balance that has been determined by the outcome of the game. And of course broadcast the signature. This will allow anyone to publicly verify the final financial situation of the players in the game and it will allow the players who wish to check out from the game and retrieve their current balance to prove that they actually have those coins in the game so that they can transfer those coins to an address of their choosing. Now we come to the final phase, which is the checkout where a party broadcasts a checkout action and then of course a sign checkout action and then is able to retrieve its current balance. Notice that this phase does not have to be executed after the end of a game. You can run any number of poker games with this protocol and only checkout after the end of the game where you want to leave the playing field. So you don't have to run a game, checkout, collect your balance, then do the checking again to run another game. After the checking, you can play any number of games and only run checkout when you want to leave, which is good so we don't waste the time that is needed to do the checking. Now, notice that even though I show these procedures in more or less modular fashion, they are not actually modular. They have to be run in a specific order determined by the rules of poker in order to achieve security in our model, meaning that what we have proven is that running these procedures for the game of poker has security, but if we simply mix and match the procedures without further security analysis, we don't have any guarantee that we'll get a naturally secure protocol. So that brings us to open questions and future works that we are working on right now. What do we have? We have a very specific protocol that works for poker, but it's good that it has formal security guarantees and it's efficient and it has minimal chain interaction, but it's still a bit limited in that it can only be used for poker. So one important topic for future works is constructing general card game protocols. Another point that can be improved over our current results is that even though we have a simulation-based security model for this poker protocol, it does not guarantee arbitrary composability, meaning that we cannot mix and match and combine this protocol with any other protocol that we might be running in parallel without compromising its security. However, when you run a protocol in a complex environment such as the internet and especially as part of complicated blockchain applications, it is important to achieve composability so that we are sure that this protocol won't break when combined with different applications and protocols. To solve that, we want to analyze our protocols in the universal composability framework which allows us to show that a protocol actually achieves this kind of security. Both of these points are being addressed in our upcoming paper called Royale. In this paper, we have a protocol that can be used to play any sorts of card games where we can actually mix and match the card operations in any order we like, do them in parallel or anything like that. And we can prove that it is universally composable, meaning that we can actually use it in conjunction with other protocols and more complex applications. If you want to know more about that, soon we'll be releasing a preprint of this paper on the IACR ePrint, so stay tuned for this interesting, exciting results that are coming. Thanks for your attention and I hope you have learned a little bit about secure gambling on blockchains.