No evidence of communication and morality in protocols: Off-the-Record protocol version 4

Video thumbnail (Frame 0) Video thumbnail (Frame 1091) Video thumbnail (Frame 3371) Video thumbnail (Frame 5301) Video thumbnail (Frame 8181) Video thumbnail (Frame 10695) Video thumbnail (Frame 12328) Video thumbnail (Frame 13991) Video thumbnail (Frame 15074) Video thumbnail (Frame 16290) Video thumbnail (Frame 17514) Video thumbnail (Frame 18470) Video thumbnail (Frame 19702) Video thumbnail (Frame 20596) Video thumbnail (Frame 21788) Video thumbnail (Frame 22966) Video thumbnail (Frame 23822) Video thumbnail (Frame 25460) Video thumbnail (Frame 26626) Video thumbnail (Frame 28374) Video thumbnail (Frame 29255) Video thumbnail (Frame 31030) Video thumbnail (Frame 32185) Video thumbnail (Frame 33916) Video thumbnail (Frame 35068) Video thumbnail (Frame 36423) Video thumbnail (Frame 37774) Video thumbnail (Frame 38879) Video thumbnail (Frame 39854) Video thumbnail (Frame 41005) Video thumbnail (Frame 41947) Video thumbnail (Frame 42860) Video thumbnail (Frame 44182) Video thumbnail (Frame 45554) Video thumbnail (Frame 46571) Video thumbnail (Frame 47689) Video thumbnail (Frame 49522) Video thumbnail (Frame 50748) Video thumbnail (Frame 51790) Video thumbnail (Frame 52905) Video thumbnail (Frame 54759) Video thumbnail (Frame 55607) Video thumbnail (Frame 57002) Video thumbnail (Frame 58596) Video thumbnail (Frame 61269) Video thumbnail (Frame 65840)
Video in TIB AV-Portal: No evidence of communication and morality in protocols: Off-the-Record protocol version 4

Formal Metadata

No evidence of communication and morality in protocols: Off-the-Record protocol version 4
Title of Series
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date

Content Metadata

