 Hello everyone. So I'm going to introduce Nadim. Hello. Okay. Thank you very much. So I'm going to be talking about Verif Pal, which is a new framework for the cryptographic for the analysis of cryptographic protocols. So you guys use TLS, right? HTTPS, Signal, Kerberos, WireGuard, OpenVPN, IPsec, Fido, MQTT, all of these protocols tend to have some encryption in them. And it's important to verify the security of these protocols because there could be bugs like, you know, TLS 1.1 had bugs and then TLS 1.2 had bugs and then TLS 1.3 was the first version of TLS that was actually produced in collaboration with people who work in the formal analysis and verification of protocols in order to eliminate bugs during the design phase and not during the production phase. So formal verification is a technology that's existed for a while where you can use software tools in order to analyze protocols like TLS and Signal to determine whether they actually achieve the security guarantees that you expect them to achieve. And turns out that protocols can behave in unexpected ways. And that's why this has been a very interesting and productive field with many different types of tools. For verifying primitives and implementations, there's a different set of utilities. But today, what I want to talk about is verifying protocols and not primitives or implementations. So when you want to verify a protocol, generally speaking, you do something called symbolic protocol verification. The main tools for this for the past 10, 20 years have been Proverif and Tamarin. They've existed for a very long time. Proverif has existed for almost 20 years in one form or another and Tamarin has existed, I believe, for at least 10 years. And the way that you use these tools is that you basically write a model of Signal or a model of TLS. Like you describe what cryptographic operations happen and for example, we can describe a model where a Signal session exists where Alice sends a message to Bob and Bob responds and Alice responds again, or TLS 1.3 between a server and a bunch of clients and so on. And then we can ask the verifier questions based on the model. So for example, in this model of TLS, are the clients authenticated to the server? Is the server authenticated to clients? Or can an impersonation happen? Are the payloads confidential against an active attacker? And then the verifier will try to find contradictions. So this is great, right? It's been used to analyze and papers have been published in the past four years at top-level security conferences on formally verifying and finding attacks in Signal, TLS, noise protocol framework, Scuttlebot, Bluetooth, 5G, and these papers, you know, they're really well received. Sometimes they win awards and so this is like a great way to work and it allows practitioners to reason better about their protocols before or as they are implemented. So why isn't it used more? Well, it's these tools tend to be really specialized. They tend to be focused made by academia, for academia, and while they are really advanced and correct and excellent, one thing that isn't a particular priority for them is sort of intuitiveness of the language. So in the top two most used and advanced tools, you can't even really intuitively describe a protocol or intuitively describe what Alice is doing, what Bob is doing. Certainly in Proverif there's no notion of principles. There's just, you know, stuff that happens in the void and somehow a protocol emerges. So the way to describe these things is very unintuitive in my view. And that's why VerifTile exists. So it's a new software project. The first alpha version was released four months ago and there's been a lot of development since then and it's become, it's not in beta now. And VerifTile is really cool because it separates itself from other formal verification software for protocols in four ways. So we have an intuitive language for modeling protocols, but that can, like, you know, it's an intuitive, easy to understand language, but you can still reason about advanced protocols like signal and noise. So it doesn't sacrifice the ability to reason about really advanced protocols. Modeling that avoids user error, analysis output that's easy to understand. You know, if you try to analyze a protocol in other tools, you might get this attack trace, which is, like, you know, 30 pages long and difficult to understand. And VerifTile, it speaks to you in English, so you can understand what's going on. And hopefully I'm also, this isn't, doesn't really exist right now, like other than a Visual Studio Code extension, but I'm also hoping to integrate it with the developer's workflow. And you can, you know, analyze for advanced security properties like forward secrecy, which is something that you might be familiar with if you use signal. And also it has features like fresh values and bounded sessions. You know, you can analyze every single possible execution of a protocol. And so here's what the language looks like. As you can see, so there's a really simple example on the left and on the right, they're just a graphic representing what it's like over the network. So, you know, we declare the attacker, we're declaring an active attacker, and then we declare the principles Bob and Alice. Alice generates a private key, calculates a public key, sends the public key to Bob, and then Bob generates a public key and encrypts a message to Alice based on his private key analysis public key. And so this is like the most simple possible Diffie-Hellman protocol, right? You know, Alice has a public key, Bob has a public key, they calculate a shared secret, and they send a message. Believe it or not, modeling this in other tools can be way bigger than this. Maybe not an example this simple, but if you want to get more complicated, something that couldn't be modeled in Verifpal in 100 lines would take maybe 500 lines or 300 lines in other tools and would not allow you to intuitively describe what's going on and also would need you to define the primitive. So you would need to define what encryption is, what Diffie-Hellman is. In Verifpal, the primitives are built in. So users cannot define their own primitives, and that's meant to basically remove a surface in which the users can make mistakes and define primitives incorrectly. I don't see a need to allow users to define their own primitives. And the library of primitives in Verifpal is always growing. So it started off with the obvious primitives, you know, hash, MAC, cert, HKDF, encryption, decryption, authenticated encryption, authenticated encryption, signing and signature verification, but also we added password hashing, Shamir secret sharing, public key encryption. Soon there's going to be OPRFs as well. And all of these primitives allow us to model interesting protocols. For example, we can declare values that are passwords, and then we can model them such that they're not secure to be used as part of an encryption key unless they're stretched first using a password hashing function. If you look at the Verifpal manual, you'll see that there's a full example of Verifpal analyzing signal. So I don't think it's worth it to go through these slides. But yeah, so you can find more information about how signal was analyzed in Verifpal on the website or in the manual. A lot of projects, well, some projects are using Verifpal. You can see the list here. There's also example models of popular software such as Signal Scuttlebot puts on Mail and Telegram. And also the Verifpal user manual comes with an entire Japanese style manga where Verifpal goes on adventures in formal verification and fights bad guys who are like trying to break protocols. It's a lot of fun. And I really like this manual because I honestly believe that if you want to learn about protocols and how they work and how to analyze them, I don't think that there exists any better educational material for beginners. I mean, for advanced people, there's definitely way better materials. But for absolute beginners, it's a really amazing manual. And I really think you should check it out and definitely recommend it to people who are just starting off with protocols and understanding cryptographic protocols and how to analyze them. So check out this manual. There's also a Eurocrypt affiliated event that might happen. So that will happen in May. So yeah, there's a very visual studio code extension. And you can try Verifpal today. So just very quickly, I'm going to show like a super quick demo. So this is what a Verifpal model would look like here on the left. You see like this is Verifpal. This is the Verifpal signal model. Oh, okay, thank you. There we go. Wow. Okay, well, you can certainly see it now. Maybe see it a bit too much. Okay, so there, then whatever white, okay, great. So there we go. So here you have the model and you can just basically go Verifpal, Verify examples and then it'll just do some analysis and try to figure out whether it can find attacks. And if it finds an attack, it will basically look like this. So this is a intentionally broken model of signal like, oh, if the attacker has the long term identity keys and is man in the middle of the ephemeral keys, then there's no forward secrecy. There's no confidentiality and it shows you like, you know, confidentiality is violated for the message. It violates, it's able to find a contradiction to the queries that we've described here at the bottom. And yeah, that's basically it. I'm happy to take questions and thank you very much for your attention. You can download it today for all operating systems, Linux, Mac OS, Windows, VBSD on the website. It's free open source software. And I also have stickers if you're interested, I can give you stickers. Are there questions in the room? Thank you so much for the software looks very interesting, especially compared to the older tools. So as, say, an engineer or software developer, I'm implementing a stationation of the signal protocol. So this would be useful for me to verify my implementation and so on, not as a new implementation of the signal, a new protocol. So for that, I would have to maybe do an extension and collaborate with you, but to verify the implementations, this would, I'll just take the existing Verif Pal cannot be used to verify implementations. Implementations are written in code. You need to model the protocol in Verif Pal's own language. And actually, it is very useful specifically if you're coming up with your own protocol. It is it's most useful for people who are currently in the design phase of a new protocol, or have doubts about an existing protocol. If a protocol is already very well tested, especially using tools that have existed for literally decades, there's really little point in modeling it in Verif Pal, except for educational purposes. But if it's a new protocol, an in house protocol, or especially if you're making modifications to a protocol to suit your own particular use case, then modeling in Verif Pal becomes very lucrative, because it's much faster. It allows you to get results way more quickly. And the complexity overhead of obtaining a result and insight into your protocol is infinitely smaller than other tools. Yes. So the direct advantage I see is exactly that the queries are simpler. Everything is simpler and more trivial in class, more secure. Thank you. Thanks. Do we have more questions? Hello. Thanks for the talk. I'm wondering how do we see the variables or the one that you called primitives? Are they variables or how should we see them? So Verif Pal has its own modeling language. And if you look at the primitives that are declared here, so essentially there's a bunch of keywords, and they're all listed inside the Verif Pal user manual. And each of them functions in a specific way. Like for example, you have an encryption primitive, decryption primitive, signature, there's a set of them that I think there's like 15 or 16 of them. And sometimes I add more. And each of them works in a particular way. And you can read the manual to learn more about what they do and how to use them. And there's a sort of standardized sort of set of expectations of how they work and how they're constructed. For example, when I define a new primitive in Verif Pal, I write it using a primitive definition language that's inside Verif Pal. It's not like just a random bunch of things. And they're basically just meant to represent common cryptographic operations, like public key encryption, symmetric encryption, some new secret sharing, password hashing. They're not particularly unintuitive. They're just standard cryptographic operations. So I think that I don't think Verif Pal will ever have more than 20 primitives, because I don't think there are more than 20 fundamental cryptographic operations. If you allow me as well, like, like M1, E1, the stuff like this, should we see them like as variables in the code or? Yes, yeah, totally. Yeah. All right. So these are symbolic representations. This is a symbolic model. So there's no notion of like addition or values. I'm just going to let the gentleman over here ask a question because he's raised his hand many times. The last question. Is there a way to specify elliptic curves or isogenes and protocols in Verif Pal? So when you're verifying things in the symbolic model, you're basically looking at the assumptions on Diffie-Hellman. It doesn't matter whether you obtain Diffie-Hellman using classical finite field Diffie-Hellman, elliptic curve, isogeny, learning with errors. What we care about is the core Diffie-Hellman assumption itself. And yes, of course, Diffie-Hellman is supported. And let's have a round of applause for the speaker. Thank you. Thank you so much. Thanks a lot.