 So, welcome and our next speakers are Sophia Selie and Jure van Börchen and they are going to tell you about the newest version of 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. So, please welcome Sophia and Jure. So, hello and welcome and Sophia and this is Jure and as it was said we are going to present the version 4 of the OTR protocol but we are also going to, we named this talk No Evidence of Communication and Morality in Protocols for a reason and you will see during the talk why. So, the first thing that came to our mind when we decided to present the version 4 of the OTR protocol was to talk to the audience about 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 Rowerway in 2015 which is called the Moral Character of Cryptographic Work and this paper starts by saying that most academic cryptographers seem to think that our field is a far and deep and political neutral game, a set of puzzles involving communicating parties and notional adversaries. This vision of who we are and it makes a field whose work is intellectually impressive and rapidly produced but also quite inbred and devolved from the real world concern. Is this what cryptography should be like? Is it how we should expand 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 as privacy and security developers or cryptographers or software developers we own the product and the design decisions we do for the real world people who are the ones who are going to use and if we're going to give a protocol or an algorithm or a product to them then it should be also interbred with ethical and moral decisions. And of course Rowerway does a lot of points in his paper but there's a special part of that actually concerns the main focus of our talk in which he talks that basically one of the things that sometimes have been abandoned by cryptographic or security or privacy research is the problem of 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 we're presenting today OTR in his version four is because since the beginning OTR tried to solve this problem of secure messaging and tried to give to the user back in privacy that sometimes big corporations or government have actually taken away from them. And of course as I already said there's 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 OTR 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 users do in the Internet is 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 don't 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 full specifications. It's not enough to actually do a secure messaging protocol that is only defined between three blog posts or a health specification or just an implementation. We actually need protocols that are highly structured enough and that not only say what cryptographic algorithms are used but actually define how these cryptographic algorithms are used and how they relate to each other. It is not enough to say in a protocol that you use a lifted curve cryptography you have to take in account how a lifted curve cryptography works between each with other algorithms and how it takes into account different kinds of attack I don't know made before we would use side channels that are cofactor issues etc etc so we need full structure specifications. We also need to define specifically which properties a protocol is going to try to solve by saying okay this is trying to solve the ability and all of the types of the ability or only some types of the ability. It tries to solve perfect forward secrecy or whatever property it is. A protocol should also define which limitations it has because a protocol cannot solve them all. In OTR before us we were going to see in some next slides 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 Tanya Langes and Tanya Bernstein's talk yesterday you'll see that 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 already a protocol so why should we update to another protocol if we already 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 expect that uses it. It has to have formal verifications revision by several parties by cryptographers, software developers etc and verifications. We also need implementations and by implementations I mean a code that can actually run on several operative systems that can compile and actually run. And of course most importantly we also need ideas from different places. Something that we are very proud from the version 4 of OTI is that actually most of the developers of OTR 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 have ideas from a certain region of the world and impose them into another region of the world. You will find that they are very good ideas from other parts of the world that need the attention as well. All right. So now we're going to talk about what actually is OTR of the record messaging and what exactly is the liability. So in the beginning there were three people who wrote a paper, Ian Goldberg, Nikita Borisov and Eric Brewer and they created this paper called After Record Messaging and basically what they wanted is that they wanted to have messaging algorithms and protocols in the world that would sort of mimic conversations you would have casually like in the real world and bring that to the digital world. So what PGP did for example is that you can sign a message where you can say oh this message is actually written by me but in the real world what you want is actually say I have a conversation with Sophie that I know it's Sophie but if we have a one-on-one conversation somewhere and nobody knows what was actually set and that's something we wanted to that Ian and the others wanted to incorporate into a 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 will still control a certain account like over XMPP or via C 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 where you can sort of authenticate somebody sorry verify somebody and you know 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 OTR has is like authentication so there's like an authenticated key exchange there's a variant of the Sigma protocol with signs which stands for the silent Mac protocol but what was different in the OTR version is that they sort of removed the signing part and it still worked through the Mac stuff because you can sort of like because 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 socialist 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 ask as well as like 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 it's like the perfect for its secrecy right so there's like unique keys for every conversation that you're having and like every message and every like session that you have and why this is important is that let's say the device gets compromised and somebody gets access to your phone that at least the attacker can't decrypt the messages that were sent earlier because every session has like a unique key and then the post-compromise security right is that even if a message key gets compromised no 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 the liability part so the liability in like the OTR version 3 which is like the sort of like previous version of OTR is that you know the conceding scenario where Bob accuses Alice of sending a specific message just in a just must decide whether or not he believes that Alice actually did so and if Bob can provide evidence that Alice sent that message this is a fairly cryptographic signature of the message and the Alice long-term key then we say that the action is run non-reputable otherwise the action is deniable and so with a sort of change in the OTR version 4 then the liability 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 message so if you're sending a message you can sort of like deny that you have send that message but you can also deny that you actually are participating or had participated in that message in that conversation with somebody and then the offline one is that let's say we had a conversation and we ended the conversation we can you know force the transcript afterwards and online 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 are actually having that conversation of course you know cryptographic protocols are never a silver bullet so you shouldn't just rely on the liability for like you know your perfect operational security and a protocol is firmly deniable transfer for right no evidence even if long-term key materials compromised I know outside I can obtain evidence even if an insider interactively colludes with them which is the online deniability okay so basically what we try to attain in the full version of OTR that we wanted to have all of the properties that OTR had plus all of the academic definitions that have already been updated we wanted to have full secrecy post-compromise secrecy but also online deniability offline deniability deniability participation and message deniability one of the reasons why in the past OTR did not define all of these deniabilities was because in the academia there was big terms around what online deniability was and offline deniability one was but what we wanted with the version four is to update this protocol to catch up with what the academy how academia has already defined so we can put that on to a protocol that can be used by the real world people and as you see here we have pointed at table of comparison between the most popular secure messaging protocols OTR has most of the poor properties of course in some cases we don't have the full property you only partially provide the property and this is something that we also wanted to make very clear with OTR 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 properties and the mapping that we have made of all the secure messaging protocols might not be that accurate enough because we have based our research on the protocols of these secure messaging protocols or the blog post that sometimes they have and sometimes these blog posts are not updated enough so yeah be aware okay so while we have a version four of OTR of course as we already said we wanted an ability we wanted an ability in all of its form as Yuri has already pointed out we wanted participation message online and offline in ability we also wanted to give a strong perfect forward secrecy and post compromise 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 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 to provide additional protection against transcript decryption in the case of ecc compromise we wanted to use elliptic curves this is a very important point because one of the things as i have already said in the past is that we would don't provide quantum resistance in otr 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 next competition is over to maybe reconsider this thought but the next 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 diffie helman of a very large prime so it will be more difficult to break this very large prime diffie helman that the elliptic curve cryptography but of course we also wanted to use elliptic curves because elliptic curves have a smaller prime but they have the same security level bigger security level we also wanted to incorporate a new communication model that now we have when otr was first developed we it only supported synchronous online conversation and right now we also need online and offline conversations so that is something that otr before also provides we also provides in order and out of order delivery of messages we also give the implementers several ways in which otr before can be implemented because sometimes implementers only want to implement the online version of it and of course we also don't want to trust service because service can be tricky too many and we don't want to trust them and that's the way that we use the the naval authenticated key exchange which is a mechanism by which you authenticate the other party in a deniable way and you also generate a shared secret that mechanism for the offline mode needs a untrusted server that is going to cash for some time ephemeral material here you have the main changes if you go to our repository on our protocol you will find it but just to show okay um some design decisions um of course uh instead of something simpler as people have put it um we use deck set and xcdh which are two decks as i defined decks is that deniable authenticated key exchange um 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 liptokurve ed4 for a goldilocks by Mike Hamburg because it gives us the security level that you we wanted to attain of course as i already said because we wanted to make sure that quantum computers might take some time to decrypt some parts of otr before we also wanted to use a dvHelman uh 3072 we wanted to use shake and xalsa 20 shake is the hash function that we're using otr before xalsa 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 the double ratchet algorithm because it's the algorithm that will give us perfect forward secrecy by the means of always encrypting one message with one unique key and some other questions that people sometimes are opposed to us what is the toolkit the toolkit is um something that otr before always provides is basically a way to prove to the people that look into otr that actually this gives the deniability properties that it claims to have um i have already said that we don't superpose 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 a very strong strongly deniable um communication in a group chat okay well uh 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 operative system an implementation that compiles an implementation that runs and for this we wanted to have a real-world implementation right so we did that collaborating with uh two different entities mainly the cryptographers who worked on like um the deniable key exchange um 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 uh that is OTR version 4 um so uh that came out you know lip lip Goldilocks is an extension of lip decaf from like Hamburg uh where we uh said well we only are going to use ed448 for like a specific encoding um there's going to be um you know people on 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 where there's any flaws maybe in the specifications or things that are unclear and so far that has helped us to um clarify certain parts of the specification um and improve those parts um and you know we've been collaborating with the cryptographers while they were writing the papers and a lot of the revisions of this work have been reviewed by Ian Goldberg and Nick Unger who have worked on like the deniable key exchange paper as well as like OTR in general yeah related to the point it's always important when designing a protocol that if you're using a paper it would be good to always refer to the author so have collaborations with the author 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 decks are based upon the first paper by Nick Unger and Ian Goldberg that's the ed448 Goldilocks by Mike Hamburg and of course we have already been quoted in all the papers like in this paper from the Alto University yeah um 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 Yure has already said there's already of some ongoing efforts of actually implementing in Python, Java and Golan but the main library has been written in C what we want to see well C is always 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 use C you will have some problems with memory handling um I don't know if you attended a previously a talk called MemSat in which actually uh the talker explained some of the problems in memory handling but we had to um to verify this memory handling in our library in a good way because if we are going to provide a library that is going to be used by the real people then it has to not have the memory problems that some libraries have for that we tried to we incorporated a static testing by using client ID and splint uh we also use ballgrain to check buffer oil flows double freeze uh usage with uh after a free etc etc and various address sanitizers. Of course we also wanted to have um testing in our library in the form of unit and integration this is something that is always so uh very needed in libraries because um sometimes people push in production some libraries that actually verify correctly all of the edge cases that a library can have in its development process and we wanted to make sure that everything was uh okay and something that actually on the talk of yesterday by Daniel Langer and Daniel Bernstein said is that we also should put on the cryptographic things or design or when designing algorithms we should also make an strive for code that can be readable because sometimes your library is going to be used by other software developers and so all the software developers should be able to understand how uh how the library is actually working so we wanted code that we 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 in any way 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 more robust um because we catch up some errors that maybe cryptographers didn't catch up security privacy experts didn't catch up but software developers implementing the protocol did catch up all right and just like Sophie said we've been doing testing but we also think it's important to actually test on like various architectures and operating systems so uh we actually found like a couple of bugs while we were running the test suite on like uh some of the um online like test suites um mainly being like different gcc and clang versions or like different um uh operating systems and this and distributions from Linux and that actually like caught some problems every now and again um we also want to you know get better support and like the various bsd that are out there and so we started working on like um you know uh continuous integration for those platforms um and one also one one sort of funny thing is that um Demian you know has like various architectures um and they also have like sort of like unix like systems so we managed to like find some problems like the new herd uh that is out there and some other more exotic like architectures on like MIPS and power pc um and it actually helps to sort of like have like a wide range of of uh architectures that we check for any mistakes yeah and something that is also very important when doing our cryptographic protocol that real world people are going to use is that we should always prioritize the real world people that is going to use it because at the end of the day they use some matters if you're pushing someone something to the world then of course some user is going to use it so we try also to at least when we did uh our implementation of the plug-in to the pitching client to at least make the dialogues dialogues more understandable on how they actually try to attain that for example if if the process of generating a private key then 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 on OTA before is actually doing form aberrifications of all the protocol so we tried so right now there's an ongoing work or actually doing a model checker of the protocol estate machine that is going to be done in the tool cmarphy and eventually we want a full protocol for form aberrification this is important because as i said this is one of the reasons why you should have a full structured protocol because something's between the interaction of one estate to other estate is when errors and mistakes occur so you actually need to formally check all of these steps to catch up maybe issues of mistakes or potential bugs that can happen in a protocol right and we also really care a lot about security so especially in cryptographic protocols we actually want to be sure that the code that people are using is like reasonably secure so we want to sort of like start working towards fuzzing so we want to integrate parts like lip fuzzer and using like stuff like afl and hopefully we can run that on like the other the OSS fuzz 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 there's like a security pgb key on like security at otr.im so if you ever want to email about any flaws that you find please use something like this or email the otrv4 people on the the autonomia digital email address and we you know we don't only stop there we also actually want to gather a professional security audit by the code that we've been coding okay so just to have in conclusion what we wanted to attain with otrv4 is to design a very structured protocol 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 implementation a real world specification that actually says structure enough says what limitations this protocol has such which design decision it has such says which requirements it needs because that's 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 coming again with what we started at the beginning with the philip rower waste paper basically that's what we tried to do in otr that this is a protocol that tries to solve the problem of the ability as a basic right of people when they have in a communication in the digital world and also as something that takes into account this morality and takes into account the requirements and needs of the users when they actually need something that is specified good enough that is implemented good enough for them yeah and check out our repos they are in github this is the protocols we also have the library in c the pre-key server the toolkit our implementation half implementation which is not done in goland the implementation in java that was done by danie is been is going by danie van heumann and yeah and check out 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 an sort of otr community website called odio.im which also has a github a github instance and we have like various like continuous integration possibilities so if you ever want to move from github for example a github we are like happy to host you on this platform and provide continuous integration capabilities for you okay we also wanted to thank everyone involved otia 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 um 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 has collaborated you can also you can always check our repositories here's some time for experience if you want to know the papers we base upon this talk and yeah questions yeah thank you and of course thank everyone involved for the amazing work on otr and thank you for the great presentation we have time for questions so line up 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 will the protocol also support media other than texts such as vip or 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 otr because they are the ones who also did right now the newest papers and the reason why we wanted only to update otr is because otr has always been the inspiration to other protocols the signal protocol base itself on otr so we wanted to first update otr only in the past trevor perrin when we first pushed the first draft of the otr he suggested us that we should also publish the first draft 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 in otr if you want encryption of video or attachments you can always use the thing that's called the extra symmetric key for those purposes yes they were actually already implemented in the otr version three so i said no actual implementation happens thank you microphone number one well my question is related to the capability of omimo to support multiple devices which is very important in a modern world and i wanted to know if otr before can do this and still provide its stronger say our deniability guarantees thanks so much for your question this actually moves us to this congratulations okay um this this is a common question that we have and part of the question i think is also important to answer this so right now otr before and since otr v3 otr has a thing called instant size that is the ones that actually um identify several devices so 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-synchronization between devices that's not there but of course you can use several devices and if the devices recognizes which instant stack that belongs to it will always send to the correct device if you want difference with omimo is that of course otr before and otr is more agnostic and by this it means that otr can be built upon any other messaging protocol that they exist not only x and bp if you want to build otr over irc you can do so and even today because we're supported offline messages you can also build it if you want as an email and of course otr has better deniability properties i have not seen any paper that actually said deniability properties in the concern of multi-synchronization devices maybe that's something interesting to look upon and of course otr before has a little bit of much more well-defined specification thank you as a reward for unlocking the secret slides we're going to have a question from microphone one again um yeah 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 um so basically that is much more in the sense of something that is deployable in a mobile devices um and of a client and right now otr right now we are the stage of doing the protocol and doing the basic library so if someday we start walking into a client that is going to be supported by mobiles then of course we will have to tackle that problem but right now in otr we have not tackled 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 i think it also depends on like what kind of like messaging protocol you use underneath right like this will be sort of tough for like isc but like maybe xmpp also not really the problem but then if you get into like the sort of mobile landscape and everything changes and it's like more complicated um which is something yeah thank you um microphone three please um 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 for daily usage yes so um there has been some efforts in the past as we know there was at least one effort some years ago about doing mp otr and right now there's even a very nice paper that is called um where is this uh here um yes this last paper uh secure messaging is the one that actually defines like all of the properties that some um secure messaging protocol has to have in order to also support group chat and the thing is that there's right now not a good uh way of achieving the same deniability properties that you want um with the current current cryptographic algorithms that we have now about the future that actually looks very bright i remember that we attended pets 2018 and nicolas hopper already presented a paper around group chat and 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 uh conference nic unger also um told us that he's preparing a paper around good deniability in the sense of group chat so that is something that may be happening in the future thank you one more question from the internet could you explain how otr before forward secrecy is stronger than signals referring to the protocol comparison slide so basically um this depends on the kind of a key of deck that you use signal uses right now one day that is called x3dh uh extended triple diffie helman that is the one that provides that gives this week forward secrecy um the double ratchet algorithm of course gives perfect forward secrecy but the start of the deck with the with the double ratchet algorithm is the problem how you will define week forward secrecy is that only it will only protect the deck will only protect the session key when when both parties complete the deck exchange and in otr before we wanted to give perfect forward secrecy since the start of the deck meaning that it will 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 exchange to have the forward secrecy but in otr before we wanted to have that in a strong way thank you question from microphone one uh in the links there was a mention of a pre-key server is that uh server side requirement like signal does sorry is that the award a pre-key server yeah yeah and links it's the same as signal you asking yeah i think signal has some requirement in the server side is that a requirement for all the r2 signal defines also an untrusted server i don't know that much in our requirement from an implementation standpoint but our requirement from otr before is also that it's not trusted pre-key server meaning that we take all of the precautions that is needed when you're using an untrusted pre-key server we define the limitations because you can have a lot of the level of service attacks like someone can drag all of the the ephemeral material that you have on the pre-key server someone can can make um yeah someone can publish there's something else so we wanted to have all of the security considerations when using an untrusted pre-key server like for example the submissions that we do to the pre-key server are always authenticated also in a denouable way with the server um 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's no more ephemeral material in the pre-key server we just wait until someone publishes more to the pre-key server thank you what yeah and of course an untrusted pre-key server yeah thank you is not required unless you want to support offline messages some protocols may only want to implement the online version of otr because i don't know those are their requirements only if you need to use offline asynchronous communication is that you will have a pre-key server thanks uh one last question from microphone one i wanted to know if you um worked a bit in the between the integration of otrv4 and the other protocol actually one of the strengths of omemo is that it's perfectly well defined with how the key where the key are stored 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 xmpp while on otr you always have this like pre a little tag on the body of the messages which is a bit ugly and like so i would i wanted to know if you had some thoughts how about and oh if you do some work for otrv4 regarding the integration of otrv4 and the other protocol right so um you know it's slightly easier for omemo in some way because it's uh it it works only over xmpp um and with the otrv4 protocol we can sort of like uh federates over you know what kind of well i mean not federate but um get it to work over any messaging protocol now of course if you would do something like a pre-key server over isc that might get tricky in some way so that might not entirely be possible um so i think it sort of depends on what kind of messaging protocols 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 takes these things into consideration right to have a sort of extension that we can build upon where we can actually plug like pre-key servers into it um it's sort of like the reasoning i would use i mean if you have so one of the properties of course of otis 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 otr will not be part of otr but maybe from a separate document in which we can give recommendations for implementers upon building upon xmpp on the actual implementation we haven't found that much trouble the only trouble in the xmpp thing implementation that we found out is that we actually needed to uh discover the pre-key server and when we were using the pg in um library there was not an exposed header for actually doing that so we had to do some tricks to actually do that thank you that was the last question thank you for the amazing talk thank you for your work thank you