Subject Area
OTRv4 is the newest version of the Off-The-Record protocol. It is a protocol where the newest academic research intertwines with real-world implementations. It is also one of the first protocols that comes from the global south which makes the political discussion around protocols an urgency. This newest versions also asks us to revisit our definitions around deniability (online and offline) and how important is it to the world. In this talk we will try to start a discussion around the importance of protocols, its political/moral foundations, the real-world implementation of academic ideas, the importance of securely implementing them, the definition of deniability in the current world and the design of OTRv4.
Keywords Resilience
Revision control Telecommunication Encryption Musical ensemble Communications protocol
Real number Set (mathematics) Cryptography Field (computer science) Machine vision Revision control Machine vision Cryptography Telecommunication Game theory Communications protocol Game theory Row (database)
Point (geometry) Algorithm Focus (optics) Decision theory Real number Software developer 1 (number) Instance (computer science) Semiconductor memory Information privacy Cryptography Information privacy Product (business) Revision control Spur <Mathematik> Message passing Cryptography Exterior algebra Computer configuration Communications protocol Communications protocol Information security Fundamental theorem of algebra Marginal distribution
Algorithm Implementation Decision theory Term (mathematics) Limit (category theory) Cryptography Elliptic curve Category of being Type theory Message passing Latent heat Goodness of fit Computer configuration Different (Kate Ryan album) Computer configuration Blog Order (biology) Formal verification Data structure Communications protocol Communications protocol Information security
Algorithm Implementation Graph (mathematics) Software developer Term (mathematics) Cryptography Mereology Flow separation Revision control Category of being Goodness of fit Computer configuration Different (Kate Ryan album) Internetworking Formal verification Operating system Quantum Formal verification Communications protocol Quantum computer Communications protocol Information security
Algorithm Message passing Right angle Data conversion Semiconductor memory Communications protocol Communications protocol
Authentication Authentication Sigma-algebra Schlüsselverteilung Semiconductor memory Mereology Electronic signature Revision control Category of being Sign (mathematics) Message passing Formal verification Formal verification Right angle Encryption Communications protocol Pairwise comparison Message passing Communications protocol Information security Fingerprint
Perfect group Authentication Sigma-algebra Cyclic redundancy check Cryptography Encryption Uniqueness quantification Row (database) Data conversion Communications protocol Pairwise comparison Message passing Information security Fingerprint Pairwise comparison Data dictionary Polar coordinate system Key (cryptography) Computer Message passing Telecommunication Formal verification Right angle Encryption Key (cryptography) Musical ensemble Information security Fingerprint Perfect group
Group action Semiconductor memory Term (mathematics) Group action Mereology Electronic signature Information privacy Smith chart Electronic signature Revision control Latent heat Mathematics Latent heat Cryptography Hardy space Type theory Term (mathematics) Internet service provider System programming Quicksort Information security Message passing
1 (number) Materialization (paranormal) Smith chart Information privacy Latent heat Message passing Type theory Software Data conversion Information security Message passing Communications protocol Information security
Revision control Category of being Message passing Type theory Term (mathematics) Real number Interactive television Term (mathematics) Communications protocol Table (information) Category of being Communications protocol
Point (geometry) Vorwärtsfehlerkorrektur Mapping Multiplication sign Curve Primitive (album) Limit (category theory) Category of being Message passing Personal digital assistant Blog Revision control Energy level Encryption Information security Category of being Message passing Information security Communications protocol Form (programming)
Point (geometry) Vorwärtsfehlerkorrektur Addition Algorithm Implementation Curve Mathematical analysis Primitive (album) Personal digital assistant Internet service provider Revision control National Institute of Standards and Technology Encryption Quantum Encryption Information security Message passing
Asynchronous Transfer Mode Implementation Service (economics) Interior (topology) Virtual machine Revision control Data model Mechanism design Telecommunication Synchronization Energy level Endliche Modelltheorie Data conversion Message passing Information security Curve Server (computing) Division (mathematics) Schlüsselverteilung Line (geometry) Cryptography Elliptic curve Message passing Telecommunication Order (biology) Quantum
Asynchronous Transfer Mode Server (computing) Algorithm Ferry Corsten Multiplication sign Decision theory Interactive television Curve 1 (number) Data management Advanced Encryption Standard Data model Mechanism design Mathematics Cryptography Communications protocol Vorwärtsfehlerkorrektur Computer network Schlüsselverteilung Ratsche <Physik> Category of being Repository (publishing) Function (mathematics) Revision control Encryption Information security Communications protocol Online chat Asynchronous Transfer Mode Extension (kinesiology)
Algorithm Group action Mapping Key (cryptography) Algorithm Multiplication sign Primitive (album) Cryptography Mereology Information privacy Neuroinformatik Ratsche <Physik> Category of being Ratsche <Physik> Arithmetic mean Message passing Hash function Telecommunication Encryption Quantum Energy level Whiteboard Information security Online chat
Implementation Software developer Code Software developer Moment (mathematics) Collaborationism Java applet Primitive (album) Schlüsselverteilung Cryptography Mereology Revision control Latent heat Cryptography Operator (mathematics) Universe (mathematics) Revision control Operating system Right angle Software testing Implementation Extension (kinesiology) Communications protocol Extension (kinesiology)
Collaborationism Algorithm Authorization Schlüsselverteilung Control flow
Programming language Execution unit Implementation Software developer Java applet Disintegration Code Principle of maximum entropy Client (computing) Fluid statics Doubling the cube Read-only memory Semiconductor memory Software testing Software testing Implementation Buffer overflow Library (computing)
Software developer Code INTEGRAL Disintegration Execution unit Information privacy Product (business) Read-only memory Touch typing Software testing Implementation Information security Error message Form (programming) Execution unit Algorithm Software developer Code Cryptography Process (computing) Fluid statics Personal digital assistant Network topology Software testing Communications protocol Library (computing)
Suite (music) Distribution (mathematics) Suite (music) Continuous integration Revision control Architecture Finite difference Different (Kate Ryan album) Revision control System programming Software testing Software testing Quicksort Computing platform Physical system Computer architecture
Implementation Real number Range (statistics) PowerPC Client (computing) Virtual machine Data model Software testing Formal verification Communications protocol Communications protocol Formal grammar Computer architecture
Existential quantification Spezielle orthogonale Gruppe State of matter Interactive television Virtual machine Vector potential Data model Model checking Process (computing) Formal verification Cuboid Software testing Formal verification Finite-state machine Communications protocol Communications protocol Error message Formal grammar
Mobile app Key (cryptography) INTEGRAL Code Multiplication sign Digitizing Mereology Operations support system Order (biology) Lipschitz-Stetigkeit Software testing Quicksort Fuzzy logic Information security Communications protocol Information security Address space
Algorithm Implementation Decision theory Interactive television Cryptography Limit (category theory) Latent heat Operations support system Different (Kate Ryan album) Data structure Fuzzy logic Information security Communications protocol Communications protocol Library (computing)
Programming language Implementation Latent heat Telecommunication Right angle Semiconductor memory Communications protocol Product (business)
Onlinecommunity Implementation Mobile app Java applet Line (geometry) Java applet Continuous integration Instance (computer science) Semiconductor memory Software repository Website Quicksort Communications protocol Analytic continuation Communications protocol Library (computing) Electric current
Vorwärtsfehlerkorrektur Collaborationism INTEGRAL Code Line (geometry) Multiplication sign Authentication Java applet Ellipse Line (geometry) Semiconductor memory Control flow Repository (publishing) Row (database) Musical ensemble Communications protocol Electric current
Presentation of a group Digital media Internetworking Internettelefonie Multiplication sign Software developer Touch typing Videoconferencing Row (database) Cartesian coordinate system Communications protocol
Curve Email Implementation Electronic mailing list 1 (number) Videoconferencing Encryption Symmetric-key algorithm Drop (liquid) Communications protocol Number
Slide rule 1 (number) Instance (computer science) Mereology
Multiplication Message passing Synchronization Different (Kate Ryan album) Circle Instance (computer science) Information privacy Communications protocol
Category of being Email Multiplication Message passing Latent heat Synchronization Bit
Mobile Web Group action Bit Client (computing) Mereology Mathematics Integrated development environment Right angle Quicksort Endliche Modelltheorie Extension (kinesiology) Communications protocol Library (computing)
Data dictionary Group action Algorithm Authentication Computer Cyclic redundancy check Smith chart Information privacy Category of being Message passing Cryptography Order (biology) Information security Information security Communications protocol
Category of being Pairwise comparison Group action Goodness of fit Internetworking Communications protocol
Slide rule Ratsche <Physik> Algorithm Arithmetic mean Doubling the cube Key (cryptography) Extension (kinesiology)
Point (geometry) Default (computer science) Server (computing) Implementation Service (economics) Link (knot theory) Key (cryptography) Density of states Denial-of-service attack Limit (category theory) Category of being Arithmetic mean Personal digital assistant Information security
Server (computing) Building Implementation Service (economics) Key (cryptography) INTEGRAL Data storage device Mereology Revision control Category of being Message passing Synchronization Right angle Quicksort Figurate number Communications protocol Library (computing)
Cartesian closed category Musical ensemble Semiconductor memory
[Music] so welcome and our next speakers are Sophia silly and you have one person and they are going to tell you about the newest version of the off-the-record protocol version 4 and as well as encryption they are going to touch on morality and ethics and why we encrypt and why we need communication
please welcome Sophia and you okay so hello welcome and Sofia and this
is you day and us it was said we're going to present the version for the OTR protocol but we are also going to rename
this talk no evidence of communication and morality in protocols for a reason and you will see during their talk why so the first thing that came to us to our mind when we decided to present the version for the OTR protocol was to talk to the audience or why we need why why we need secure messaging and for this we decided to quote one of the most famous papers in cryptography that was done by Philip row away in 2015 which is called the moral character of cryptographic work and this paper starts by saying that most academic cryptographers seems to think that a field is a fun deep and political neutral game a set of puzzles involving communicating parties a notional at Versailles this vision of who we are an inmate's a field whose work isn't that intellectually impressive and rapidly produced but also quite inbred and Debose from the real war concern is this what cryptography should be like is it how we should spend the bulk of our intellectual capital the reason why we wanted to show this quote is basically that for a start of a talk is to start inquiring in ourselves if what the work that we're doing is actually the work that we should be doing because at the
end of the day we are privacy and security developers of cryptography so software developers we own the product and the design decisions with you for the real world people who are the ones who going to use and if we're going to give our protocol or an algorithm or product to them then it should be also interpreted with ethical and moral decisions and of course roadways that's
a lot of points in his paper but this in a special paragraph that actually concerns the main focus of our talk in which he talks that basically one of the things that some sense have been abandoned by cryptographic as security or privacy research is the problem does the secure messaging he says that of course there has been some research and of course there are some options but there has not been that much intensive research and one of the reasons were presenting today out here in his version four is because since the beginning Odia tried to solve this problem of secure messaging and try to give to the user back eat privacy that sometimes big corporations of government had actually taken away from them and of course as I already said there's a rather a lot of not a lot but some alternatives to the secure messaging protocols there's a lot of protocols that try to do that but in this talk we will also argue what we
need actually a protocol of like Oh Tia that actually sets the bars around the definitions limitations of properties that we need when creating a protocol so one of the things that of course if we want to solve the secure messaging
problem because this is a problem that users actually need to be solved because one of the things that real world uses doing the internists communicate between each other so we actually need to solve this problem and one of the things that we need in order to solve this problem is to give to the users options that work sometimes a lot of secure messaging protocols and actually give any implementation for the user to use or actually good design decisions so they can actually know what they are using we also need fully specifications it's not enough to actually do a secure messaging protocol that is only defined between three blog posts or having a specification or just an implementation we actually need protocols that are highly structured enough and that say that that not only say what cryptographic algorithms are used but actually define how these are cryptographic algorithms are used and how they relate to each other it is not enough to say in a protocol that you use elliptic curve cryptography you have to take in account how I live take care of cryptography works between each with other algorithms and how it takes into account different kinds of attack I don't know if maybe for be with you side channels that are cofactor issues etcetera etcetera so we need full structure specifications we also need to define a specific specifically which properties our protocol is going to try to solve by saying okay this is try to solve deniability and all of the types of the nobility or only or some types of deniability it tries to solve perfect forward secrecy or whatever proper it is a protocol should also define which limitations it has because a protocol cannot solve them all you know she had before as we were going
to see in some Nexus lies for example we didn't try to solve the post quantum algorithm the quantum computing problem because obviously post quantum algorithms and as you can see if you attended Daniel Angus and onion burst in stock yesterday you will see the post quantum algorithms are not good enough right now to be deployed we also need protocols that update existing definitions because a lot of people
sometimes says that we have our already a protocol so why should we update to another protocol if we already what have one that looks good enough it might look good enough today but in the future or right now already the academia has actually defined in a proper way the definitions of the security properties that your protocol is trying to attain of course for protocols we also need review and verifications because it's not enough to put a protocol on the internet and inspected uses uses it has to have formal verifications revision by several parties by cryptographers software developers etc and verifications we also need implementations and by implementations and mean a coder can actually run on several operative system that can compile and actually run and of course and most importantly we also need ideas from different places something that we are very proud from the version 4 of all Ti is that actually most of the developers of or TIA come from Latin America specifically from Ecuador and Brazil as sometimes we actually need ideas coming from different places because it's not enough to just graph ideas from a certain region of the world and impose them into another region of the world you will find that there are very good ideas from other parts of the world that needs the attention as well
what actually is ok are also recommending and what exactly is deniability so in the beginning what three people who wrote the paper yeah Ian Goldberg Nikita Borissov and Eric Brewer and they created this paper
called off-the-record messaging and basically what they wanted is that they wanted to have messaging algorithms and protocols in the world it would sort of mimic conversations you would have casually like in the real world and bring that to the digital
world right so what PGP did for example is that you can sign a messages where you can say oh this message is actually written by me but in the real world what you want it's actually say I have a conversation with Sophie that I know it's Sophie but if we have a one-on-one conversation somewhere nobody knows what was actually sad and that's something we wanted to that that you know Ian and the others wanted to incorporate into and the cryptographic protocol and so they
did that and then it went through several revisions and one of the cool things as well is that you can sort of authenticate somebody right in a deniable way we'll get more into that later on but sometimes you know you want to sort of verify that the person who still controls a certain account like of a xmpp of IRC you want to verify that that is still the real person that you are expecting and that was done through like the socialist millionaire protocol or you can sort of authenticate somebody sorry verify somebody and you know the OTR gave like inspiration to like a bunch of other secure messaging protocols and signals was definitely one of them and so some of the properties that OCR has is like authentication so there's like an authenticate the key exchange is a variant of the signal protocol with science which stands for the sign and Mac protocol but what was different in the OTL version is that they sort of removed the signing part and it still
worked through the to the Mac stuff because you can sort of like because it's just like what I said before you don't always want signatures and they achieved it this way and then through the verification right the social Millionaire protocol you can sort of like have a shared secret or have like a
question and answer where you can ask a certain question and hopefully this person only knows the answer to that question that you asked as well as like a fingerprint comparison like other bands and then you know it has end-to-end encryption so all messages are encrypted between the two devices that are talking to each other and so another important thing is like
the perfect forward secrecy right so there's like unique keys for every conversation that you're having like every methods in every like session that you have and why this is important is that let's say the device gets compromised when somebody gets access to your phone that at least and the attacker can't decrypt the messages that was sent earlier because every session has like a unique key and then the post compromised security right is that even if a message key gets compromised now future messages can be decrypted where if Alice has like a security guarantee about communication with Bob even if Bob secrets have already been compromised you know they can't really do anything with that and so we get to the
deniability part so deniability in like the og of version 3 which is like the the sort of like previous version of Archaea is that you know the considering
scenario where Bob accuses Alice of sending a specific methods Justin that just must decide whether or not he believes that Alice actually did so and if Bob can provide evidence that Alice entered methods this is a valid cryptographic signature of the methods in the Alice long term key then we say that the action is run on reputable otherwise the action is deniable and so what the sort of change in the OTR version for then deniability part is
that it has sort of like the deniability has expanded so let's start with the two easy ones one of them is the methods so if you're sending a message you can sort of like deny that you have standard methods but you can also deny that you actually are but the painting or had participated in that message in that conversation with somebody and then the offline one that let's say we had a conversation that we ended the conversation we can you know force the transcript afterwards and online is is that somebody might try to collude with the network somehow to try and figure out like what's going on and
also that party cannot verify you're actually having that conversation of course you know cryptographic protocols are never silver bullets so you shouldn't just rely on deniability for like you know your perfect operational security and a protocol is funnily deniable strands which provides no evidence even if long-term key materials compromised an outsider can obtain evidence even in from inside the
interactively coalesce with them which is the online deniability okay so basically what we try to attain in the full version of for TIA that we wanted to have all of the properties that ot AHA plus all of the academic definitions that have already been updated we wanted to have forward
secrecy post compromised secrecy but also all and an ability of London elite deniability participation deniability and message deniability one of the reasons why in the past out here the knotty final of these inner abilities was because in the academia there was big terms around what own and inability was and offline deniability one was but what we wanted with the version four is to update this protocol to catch up with what they academy how academia has already defined so we can put that onto a protocol that can be used by the real war people and as you see here we have floated our table our comparison between
the most popular secure messaging protocols Odia has most of the pool properties of course in some cases we don't have the full properties you only partially provide the property and this is something that we also wanted to make very clear without here to say the limitations that the protocol has not only try to say to the user oh this has it all it actually has some limitations some of the appropriate and the mapping that we have made of all the secure messaging protocols might not be that accurate enough because we have pacer research on the protocols of these secure messaging protocols or the blog post sometimes they have and sometimes these blog posts are not updated enough so yeah be aware okay so what we have a
person 404 TIA of course as we already said we wanted an ability we wanted an ability in all of its form as UD has already point out we wanted participation message online and offline deniability we also wanted to give a strong perfect forward secrecy and post compromised secrecy we also wanted to update the highest security level and this is related to the next point which is that we also wanted to update the cryptographic primitives why is this is important in the secure messaging protocol is because most of the times
you have algorithms and you think okay this algorithm is good enough but then of course someone finds an attack against this algorithm or an issue of the implementation of that algorithm so we should also update the cryptographic primitives to something that has enough crypt analysis and is good enough to use we also wanted to grow to provide
additional protection against transcript decryption in the case of ECC compromised we wanted to use the Liberty curves this is a very important point because one of the things as I already said in the past is that we don't provide quantum resistance you know Tia before and one of the reasons is because as I said there's still no quantum algorithms that are good enough to be used right now in a massive way we will wait until the NIST composition competition is over to maybe reconsider this thought but the NIST competition is still ongoing so we will still have to wait on that but in the case that
quantum machines come earlier as we thought then at least we will use a division of a very large prime so it will be more difficult to break this very large prime diffie-hellman that elliptic curve cryptography but of course we also wanted to use the Liberty curves because elliptic curves have a smaller prime but they have the same security level up bigger security level we also wanted to incorporate a new
communication model that now we have when OTA was first below we it only suffered a synchronous online conversation and right now we also need online and offline conversations so that is something that out here before also provides we also provides in order and an outer order delivery of messages we also give they implemented several ways in which Oda before can be implemented because sometimes implementers only want to implement the own line version of it and of course we also don't want to trust service because service can be tricky to manage and we don't want to trust them and that's the way that we use the the novel authenticated key exchange which is a mechanism by which
you authenticate the other party in a dinner away and you also generate a shared secret that mechanism for the offline mode needs our on trusted server that is going to cache for some time ephemeral Mattia here you have the main
changes if you go to a repository and our protocol you will find it but just to show okay some design decisions of
course instead of something as simple as people have put it we used exit and exeed eh which are two bags as I defined X is that the novel authenticated key exchange and we wanted to have these two decks because these are the ones that mostly give the deniability properties that we need we also wanted to use the libtech of 84 for a Goldilocks by Mike
on board because it gives us a security level that you we wanted to attain of course as I already said because we wanted to make sure that went on computers might take some time to decrypt some parts of out here before we also wanted to use the DB here mum 3072 we wanted to use shake and exhausted xx shake is the hash function that we're using Odia before its asset 20 is the encryption algorithm that we use the reason why we wanted to use them is to update the cryptographic primitives of course we wanted to use that of a ratchet algorithm because it's the algorithm that will give us better forward secrecy by the means of always encrypting one message with one unique key and some of the questions that people sometimes have posed to us what is the toolkit the toolkit is something that out here before always provides is basically a way to prove to the people that look into TF that actually these gives the deniability properties that it claims to have I have already said that we don't support post quantum algorithms and the reasons for that and of course we also don't have group chat the reason why don't we don't have group chat is because there has not been a good mapping of which deniability properties
and security privacy properties we need for group chat and there is not a way of to create AB a strong strongly deniable communication in a group chat okay of
course as I said at the beginning one of the things that we should also have when we design a protocol is that it should also have a good implementation an implementation that runs in most of the operating system an implementation that
compiles an implementation that runs and for this we wanted to have a real-world implementation right so we did
collaborating with two different entities main mainly the cryptographers will worked unlike the dnieper key exchange at the university of waterloo and the developers will you know have
implemented cryptographic primitives but also like working on like the actual like code of the specification that it's out to operation for so that came out you know lip-lip goldilocks is an extension of decaf from Mike Hamburg where we said well we only are going to use IDI for for like a specific encoding there's going to be you know people at the moment working on different implementations and why that is important is that you know we want to be able to also like test it out and see whether there's any flaws maybe in the specifications or things that are unclear and so far that has helped us to clarify certain parts of the specification and improve those parts and you know we've been collaborating with the cryptographers father was writing the papers and a lot of the revisions of this work have been
revealed by Ian Goldberg and Nick Unger we have worked on like the dnieper key exchange paper as well as like OTR in general is always important when
designing a protocol that if you're using a paper it would be good to always refer to the author so how
collaborations with the others so you are sure that you're implementing the cryptographic algorithm that is defined on the paper in a good way and actually this is the paper we are based upon mainly our takes are based upon the first paper but Nicola Rangi young Goldberg that's 84 for a goldilocks by my Humbert and of course we have already been quoted in all the papers like in this paper from the Aalto University
yeah of course if we wanted to do a real war
implementation we needed to choose a programming language in which we were going to implement this and we choose to do an implementation in C as urea has already said this already of some ongoing efforts of actually implementing in Python Java angolan but the main library has been written in C what we want to see well C so with the library that C is always the programming language that is often used as a reference and most of the libraries that we use were written in C in C so we wanted to use the same programming language but of course when you you see you will have some problems with memory handling I don't know if you attended previously a talk called mem sat in which actually the talker explains some of the problems in memory handling but we had to to verify this memory handling in our library in a good way because if we're going to provide elaborate that is going to be used by the real people then it has to not have the memory problems that some libraries has for that we try to we incorporate in a static testing by using client ID and splint we also use valgrind to check buffer overflows double fries usage which - after a free
etcetera cetera and various a tree sanitizes of course we also wanted to have tests seen in our library in the form of unit and integration this is something that is always so very needed in libraries because sometimes people push in production some libraries that are naturally they correctly all of the edge cases that Allari can have in its development process and we wanted to make sure that everything was a-ok and something that actually on the talk of yesterday by Daniel anger and Daniel burns they said is that we also should put on the cryptographic things or design or when designing algorithms we should also make an ax strive for code that can be readable because sometimes your library
is going to be used by other software developers and so other so what developers should be able to understand how how the library is actually working so we wanted code that week that can be used by other developers we also wanted to give recommendations to developers because yes it's it's true that we created this protocol and we created a design of this protocol but not because of that we just should push the protocol out of there and just say try to implement it at anyway but actually try to keep in touch with the community give recommendations clarify things that may not be good enough in the protocol this actually makes the protocol much much more robust because we catch up some errors that may be cryptographers in it catch up security privacy as first didn't catch up but software developers implementing the protocol did catch up Sophie said we've been doing testing but
we also think it's important to actually test unlike various architectures and operating systems so we actually found like a couple bucks while we were
running the test we don't like some of the online like test Suites many being like different GCC and clang versions or like different operating systems and
distant distributions from Linux and I'd actually like caught some problems every now and again we also want to you know get by the support and like the various beasties that are out there and so we started working on like you know continuous integration for those platforms and one also one of one sort of funny thing is that Debian you know has like various architectures and they also have like so like unix-like systems so we managed to like find some problems or
like the DP new hurt this is out there and some other more exciting like architectures on like MIPS and a PowerPC and it actually helps you sort of like have like a wide range of architectures that we check for any mistakes is also
very important when doing a cryptographic protocol that really what people are going to use is that we should always prioritize the real war people that is going to use it because
at the end of the day they use some matters if you're pushing some weren't something to the world then of course some user is going to use it so we try also to at least when we did our implementation of the plug-in to the pitching client so at least make the
dialogue O's dialogue O's dialogues more understandable on how they actually try to attain that for example if the process of generating a private kid and it should be clear enough to the user what that process that that process is happening and of course something that as we said is also needed when you are designing a protocol and something that we try to include a note here before is actually doing formal verifications of all the protocol so we eat right so right now this and I'm going work are actually doing a model checker of the protocol state machine that is going to be done in the Tulsi Murphy and eventually we want a food protocol for formal verification this is important because as I said this is one of the
reasons why you should have a fully structured protocol because something's between the interaction of one state to other state is when errors and mistakes occur so you actually need to formally check all of these steps to catch up maybe issue some mistakes or potential box that can happen in a protocol
security so especially in cryptographic protocols we actually want to be sure that the code that people are using it's like reasonably secure so we want to sort of like start working towards fuzzing so we want to integrate parts like lip fossa and using like stuff or like AFL and hopefully we can run that unlike the other the OSS first which is an initiative by Google where they provide
App Engine computational time in order to run like fuzzing tests and we also really welcome community audits so that's like a security PGP key on like security at LG or that I am so if you have one to email about any flaws that you find please do something like this or email the OT our fee for people on the autonomia digital in address and we you know we don't only stop there we also actually want together a professional security audit by the code
that we have been coding okay so yes we have in conclusion what we wanted to attain without here before is to design a very structure protocol is specification that actually say how the interaction between different cryptographic algorithms work to check that everything is correct we wanted to also give to the users a real-world implement a real war a specification
that actually is a structure enough says what limitations this protocol has said which design decision it has such says which requirements it needs because that sometimes something that the users and implementers actually may need because
the user may choose between different protocols depending on how the specification is defined we also wanted to give this real-world implementation that didn't only care about implementing it just in whatever way in whatever programming languages but actually to make sure that this is an implementation
that is production ready that can be used by people and that can be used to base other implementations upon that that come in again with what we started at a beginning with the Philip rollaways paper basically that's what we try to do in note here that this is a protocol that tries to solve the problem of the nobility as a basic right of people when they have in a communication in the digital world and also are something that takes into account this morality then takes into account the requirements and needs of the users when they actually need something that is specified good and I that is implemented good enough for them yeah and check out
our repos they are indeed have this is the protocols we also have the library and see the precursor the toolkit our implementation half implementation which is not done in Golan the implementation in Java that was on the dome by Danny is Ben is going by Donovan Holmen and yeah and check also our website and we also wanted to thank everybody okay so also just to
like add like a little thing so we have like a sort of OTO community website cut out the other diam which also has a get up again app instance and we have like various like continuous integration possibilities so if you ever want to move from github for example gitlab we are like happy to host you on this platform and provide continuous
integration capabilities for you hey we also wanted to thank everyone involved out here before has been a protocol that has been done by a lot of people from all over I think from almost
all of the continents in the world we wanted here to show up the people who have more than six thousand lines of collaboration or code of text in a
repository but there's much more if you can you want to know who have who have collaborated you can also you can always check our repositories here's some time for reference if you want to know the
papers we based upon this talk and yeah questions [Music]
thank you and of course then everyone involved for the amazing work on OTR and
thank you for the great presentation we have time for questions so why not in front of the microphones we have five of them in the front and in the back of the hall we're going to take a question from the internet first the question is are
you in touch with developers of popular messaging applications such a signal and if yes it will the protocol also support media other than text such as VoIP or a video or something okay attached I don't
know but yeah we have we have not collaborated with them specifically we just have collaborated with the people who in the past did Odia because they are the ones who also did right now the newest papers and the reason why we wanted only to update oti is because so Tia has always been the inspiration to other protocols the signal protocol base itself on Odia so we wanted to first updated here only in the past Trevor Perrine when we first pushed the first draft of the OTA he suggested us that we should also publish the first drop on the mailing list that modern curves have but we have not closely collaborated with them now around the second question which is around video and audio you can always support them you know Tia if you want encryption of video or attachments you can always use the thing that's called the extra symmetric key for those purposes so I said no actual implementation happens thank you microphone number one well my question
is related to the capability of a MIMO to support multiple devices which is
very important in a modern world and I wanted to know if ot are before can do this and still provide its stronger say deniability guarantees thanks so much for your question this actually moves us to ok this this is a common question
that we have and first part of the question I think it's also important to answer this so right now out here before and since OTR v3 ogia has something calls instance acts that is the ones that actually identify several devices
when you send a message you will only be identified to that specific device there's not multi synchronization of devices because that will create some privacy concerns so that's not there like multi circle synchronization between devices that's not there but of course you can use several devices and if the devices recognizes which instant act the instance stack that belongs to you will always send to the correct device if you want difference with a memo is that of course or ti-84 and ogia is more at gnostic and by this it means that idea can be built upon any other messaging protocol that they exist not
only XMPP if you want to build out here
over IRC you can do so and even today because we're supported offline messages you can also build it if you want us an email and of course what here has better deniability properties I have not seen any paper that actually said inability properties in the concern of multi synchronization devices it has something interesting to look upon and of course
what here before has a little bit a much more well-defined specification thank you as a reward for unlocking the
secrets lies we're going to have a question from microphone one again my apologies this might actually be out of scope but one of the problems with messaging apps like on your phone is not
just the encrypted chat session but discovering people and matching people to initiate first their first contact do you have thoughts on how that might you know on how that problem gets addressed okay that's the contact discovery problem right so basically that is much more in the sense of something that is deployable in a mobile devices and of a client and right now out here right now where the stage of doing the protocol and doing the basic library so if some day we start walking into a client that is going to be supported by Mobile's then of course we will have to tackle that problem but right now in Oriya we have not try called that because it's not part of the main protocol it might be an extension for clients that want to develop that on the mobile environments what kind of like messaging protocol you used underneath right like this will be sort of tough for like IRC but like maybe example P also not really the problem but then if you get into like their sort of model landscape and everything changes and it's like more complicated with this something yeah thank you
microphone 3 please could you elaborate a bit more about why group chat isn't
possible and do you think it will be possible in the future because I think it would be really important or daily usage so um there has been some efforts in the past as we know there was at least one fo some years ago about doing NPO Tia and right now just even a very nice paper that is called Christy's here
yes this last paper secure messaging is the one that actually defines like all of the properties that some secure messaging protocol has to have in order to also support group shot and the thing is that there's right now not a good way of achieving the same deniability properties that you want with the current current cryptographic algorithms that we have now what the future that actually looks very bright I remember that we attended pets 2018 and
Nikolas hopper already presented a paper around a group shot on deniability which was interesting it didn't cover up all of the secure properties that you need for group chat but it was very interested and during that same conference Nick Unger also told us that he is preparing a paper around good deniability in the sense of group shot so that is something that may be happening in the future thank you one more question from the
internet explain how h ER before forward secrecy is stronger than signals referring to the protocol comparison
slide so basically this depends on the
kind of a key of dake that you use signal uses right now one deck that is called x3 d8 extent of triple diffie-hellman that is the one that provides that gives this weak forward secrecy the double ratchet algorithm of course gives perfect forward secrecy but the start of the take with the with the double ratchet algorithm is the problem how you will be fine weak forward secrecy is that only it will only protect the deck will only protect the session key went on when both parties complete the deck is changed and in Odia before we wanted to give perfect forward secrecy since the start of the day meaning that it would provide a strong forward secrecy even if one party only finished the deck in signal you have to wait for both parties to actually finish and complete the deck is changed to to have the forward
secrecy but in note here before we wanted to have that in a strong way thank you question from microphone one
in the links there was a mention of a pre key server is that server side
requirement like signal DOS sorry eat that either what a pretty key server yeah yeah and their links is the same as signal asking I think Cigna has some requirement in the server side is that a requirement for ulti are two signal defines also an untrusted server I don't know that much in our requirement from an implementation at some point but while requirement from OTA before we saw so that signal trusted pretty server many meaning that we take all of the precautions that is needed when you're using an untrusted three key server we define the limitations because you can have a lot of denial of service attacks like someone can track all of the pre the ephemeral material that you have on the three key server someone can can make yeah someone can publish there's something else so we wanted to have all of the security considerations when using an untrusted biggie several I for example the submissions that we do to the pre key server are always authenticated also in a deniable way with the server we don't use a signal because signals in the case that for example you run out of ephemeral keys signal will use a static one per default in those cases we didn't wanted to use that because that actually can go against some deniability properties so we in the case that there is no more ephemera material in the pretty server we just wait until someone publishes more to the pre key service thank you
what yeah and of course Anna trusted
freaky server yeah thank you it's not required unless you want to support offline messages some protocols may only want to implement the only version of OTR because I don't know those are their requirements only if you need to use offline a synchronous communication is that you will have a pretty service thanks one last question from microphone
one I wanted to know if you
worked a bit indignant between the integration of OTR v4 and the other protocol actually one of the strengths of a memo is that it's perfectly well defined with all the key where the key our store in XMPP between the account and how they are exchanged and then it gives you a really nice and well-defined way of where to find the keys in in XMPP while on OTR you always have this like pre little tag on the body of the messages which is a bit ugly and like so I wanted to know if you add some tops how about and if you do some work for HR before regarding the integration of what your before and the other protocol you know it slightly easier for MIMO in some way because it's it works only over XMPP and with the OTO fee for protocol we can sort of like federates of you know what kind of well I mean not federated but get it to work over any messaging protocol now of course if you would do something like a pre key server over is see that might get tricky in some way so that might not entirely be possible so I think it sort of depends on what kind of messaging protocol is underneath and sort of try and figure out how we can implement these things and maybe we should sort of move to messaging protocols that sort of take these things into consideration right to have a sort of extinction that we can build upon where we can actually plug like pre key servers into it you're sort of like there the reasoning I would use I mean oh if you love so one of the properties of course of RTI is that it should be agnostic to any protocol that it's it will build upon so specifically defining the XMPP properties or the XMPP things that we need for Oh Tia would not be part of what yeah but maybe from a separate document in which we can give recommendations for implementers upon building upon XMPP on the actual implement we haven't found that much trouble the only travelling that simply beefing implementation that we found out is that we actually needed to discover the P key server and we were using the pigeon library there was not an exposed Heather for actually doing that so we had to do some tricks to actually blue thank you
that was the last question thank you for the amazing talk thank you for your work thank you
[Music] [Music]