 Hi, I'm Steven Goldfeder and today I'll be talking about zero-knowledge subversion resistance and concrete attacks and this is joint work with Mateo Campanelli and Rosario Gennaro at City College of New York as well as Lucca Nazzardo at MDL Software Institute in Madrid. So you all know that by now, especially if you listen to Ian's talk, that snarks, which are the backbone of the Zcash protocol, amongst other things, require a trusted setup. But the question and something Ian touched on, but we'll get a little bit more into today is what could actually go wrong? So say your trust is betrayed, what actually happens in practice? In other words, what are we actually trusting? And to answer this question, we're going to take a detour into a protocol called zero-knowledge contingent payments, which is a fair exchange protocol over the Bitcoin blockchain. And we'll see a prime example of what actually went wrong in practice and try to learn some lessons from here about what can go wrong with a trusted setup. So the basic problem that zero-knowledge contingent payments tries to solve is you have a buyer and a seller, here we have Alice and Bob, and Alice says, I have some Sudoku solution or some puzzle that I want to know the solution to, but I can't figure it out. And Bobby says, okay, don't worry about it, I know the solution and I'll sell it to you and I'll pay you for, and I'll sell it to you. It's just pay me money and I'll give you the solution. And Alice says, hey, wait a second, give me the solution and then I'll pay you. So this is a trust issue. It's the classic fair exchange problem. And even though we know that there are classic results due to cleave that fair exchange in a trustless manner without a third party is impossible, we can sort of get around that with a blockchain because our blockchain can be our trusted party. So we can do a trustless fair exchange in practice. And this is what the zero-knowledge contingent payment protocol does and this protocol is due to Greg Maxwell in 2011. So let's take a look at that. As a background, we're going to need a tool called hash lock transactions, which is the main tool of this protocol, and it's very simple. Alice has some money and he can spend it with the following condition, which says, I'll pay Bobby if she reveals x such that x hashes the shot to hash to y. So Alice publishes y in the blockchain and says, hey, Bobby, you can take this money. All you need to do is show me x. And Bobby says, hey, sure, no problem. Here's x and she claims the money. And the contingent part here is that Bobby receiving the money is contingent on Alice and actually the rest of the world learning the value x. Okay, so that's the tool that we'll need. Now let's take a look at how the zero-knowledge contingent payment protocol works. So again, Alice wants to buy the solution, Bobby wants to sell it, and no one wants to move first. You have a fair exchange problem, and let's see how the protocol works. So Alice starts off with some money, Bobby starts off with the solution, Bobby takes her solution and she encrypts it, takes some key, puts it in the safe, and she sends over that cipher text to Alice. Okay, she also goes ahead and she takes the key that she used to encrypt that cipher text and she hashes it with shot two, call that y, and she sends that over to Alice as well. Okay, and now she gives Alice a zero-knowledge proof that says, hey, that cipher text that I gave you, that actually is a valid encryption of the thing that you want, meaning the solution. And also that y that I gave you is the shot two hash of the key that the solution was encrypted with. Sends over that proof to Alice. And now at this point, Alice is convinced that all that he has to learn is the preimage of y, and that's equivalent to learning the Sudoku solution that he wants, because once he has that key, or the preimage that Bobby knows, he'll be able to open up the cipher text and learn the solution. So Alice goes ahead and creates one of these hash log transactions that says, hey, tell me the preimage of y, tell me that key, and then you'll get your money. And again, this transaction is enforced by the Bitcoin blockchain. It's built into Bitcoin scripting. It's available today. And Bobby says, sure, here's the key. And now simultaneously, Bobby gets her money and Alice gets the key. But as we said, getting the key is equivalent to learning the Sudoku solution that Alice wanted. So everyone's happy, and the protocol works. Alice knows the solution, Bobby got paid, and we're done. Kind of. One thing we left unspecified is how do we actually implement this proof? We said very nice, take this proof, just prove that everything works, and great, but how do you actually do that? And the zero-knowledge contingent payment protocol was introduced by Maxwell in 2011. And the truth is at the time, it was more of a theoretical object, because we didn't really know how to implement these proofs. It was before the days of Snarks. And let's take a quick, very, very abridged history, look at the history of zero-knowledge proofs to understand what exactly the properties are you want of zero-knowledge proofs, and how they developed. So they were originally introduced in the 80s, and zero-knowledge proofs give you basically two properties. So one is a soundness property. And what this means is what I'm proving to you is actually correct. In other words, I can't give you a false proof. So in our example, Bobby needs to convince Alice that she actually encrypted a valid solution. She shouldn't be able to convince Alice of that if she did not. And the zero-knowledge property says, well, the proof shouldn't leak any data. So Bobby's giving over this proof that she knows the solution, but it should only be a proof that the solution, sorry, was encrypted. The proof shouldn't leak the data. In particular, in our example, Alice shouldn't be able to look at this proof and learn anything about the solution, other than the fact that it's encrypted in the cyberdecks that he holds. Okay. So zero-knowledge proofs, originally we talked about interactive proofs. Also in the 80s, where the introduction of non-interactive proofs, which is a one-move protocol where the prover goes ahead and just sends this proof to the verifier, and no interaction is needed. And it was shown that at least without resulting to random oracles, you need what's called a common reference string, a CRS, and this is the infamous trusted setup. So non-interactive zero-knowledge proofs require a trusted setup, trusted parameters, and someone has to perform this setup. Okay, let's jump forward to 2012, and that's when Genaro et al and GGPR paper introduced what later became to be known as ZK Snarks. And these are very efficient non-interactive arguments, where an argument is just a computationally sound proof, and they require, as do all non-interactive zero-knowledge proofs, they require a trusted setup. Okay. Great. So this is 2012, a year after Maxwell presented zero-knowledge contingent payments, but now we have a contender for something where we can actually implement the protocol. And that's actually what happened. It took a few years for the improvements we made to Snarks, for Lipsnark to be developed, and in 2016, at the financial crypto conference, Sean Bao, a member of the ZCash team, demoed the first zero-knowledge contingent payment in which he brought a Sudoku solution from a remotely participating Greg Maxwell. And this was a big deal. It was the first zero-knowledge contingent payment. But wait a second. One thing we left out was, we said that there is this trusted setup in Snarks, and who performs the trusted setup in our example? Is it Alice? Is it Bob? Is it something else? Is there an MPC? Where do these parameters come from? So this is something where Maxwell dealt with in the blog post where he announced the first successful, or was dubbed the first successful zero-knowledge contingent payment, and I quote, the GGPR12 crypto system requires a trusted setup, but for the ZKCP application, ZKCP being zero-knowledge contingent payments, this is no real limitation since the buyer can perform it. So let's take a look at what Maxwell was suggesting and what they actually implemented in practice. So here you have the buyer, Alice, in our example. He's going to create the trusted parameters, the CRS as we call them, and send those over to Bobby. Bobby now uses those parameters and sends Alice a proof. So intuitively, this kind of makes some sense, because Bobby needs to convince an audience of one that the proof is correct. Again, Bobby's the seller, Alice is the buyer, as long as Bobby convinces Alice that what he's going to buy is the right thing, no one else in the world has to deal with this. As opposed to Zcash, where you have to convince the entire world that the correctness of this setup here is a much more limited thing you need to do. So it kind of made a lot of sense that Alice should generate the parameters. This kind of makes sure that Bobby can't cheat and give a false proof. But it's kind of missing something, because true, that prevents a malicious Bobby, a malicious seller, from creating a false proof, but it doesn't present, France, a malicious Alice. In particular, a malicious Alice could break the zero knowledge property and want to learn something from the proof. And this is exactly what we did in our CCS paper from this year, where we actually implemented an attack in practice. I'm going to leave out the details of how the attack works, because it's not really appropriate for the setting, it's a little bit involved, but the structure of the attack is what's interesting, and that is Alice takes this malicious CRS, he does something a little funny, intentionally malicious, when he creates these parameters and he sends them over to Bobby. And Bobby now goes ahead, not knowing any of the better, she goes ahead and gives what she believes is a zero knowledge proof. But because of the way that Alice maliciously generated this CRS, Alice now broke the zero knowledge property and he can inspect the proof and actually learn bits of the Sudoku solution from it. And remember, the proof is exchanged in the zero knowledge contingent payment protocol well before any payment happened. So now Alice says, hey, I got the solution ready just from the proof, I'm done, abort the protocol, and never pays anyone any money. So this is a problem, this was an attack on the zero knowledge contingent payment protocol that Maxwell and Vow demonstrated, and this was due to a misuse of Snarks, whereas Snarks required a trusted setup, this was used without, in a slightly different model, which violated those assumptions. And the key takeaway here is, so there's a dual adversary model, whereas they were only considering the soundness adversary that wants to create false proofs, you also have to consider the zero knowledge adversary who wants to learn information from those proofs without paying for it in this case. And we implemented this attack in practice, it interacts with the honest paid of Sudoku seller that Ball and Maxwell released, and they are able to steal part of the solution. So again, the key takeaway is, so the GGPR or ZK Snarks, as they're known, system requires a trusted setup, and in its original presentation, that trusted setup was required for both zero knowledge and soundness. So now, at least for zero knowledge contingent payment protocols, our protocol is broken, we don't have a protocol that works, so can we fix it? And the answer is yes. There's a technique called subversion zero knowledge or subversion resistant zero knowledge, and in our CCS paper this year, we sketched how to do this, and in concurrent work that appeared in Eprint in the weeks after we released our paper, there were a bunch of papers that showed up that presented how to do a subversion zero knowledge snark. And actually, one of those papers was from the Zcash team, and it turns out that in the Zcash MPC protocol, they didn't frame it in these terms, and they didn't realize that it had applications to general subversion resistance, but they did include subversion resistance measures. So what is subversion zero knowledge? So what it does is at least, it makes it that you're no longer relying on the trusted setup for the zero knowledge property. So zero knowledge you have without any trust, the trusted setup is still required for the soundness property, meaning if you don't trust the setup or if something goes wrong, you could potentially create false proofs, but zero knowledge property is no longer relying on that trust. And in Zcash, this is really nice. So this is what they actually do in the Zcash MPC. So what would happen if the Zcash MPC was subverted? So with all those crazy setups that Ian showed us, somehow they were really subverted and everyone was working together, which I'm not suggesting happened, but in theory, what would happen if the setup was subverted? So you would be able to create false proofs, which in the context of Zcash means you could actually mint money because you just spend money that you don't have, but what you can't do is you can't break anonymity. And what that means is that you can send money to the Zcash network knowing that your anonymity is not relying on anything of the trusted setup. So even if the trusted setup went totally wrong, the anonymity, at least as offered by the zero knowledge proofs, cannot be compromised. And now that works very well for Zcash, but there's a problem. These subversion zero knowledge techniques that I've discussed, although I haven't gotten into them, they're quite expensive. What they do is they augment the CRS. They add only a few elements to it, but they also add lots and lots of checks, and these checks take a really long time. So for the ZKCP protocol, whereas Maxwell and Bow's original implementation was really quick, they did a live demo, it completed in less than a minute, when you add the subversion zero knowledge to the picture, it takes, and this is a very conservative estimate for a rather small circuit, meaning the Sudoku solution, at least 45 minutes. And the idea is that it takes a nice, elegant, quick exchange protocol and blows it up in practice. And the key difference between Zcash and ZKCP, in Zcash this is okay. So even if the protocol takes another day or another few hours, it doesn't really matter. This is a one-time setup of the system, and you can incur this cost, it actually had a great benefit that you now have unconditional zero knowledge, or zero knowledge, I'm sorry, unrelated to the setup. But with ZKCP, the buyer and the seller have to do this CRS every time, it's kind of part of the protocol itself, there's not a one-time thing, so it's a bit of a large cost to incur in practice. So the question is, can we do better? What if we don't actually need full zero knowledge from our snark? So we don't need full ZK subversion. And what I mean is there's a less, zero knowledge has a little known sibling that's a little less popular, but it's called witness and distinguishability, and it's a weaker form of zero knowledge, and what it guarantees is that, often for a zero knowledge proof or any proof, you might be able to prove the thing in different ways. You'll have what we call various witnesses, and a witness and distinguishable proof will say, you can't distinguish in between the various witnesses. I don't know if you're a prover that used this witness or that witness, and in particular what this means is, the proof is not necessarily zero knowledge, it may leak information that's common to all the witnesses, but it won't leak any information specific to a single witness. And it happens to be that getting subversion witness and distinguishability is actually really simple, with very much fewer checks and very efficiently done, and this is even presented in the original snark paper. But WI doesn't really help us, because in our example, the witness is a Sudoku solution, which is generally unique. There only is one Sudoku solution. So saying a proof can leak information that's common to all the witnesses when you only have a single witness is equivalent to saying the proof can leak the entire witness, so we actually don't gain anything. But let's see if we can switch up the protocol a little bit and leverage the fact that we can get subversion WI very simply to build a better protocol that doesn't, that we don't need to resort to using the expensive subversion zero knowledge. So here's how our protocol works. Again, it's the same problem. Alice wants to buy a Sudoku solution. Bobby wants to sell it. It's a very similar protocol, but with subtle differences. So here in the first step, while originally Bobby encrypted the Sudoku solution, Bobby doesn't do that now. She says to Alice, I'm going to encrypt the Sudoku solution or I'm going to encrypt garbage, meaning I'm going to encrypt perhaps anything in the world. But it might be a Sudoku solution. So this doesn't seem like a very useful statement and she hands Alice that Cypher text. Again, Alice doesn't know what's in there. He just knows that it might be the Sudoku solution. And now Bobby goes ahead and says, and that key that I used to encrypt whatever it was that I encrypted, I'm going to take a hash of it, but I'm not going to tell you which function I'm using. Or maybe I'll use shot two, maybe I'll use shot three. Here you go, here's why. So, so far it seems that Alice doesn't have very any really useful information. He knows he has an encryption of really just about anything and he has some hash of the key but unclear which function was even used. But we can connect this all with AWI proof. And here's what the statement that Bobby proves to Alice. And she says, hey, if that thing that I gave you, that Cypher text actually was the Sudoku solution that you wanted, then I'm proving to you that the Y that I gave you was the shot two image of the key. But if I gave you anything else in the world, if I just encrypted garbage, that's going to be shot three. And by a very reasonable assumption that shot two and shot three are what are called claw-free functions, we assume that if Alice can only know one pre-image of the function, she can't know both a shot two of Y, sorry, she can't know both a shot two image and a shot three image of Y. So, Bobby goes ahead, I'm sorry, yeah, Bobby goes ahead and sends Alice that proof. And now Alice goes ahead and uses a hash lock transaction and says, okay, I'll pay Bobby the money if she reveals a shot two pre-image of Y. And in particular, because of the proof, Alice knows that the only way that Bobby can reveal a shot two pre-image of Y is if she actually encrypted the correct Sudoku solution. So this protocol, we added some weird machinery where we're kind of switching things up. At the end of the day, it works very similar way because at the end of the day, the only way that Alice is convinced that if Bobby encrypted the solution, she will know the shot two pre-image and she'll only know Bobby will only know the shot two pre-image if she encrypted the correct solution, so it works as before. And Bobby goes ahead and says, here's the key, she gets the money and Alice gets the solution. But notice, so what are we actually doing our protocol? What was the point of all that? Now, witness and distinguishability is enough because whereas before, the only valid witness to this proof was a single Sudoku solution, so there was only one solution, so WI didn't help us very much. Now, anything in the world is a valid witness. You can literally encrypt anything and give a proof and it will go through. The point is that if you encrypt the wrong thing, the output of the function will be different, but the output of shot two and shot three are we're assuming they're not distinguishable and therefore there are many, many, many witnesses to this proof and now WI is enough. And the nice thing is, and the reason why we embarked on this path, is the protocol now completes in once again the original less than one minute. So we get the subversion resistant benefits by using a WI and a bit of a funkier protocol and we are able to save all the heavy machinery of using subversion zero knowledge. The conclusions that I'd like to give for this talk and the main takeaways, well perhaps the most important thing is you must be careful when applying cryptographic primitives and ways for which they weren't designed. So even if something seems intuitively correct, like, oh, the buyer can just do the trusted setup and everything will work just fine, you have to be very, very, very careful and in particular, if you're going to adapt a primitive for something that it's not used, you should go through the exercise, even if it seems like an exercise of utility of actually figuring out a security proof of your protocol because if that would have been done, these attacks would have fallen out. As a second conclusion, subversion zero knowledge reduces our reliance on SNARK's trusted setups and even though they're expensive, it's expensive to include subversion zero knowledge techniques. In some cases, like in Zcash, they're really, really appropriate, don't add much to the big picture in terms of cost and you get a lot of benefits, such that your zero knowledge or in Zcash, your anonymity, doesn't require any trust. And the third takeaway is witness and distinguishability is a weaker form of zero knowledge and in the ZKCP protocol, it allowed us to fix the protocol at a minimal cost and also, I didn't go through the details here, but I'll just mention that besides for just fixing the original Maxwell protocol, when you move over to our protocol, there is a whole new class of applications that are now achievable and realizable with this protocol, but I'll defer to the CCS paper for those details. Thank you very much and I'm happy to take any questions. We do have time for a question, so go ahead. Thanks a lot. So, I'm a little, can you go back to 62? Sixteen? 62? Oh, yeah, sure. Yeah, great. So, I'm a little worried here that Bobby, if she can cause Alice to burn his money by actually giving him a bogus solution. So, this is the detail that I left out of the proof, but included in the actual protocol as we implemented it as well as, and this is something that you can do on the Bitcoin blockchain, is there's basically a refund. You can pay a time lock in your transaction. It says if the money is not claimed after this amount of time, the money Alice can now claim the money back himself. In practice, I'll give the correct caveat that with the fee structure today of Bitcoin, including these transactions, even if you get a refund, there's a significant burn of money, and that's true. We're not taking fees into account, but for the basic money in the protocol, you will get a refund. Right, thanks. Sure. Any other question? So, in the original talk, I actually talked about buying physical items first, and the example was Alice was buying makeup from Bobby. Bobby is Bobby Brown, who's a makeup designer. One of the most famous female Bobby that I could find. Okay, so let's thank Stephen again. All right, and this concludes the cryptocurrency and blockchain session, and about don't go away. I'm going to, Adam Bonet is going to pick it up from here, and we're going to move to the left-hand price session. All right.