 We'll try to show up to 25 minutes. Okay, perfect. If you end earlier, if you have some time for questions. Okay. It's up to you. So, hello, everyone. Welcome our next speaker, Sofia Tseli and Ola Bini. And they're talking about no evidence, communication, and implementing a protocol of the record protocol version four. Hello, hello. Thank you very much. I'm Ola. And, yeah, as we just said, we're going to be talking about OTR version four. I think we might be winning a prize for the longest title. We are actually here from an NGO called Centro de Autonomia Digital in Quito, Ecuador. So, we have come pretty far. And we're super happy to be here. Both me and my colleague, Sophie. Okay, hello. My name is Sofia. And as Ola said already, the title of the presentation, I think we don't need introduction around that. But we also wanted to talk a little bit about, in this talk a little bit, why we need the secure messaging and why is this a problem until this day? So, for these, we first wanted to start with a quote of one of the most famous papers in cryptography by Philip Rogaway, which is called the Mora Character of Cryptographic Work. And he states, most academic cryptographers seems to think that a field is a far and deep and political neutral game, a set of puzzles involving communicating parties and notion as adversities. This patient of who we are animates a field where the work is intellectually impressive and rapidly produced, but also quite in breadth and they're both from real world concerns. It is what cryptography should be like, is this is how we should spend the bulk of our intellectual capital. The reason why we decided to put this quote here is because when we are trying to design a protocol, a cryptographic algorithm or primitive or whatever it is, or actually trying to implement it, we oftentimes forget that we are making this for real world users, for people who are going to use it. And sometimes the reason why we create cryptographic algorithms is because they mean the difference between the life or death of a political activist or a journalist. Something that Philip Rogaway continues in his paper is that while the cryptographic community have researched a lot around all the kinds of ideas, they have a little bit not researched so much onto the secure messaging sphere. And we think this is something that we should start thinking in a more crucial way, because one of the reasons why people use the Internet and use the digital world is actually to communicate with each other. They use chat, bloopers, email, and those are all forms of communication. So given users, clients that are actually not secure is something that we shouldn't do because actually that's what people are using most of the times. Around this, of course, we also wanted to talk about why we need protocols because of course you can have a secure chat messaging application, but if you don't state to the user exactly what is being used, then it's no use for them because they don't know exactly what kind of software they are being given. We need protocols because we need options that actually work. We need to show to the user actually what is happening, what cryptographic algorithm is being chosen, why it's been used, why it was chosen this way. We need further specification because it's not enough to say that we use elliptical cryptography, we use a certain algorithm. We need to state exactly how we use that elliptical cryptography, how we're taking into account several configurations that elliptical cryptography takes into account. I don't know, cofactors, issues, timing issues, side channel attacks. We need to also state exactly how different cryptographic algorithms interact with each other. It's not enough to say that you use the double-ratchet algorithm in your protocol. It should be stated how the double-ratchet algorithm works with the other algorithms your protocol has. We also need predictability, limitations and requirements. Of course we need that because we need to define to the user exactly what we are giving them. If we're going to give a protocol that says that we are giving them an end-to-end point security, then of course we should state in what manner we're giving this. If we're going to say to a user that we're going to give them the ability properties, then we should state which kind of the ability properties and in that what way. We should also tell them the limitations that our protocol has. For example, in UTIA before, we have the limitation that we don't use any post-quantum algorithm because actually any of the post-quantum algorithms that have been chosen by one of the candidates by the NIST competition has not been actually implemented in a worldwide way. We shouldn't strive to create a protocol that says it has a post-quantum algorithm when none of the post-quantum algorithms that exist right now can be deployed at a worldwide scale. We should also state to them which requirements do they need in order to have the protocol. We also need protocols that update existing definition because baked terms get better defined. In the cryptographic community, you don't have a term that is well defined but years later you will have it defined so you always need to update protocols. The reason that a protocol doesn't mean that it's the best protocol is the last word of a protocol. It just said that it matches up with existing cryptographic literature that exists at that point. Of course, we need reviews and verifications. We need ideas from different places and we need implementations. This is so related because we need a protocol not to say that I created and it should be perfect because I created. It should have reviews and verifications from other parties, from different parties, from the software developers, from implementers, from the cryptographers, from the security experts, etc. We need ideas from different places and this is something that we try to emphasize in OTR before because it's not enough to say that we have protocols that often times always come from the global north. We also need solutions that come from the global south because if you're giving a software to the whole world, then the whole world also means the global south. This is something that we're also very proud to actually OTR before was mainly developed in Brazil and Ecuador. And yeah, we need implementations because if you're developing a protocol, then of course you need it to show that it actually can be implemented. So actually, going back to two points that I think I really want to emphasize and the first one is that this question of specification is quite interesting. It's about the specifications that underlie the applications that are used today. For example, a typical example would be signal. If anyone tried to implement the signal specification, you will find that actually exactly this is a real problem. It's actually really hard to implement signal and as far as I know, most of the people that have tried to implement signal ends up using one of the existing implementations because the specifications that are out there simply doesn't give enough information to specify it. And another part of this is the reason why we need the properties and limitations and requirements really deeply specified in the specification is that we want it to be possible for the academic community to review the work we have done. And if we don't specify what properties we're actually seeking to achieve, if we're not specific enough about these things, it will be very hard for the academic community to look at the work we have done and tell us what it's set out to do. And this is also one of the things that you will find if you look at the security audits and reviews of many of the existing programs and systems out there, such as telegrams, such as signal, and many other, that actually it's hard for the academic community to contribute because they can't actually look at the specifications and see what they're trying to do. Half the work that academics have to do, researchers have to do is to look at the implementations to see, wait, okay, they say, you know, forward secrecy here, but actually they mean something completely different. And at the end of the day, that makes it much, much harder and the barrier to entry for review much trickier. So, we forgot to say in the introduction we should have mentioned that we're actually, like we're leading the current team implementing OTR version 4 as well, so we're representing the full OTR team and we're implementing it. Now, we've talked about a bunch of stuff and maybe we should actually talk a little bit about this. So, OTR is a protocol that stands for off-the-record messaging. It was created in 2004 by a team of academics, Ian Goldberg, Nikita Bortasov, and Eric Brewer. And the idea was that basically when we're having a conversation in the real world, assuming that there are no recording devices, we can have a conversation just me and another person and you and I, we know that we were talking to each other but we know that the other person said what they said but there is no way for that other person to go away and claim to a third person, hey, Ola said this and prove it. Of course they can say that I said something but they can't actually prove it. However, in our current world we have two different situations. We have situations where plaintext is being thrown around and of course plaintext means that anyone can read it so there is no privacy in those conversations. Or we have situations like with PGP in a way that means that anyone can forward a signature to someone else and at that point it becomes very, very hard to deny that you said anything. So the idea of OTR is actually that we want something that takes back this middle ground. We want conversations to be like in the real world instead of making them more problematic by giving more evidence that something actually was said. So OTR gives you authentication meaning that we know who the other person is that we're talking to. It gives you encryption so that we know that someone else can't actually intercept what we're talking about. And the authentication is done in a deniable way and we're going to come back to deniability in a second. In version two there was also another kind of step forward introduced called the socialist millionaires protocol that allows us to actually verify that the other person is who we think they are by using another means of comparing fingerprints. Now comparing fingerprints is still possible but S&P is also another way of doing authentication. Now OTR, since OTR is quite old was kind of a trailblazer and inspired many other protocols because this idea of combining authentication with deniability was quite new at that point in time. And we are now in a situation where OTR version three has existed for roughly eight or ten years and at that point we decided a few years ago that version four needed to be created for a lot of reasons. We're going to come back to the reasons why. So basically we have three different parts of this that I've already talked about. We have authentication in OTR version three it's using an authenticated key exchange using a variant of something called the sigma protocol which is a combination of signatures and max to be able to do this deniability. And then we have S&P and fingerprint comparison and finally we have end-to-end encryption where all messages are encrypted but all messages are also authenticated in a deniable way. Okay. Okay, so around the properties that OTR in general wanted to attain. So of course OTR wanted to attain forward secrecy which means that you should be unique with encryption of its message. Yeah which is breakback work protection which means that forward secrecy is quite related to post-compromise security or what was called in the past workware secrecy which means that even if you compromise one of the message keys one of the unique keys that was used in crypto message you will not be able to decrypt previous or future messages. And why is this important and why does the academics that created OTR decided to have it because of course for example in PGP if you get hold of the long-term secret key then people will be able to actually decrypt future and past messages. And we didn't want to have that in OTR so a lot of people decided that there will be unique keys for each message and if you get hold of one of them then you will not be able to decrypt past or future messages. This is post-compromise secrecy which I already talked about. Of course and then of course what is OTR mainly known about? OTR is mainly known about the thing called inability as all of us already said it is important property and why it is important to have it in a digital world is because in real conversations you have this property granted by default no one can actually said that you said anything unless you are recorded by video and audio on most countries not on all countries but on most countries you will have to get you will have to accept that you will be recorded by video or audio if you are saying something into a conversation. But we don't have this in the digital world because actually over the world when you use the internet you always recorded some data will exist that will link you to a certain conversation and we don't want that. So that's basically the inability in the terms of OTR well it's a common goal for secure messaging consider us in the area where both accusers are sending a specific message just in the judge must decide whether or not he believes that Alice actually did so if both can provide evidence that Alice sent the message such as a biocryptographic signature of the message under Alice long-term key then we said that the action is non-reputable. Of course it happens in GPG because you actually authenticate the message and anyone can say oh this digital signature is actually linked to your identity so whatever you said in this is actually you. We don't want that in OTR. In OTR what we want is that you will have the same identifications you have in GPG but in a way that you can also deny it. There's different types of the ability and this is something we wanted to update it in OTR. We have online offline message and participation the ability are the easiest to explain because that actually means that you can deny having sent a message or that you can deny having participated into a conversation. Now only in an offline denerability are quite interesting in the sense that offline denerability is the classical denerability we knew from past versions of OTR basically means that after a conversation has happened you can actually deny having sent anything because anyone could have forged a script afterwards. Owned denerability is a new property that is quite important in the sense that during a conversation someone can actually try to collude with you in order to make someone say something for you. So for example something that actually happens for people like me that come from the global south is that you will go to a border and a patrol of the border and an officer of the border will actually try to surrender your phone and unlock it. What they often do is they open up your chat application and start messaging with someone else. This is actually colluding with something you have on your phone to make someone say something that they otherwise would not say. So for example let's say that I'm an activist and the border is surrounding my phone and they started to talk to other activists so they can get information about the situation and they can get later prosecuted. So actually giving on-lending ability means that during that moment that person actually has during that moment approved that he actually can deny whatever he said during that moment not after the conversation ended. Okay so why version 4 as we mentioned already there is a bunch of stuff in OTR version 3 and everything we've said up until now is in version 3. The biggest difference when it comes to deniability just to make this clear is that OTR version 3 does not have participation deniability and version 3 does not have online deniability. Sophie just explained online deniability and it's a little bit of a strange concept. It takes a while reading through the papers to understand what it actually means. Participation deniability is a little bit more specific but you cannot deny that you had a conversation. So if I've had an OTR conversation with Sophie using OTR version 3 there is digital proof that I actually had that conversation but there is no digital proof that can't be denied that I said anything specific. Now in some cases this can be important because in some cases having a conversation with a specific individual might be dangerous or might be something that you can be prosecuted for. So all these types of deniability we've already talked about forward and post compromise secrecy these are very important properties that every single property like if you don't have a very specific reason to not have them every protocol should have them this is actually really true like forward secrecy the last five years has become accepted in most of the world until S1.3 if I remember correctly actually deprecates the key exchange to secure which is great. It's a great step forward but post compromise secrecy and secrecy is also an important property. We want to create a higher security level. OTR version 3 is roughly at a level of 80 bits and that's primarily because of the DSA keys used that use 1,536 bit Diffie-Hellman key as the main key and that's simply too low for comfort at this point. So we are raising the security to 224 bits we also needed to update some of the other cryptographic primitives like OTR version 3 has Shaw 1 in some places using classic Diffie-Hellman it's using DSA all of these algorithms are not really a great fit for 2019. We also have this a little bit weird situation where we really want elliptic curves because elliptic curves are great at the same time elliptic curves are not so great because there are specific so assuming that quantum computers arrive and assuming that they arrive and it takes some time in how they progress in terms of speed of breaking cryptographic algorithms you can get into this weird situation where elliptic curves will be faster to break than Diffie-Hellman classic Diffie-Hellman and the reason for this is because they are relatively smaller than classic Diffie-Hellman so assuming that the progress of creating qubits is slow enough we actually could be in a situation where elliptic curves could be broken five years before classic Diffie-Hellman so we have also added what we call this like limited quantum computing transcript description which kind of helps a little bit for a few years hopefully assuming some of our assumptions are correct and yeah we also need a new communication model when OTR was created the first plug-in for OTR was created for a chat line called Gaim I don't know if anyone remembers it, that was the previous name for Pigeon and in 2004 that was kind of like great there were many protocols and you could run OTR on top of any one of these protocols all of these protocols had a few things in common meaning for example all of them were in order in general you could be okay with everything being online in our world right now a lot of people use cell phones and a lot of people come online and offline all the time and we have transports that are not necessarily guaranteeing in order so we need OTR to support out of order we needed to support offline conversations this has some consequences offline conversations lower some of the security properties specifically when it comes to online deniability it's not much but it's slightly different and if you want more information it's all in the specification for that we also have different modes which means that for people that really want the highest secure version of OTR there is a possibility of implementing that specific restricted mode that actually allows that and then finally OTR has always been serverless OTR version 4 will require servers if you want offline capability for online capability you don't need servers but for offline of course you need to trust a server to some degree actually this is an interesting situation because obviously if you're going to send an offline message there has to be some kind of server to store that message we don't really trust these servers we're using a pre-key model that is quite similar to what signal is doing so the server is only trusted to store these things and then give them out when someone is asking for them so this server is trusted to not be an asshole and do denial of service but except for that it's not really trusted because it can't actually do anything else all of these messages are signed and there is no way to actually attack a user using these pre-key messages okay just a little bit about the design which I will go very fast because we don't have a lot of time so yeah we use the Neville Authenticated Key Exchange what does this mean this basically means that you will have a way in which you authenticate each one of the parties in the conversation the two parties in the conversation but in a deniable way we use for these two primitives that are called XZ and XCDH the first one for online the second one for offline of course we use elliptic curve cryptography and we use ED448 Goldilocks why we decided to use that and not Daniels Bernstein's 25519 we decided to go with my Hamburg Curve because it gave us a higher security level the one that we needed we use also a DvHelman of a size of 3072 because as all already said we wanted to also have like a little bit of extra security in case that elliptic curve cryptography gets broken faster with a quantum computer we decided to use shake and also excelsa shake as the hash function excelsa as encryption algorithm we use the double ratchet algorithm to derive the unique message keys per each message and of course we have already talked a little bit about this why we didn't want to post quantum algorithms of course we also have a thing that is called the toolkit the toolkit is basically a toolkit that actually proves that all of the deniability properties are actually happening why we don't want group chat because we wanted to attain certain deniability properties and right now all of the cryptographic literature has not really attained that deniability properties in a group chat setting so I just want to expand on the toolkit for one second you will find a lot of people talking about deniability and there are specifications out there to talk about these properties in the abstract that's not really good enough the idea of the toolkit is to give you a command line tool that will allow you to forge messages basically the idea here is that we don't just say in the specification hey it's possible to forge messages we make it so you have a command line tool that will allow you to forge messages as simply as using the tool itself so we can actually show this is actually true anyone can do this and by having this toolkit we're putting it into the real world that anyone can forge messages and that this deniability we're talking about is not just academic it's real world and anyone in this room could pick up the toolkit and forge messages for anyone else it's great fun okay real world implementation super fast of course we're doing the implementations that we first did of OTA before we did it in C and of course implementing something in C has its thoughts we also need during the implementation also the design of the protocol we also collaborated along with all of the cryptographers with Ian Goldberg, with Nick Unger, with Mike Humber because we sometimes we didn't know exactly about some cryptographic algorithms so we needed some kind of advice on that as I said we implemented in C, while in C most of the libraries often times the protocols get implemented in C so later all the libraries in other programming languages can actually be implemented by having the inspiration in C of course working in C has its problem of course you have the memory handling so we have to be very, very careful with that we used a lot of compiler flags a lot of address sanitizers from the LLBM foundation of course we did a static testing client ID and we used Splint, we used Balgrind and various sanitizers but something that we also tried to incorporate is the idea of the code that has to be readable because sometimes on libraries what happens is that code is a huge spaghetti code and we try to create actually a code that can be readable and that people can later use it as inspiration to implement it in whatever all the programming language should we jump to the questions and I'm very sorry but we run out of time so questions in the meantime links whoa sorry here yes links for anyone that wants to look at the source code and I think maybe we would have time for maybe one or two questions maybe do we have benchmarks in terms of peer-to-peer messaging protocol for example well okay so first of all we do have messages for sorry we have benchmarks in the paper for the AKEs because the authenticated key exchange are kind of the most significant part of this they're much more costly and how much time they take the paper from Nick Unger that actually establishes these has benchmarks comparing lots of the different existing dates in terms of operational costs in terms of sizes we know how big the messages are going to be that's easy to calculate I don't have that in my head and in terms of the actual ratcheting algorithm the ratcheting of each for each message is quite inexpensive in general I don't have numbers in my head right now but it's quite easy to find out and that's something that we should definitely do of course we also have the benchmarks of the library of the elliptic curve that we use in by my Hamburg he already has benchmark from what I remember and one of the reasons why you use the elliptic curve cryptography is actually because this is faster than you say our large prime so by giving the same security level that we wanted to attain so it's a little bit faster for us in that way and we're out of time thank you