 There is only one paper in this session and the title of the paper is Computer Aided Security Proofs for the Working Cryptographer. The co-authors are Gilbert, Benjamin Gregor, Sylvain Héro and Santiago Zanella Beguin. Gilbert is going to give a talk. This paper is the best paper award of the conference and I ask all the co-authors to join up on the stage after the presentation. Okay, so good morning. So we started on this work about five years ago when we came across two very exciting papers. One was by Shai Halevi and the other one was by Mihir Bela and Phil Rogaway. And basically they were pointing out that there is a problem with cryptographic proofs in the sense that they are becoming unverifiable and sometimes they might even contain some more or less grave flaws. And on top of pointing that there is this problem, they were suggesting a plausible solution which was using computer-aided proofs for making sure that proofs are correct. And so the idea of computer-aided proof is mentioned explicitly in the paper by Bela and Rogway and it's developed to a much bigger extent in the paper by Halevi where he actually suggests how to go and build on such a tool. And so the idea of using computer-aided proofs for verifying cryptographic proofs seems to make a lot of sense because actually when you go and, sorry, use computer-aided proof you can take an arbitrary mathematical theorem where mathematical theorem is understood in a broad sense and then you can turn it into a machine-checkable proof. So the first step is actually to convert the statement of the theorem into a formula that will be written in some formal system, for example, first of the logic, and then you have to build a machine-processable proof of the correctness of this result. So once you have done this, the person who wants to check the proof has to have a careful look at the statement of the lemma to make sure that what you state is exactly what you want to prove. But then once it's done you can actually rely to an automated tool for doing the checking. So in our work we're using the Cork proof assistant which is built at Inria in France for the last 30 years. So every time you see this rooster we will be talking about the Cork proof assistant. And because proof assistants are very demanding in terms of the justification you are making for the proof to be accepted, once you've got a formal proof you are sure that with a high degree of certainty that the proof is correct and moreover that the correctness is built from first principle. And so computer-aided proofs have been around for 40 years but there have been tremendous advances in the last 10 years and this is a sample of results that have been formally checked using proof assistant in the last few years. So one of the earliest results was the four-color theorem, proof maybe five years ago by George Contier at Microsoft. More recently there has been some work by Tom Hales who's working at the University of Pittsburgh on the Kepler conjecture. So he had the proof of the Kepler conjecture and he started to get a machine check proof to convince his colleagues that his proof was correct. And some more recently there was some more computer science oriented work for more proof of correctness of an optimizing compiler for C as well as some work being done on operating system correctness. So there was some work at Nikta in Australia on the correctness of the SCL for micro kernel and Microsoft has also a big project on the verification of its hypervisor. And since computer-aided proofs seem to be very successful in a broad range of area it seems quite a reasonable question to ask whether we can do the same with cryptography. And so after reading the papers by Hallevi and Belach and Hogaway and also a related paper on Shoop about using a game-based proof we got very excited and we started building a framework that would help doing a verifiable proof for cryptographic proof. And as is suggested in these two papers we adopted the code-based game-based techniques which brings us close to programming language which is in fact the area in which we are more familiar. And so we built quite an extensive framework that tries to provide support for the most common patterns of reasoning in cryptographic proofs. And we've been able to apply our framework to a number of examples including the full domain hash for which we could reconstruct the proof of Couron with the optimal bound with more recently with the proof of OAP. So initially we had a proof of NCPA but we recently completed a proof of NCCA2 following essentially the proof by David Poinscheval in his Barcelona notes. More recently we did some work on the Sigma protocol proving basic properties of the Sigma protocol as well as some basic composition result. And our latest result is a formalization of the Bonnet Franklin basic indent identity-based encryption. So all this works collaborates corroborates the plausibility of building machine checkable cryptographic proofs. But on the other hand it requires a very high level of Koch expertise and a lot of time which means basically that it is most likely out of reach for people who don't really have a lot of experience in using Koch. And this is kind of an issue because you might want to spend a lot of time and a lot of energy and become a real expert if you want to prove the four color theorem or if you want to prove Kepler conjecture. But the idea of doing computer-aided cryptographic proof is that you can use this tool again and again when you design new scheme to make sure that your security proof is correct. So it doesn't quite fit the job as was initially stated in the papers by Hallevi and Belach and Rogaway. And on the other hand because we are using this code-based technique, essentially when you verify a cryptographic proof you're doing some form of program verification. Maybe it's a non-standard form of program verification but it's still program verification. And there has been tremendous advances in program verification over the 10 or 15 years to the point that program verification these days is something which is essentially automatic. And so when you do proofs using Celtic Crips the proof on automatic and what we would be aiming at is to try to be able to exploit state-of-the-art program verification tool in such a way that if you want to check a cryptographic proof essentially you will be almost automated. And so the main result we present in the paper is a new tool which is called Easy Crypt and which acts as a front-end for the Celtic Crypt framework and which provides computer-aided security proof with the same level of guarantee that was available with Celtic Crypt but you can complete proofs with moderate effort which is very important and also using off-the-shelf tools which is also very important because you can take advantage of all the advances that have been made in the program verification field to build your cryptographic proofs. So how does it work? Well so the idea we had when we started building these tools is that we wanted to take a game-based proof as it appears in the literature and we wanted to add as little to it as possible so that it could become verifiable automatically. And so on the screen you can see a sequence of game that proves semantic security of Hashtag Gamal in the random oracle model and so the sequence of game is standard. You go from the original game to game one by inlining the code of key generation and encryption algorithm. Then the transition from game one to game two is essentially an application of an up-to-bad step where you replace the call to the random oracle by a random sampling in the third line starting from the bottom. The next step from game two to game three you apply padding so that you can replace h, xor, and b just by h by the fact that h is uniformly sampled. And then the next the final step from game three to lcdh is just a reduction step where you construct the adversary b which is well behaved. And so when you go and see a game-based proof essentially you see a sequence of game and somewhere in the middle of the text you actually also see a number of equalities or inequality that we relate the probability of an event in the first game with a probability of an event in the other game. So in the first game this is just a bridging step semantics preserving so you keep the same event and you show the probabilities are equal. In the second step it's an application of up-to-bad so you are actually bounding the difference of probabilities in the first and second event by the probability of the bad event for example in the second game. And so you keep on for each transition giving these inequalities and once you have them it's a matter of simple calculation to come to the final conclusion which relates the probability of the adversary winning in in cpa to the probability of the adversary b winning in the lcdh game. And so ideally you would like just to be given this this is a formal object because each game is a program and each fact is a mathematical statement and output approved for this. Well we don't quite know how to do this yet but what we do is that we introduce some intermediate step where for each inequality we introduce some program verification task where we essentially here this is a relational judgment in relational logic where we say that if we execute the in cpa game and the g1 game after executing the game the event b is equal to b prime has the same probability in the two games. So in a way it's closely related to the equality that we had initially but it's cast in a relational logic which is a framework which is much closer to what is being done in program verification. And so for each transition you do this you just give a statement in a relational logic that closely resembles the qualities or the inequalities that were given for each fact. So for example this is the statement of the up to bad lemma in the logical form it essentially says if you look at the right of the implication on the first line it says that g1 and g2 are equal up to bad and then the second line say that until yeah sorry and then the second the second line say if that does not happen then b is equal to b prime coincide in both games. And so you just keep on repeating this for each transition and then once you have this if you're able to perform the verifications that are given in the red box you essentially can build automatically a proof of the security. And so what is important is that this might look quite complicated to you but remember there is a distinction between the guy who built the proof and the guy who checks the proof. If you're only interested in checking the proof you just need to look at the first game the final game and the statement the sequence of intermediate game is gone. So if you go to more complicated setting maybe it will be slightly different you won't have only the final game you will have all instantiation of the security hypothesis but essentially what matters is that most of the proof goes away. Checking the statement is much much simpler than checking the whole proof. Okay so now let's look at how EasyCrypt verifies such a statement. So essentially we're using pretty much the same techniques of our program verification except that there are some small subtleties. So we are dealing with probabilistic programs with adversary and we have to deal with this. So how do we go? Essentially what we're going to do is go from the post condition which is the formula that is at the right of the implication saying that b is equal to b prime coincides in both games and we're going to push it upwards. So how does it work? First we take the code of the oracle so the key generation and the encryption oracle and we inline the code. Then we push the random sampling up front at the beginning of the game. This is not the only strategy there are other strategies but for our purpose it works very well and then we can so this is kind of a preprocessing phase and once we have done this we start pushing the formula on the right of the implication backwards. So how does it work? Well the first thing we hit is the code of the adversary. So the adversary of course is just unspecified we don't have a code for it so the way we proceed we have to do some form of modular reasoning which is common in the program verification work and we are just inferring an invariant for the adversary saying essentially the adversary behaves the same in the two games or if it's an up to bad transition we say the adversary behaves the same in the two game unless bad happens and then once we've gone through the adversary we keep on pushing again the formula so we have to do the same thing for the adversary a1 but at some point we will reach a piece of code where we only have random sampling and so to deal with random sampling the difficulty here is just to remain in the fragment of the logic that can be handled by the automated tool we're using and the way we do this is that we provide as a witness a bijection that satisfies certain properties if you want to look at the technical details that are in the paper I will not talk about what the bijection is meant to do here but the important thing is that once you are given the bijection you can process the formula backwards until you reach a first order formulae and what you have to check is that the precondition which in this case is true and which is what you assume to be valid about the initial memories of the program implies the formula which you have computed and this is something which actually can be done automatically with some existing tools so in our work we've been using altergo and simplify but what we have built is actually connected to many other tools so you can use your favorite SMT solver and so if we really look at the code how does it look well pretty much as what I wrote here so this is actually an extract from the 30cript script so we use the keyword rest to say that b is equal to b prime is equal to the two game but if you look at the second line which is where the commands are going you say undoing inlining undoing derandomize which actually corresponds to eager sign sampling then auto means well finding variant for the adversary pop is actually the way to give the witness or pop and repeat random and then trivial is just checking the vc okay and so once you have done this you have proved this fact and then so what you are left to do is just to prove that this fact entails the equality and this is fairly easy in this case because this is just a standard transcript if you do some up to bad transition it might be the case that actually it's not an equality but it's an inequality with some constant factor and then easy crypt is providing some support to checking that the constant factor that you're providing is actually the correct one okay and so we have been able to implement in easy creep many of the techniques that are being used by cryptographers so for bridging steps failure events reduction step and on top of it we have been able to generate automatically from easy creeps proof proofs insert secret that can be checked independently using the code proof assistant so we essentially achieve our design goal and in order to prove the validity of the approach that we've been developing we've been building a proof of the Kramerschup encryption system so proof of security is given in the shy Hallevi paper for the Kramerschup encryption system and we actually follow the same proof and achieve the same bounds it's a sequence of 10 games which essentially corresponds what is in the proof by Hallevi it's about 1600 lines of easy crypt plus 100 lines of cork because cork is better is able to use sorry to handle field equation much better than smg solver so we prefer to do the proof in cork so if you look at the table here it's actually giving an indication of the difference of size improves between such a crypt and easy crypt sometimes it's a bit of a cheat because we're redoing example which we did the game but essentially we've been reducing size significantly in the proof script so if you do a proof in such a crypt maybe all the indications you have to give to build the proof is twice as long as the sequence of game while here it's 20 percent the size of the sequence of game so it's much more compact you need to do less work the development time of a proof is much faster and the learning time is much reasonable i mean such a crypt is not really usable from somebody who's not using cork easy crypt is much more easily usable so which is a good news and so to conclude easy crypt is a new tool that allows you to do computer assisted security proof with moderate effort using off-the-shelf tools so you can reuse technologies and advancing technology it's producing independently verifiable proof and it works for a challenging example and so in the future we want to distribute the tool so we were hoping to distribute it before the conference but some of us have been on holiday so it will be on this site sometime during this week we want to improve and extend the tool there are many nice techniques from programming languages that can be embedded there and we want to do more example so we started to look at the proofs of collision resistance and indifference ability for SHA-3 and we've also extended the underlying infrastructure to reason about differential privacy and we might want to lift it up to easy crypt and so that concludes my talk thanks for your attention it's brief time for some questions please um so that actually in the proof I mean they are not serious flows but so in the proof of OAP we found some small adjustment that needed to be done in the sequence of proof in order for the proof to get through but like I have to say that in this kind of business as our goal is not really to find big flow we I mean it's a lot of effort and if you do all this it's just like to try to get the proof right I'm not claiming this is the best way to find the flow this is a good way to make sure that there is no flow okay one more question please no let's join me in thanking the speaker I invite all the co-authors to join us on the stage please the best paper award was selected by the entire program committee and despite a plethora of wonderful contenders the this particular paper overwhelmingly overwhelmingly won program committee members praised it for its widespread appeal its connections to an apparently distant area from cryptography programming languages and for its potential to one day be transformative please join me in thanking the the authors