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


Hey, this is Brett with Summit Auto and Fond du Lac, Wisconsin. You're new and used RAM and heavy-duty truck headquarters. And today I'm super excited to show you this really good-looking, brand-new 2020 RAM 3500 mega cab short box with the RAM box single rear wheel in diamond black crystal pearl. This truck has the 6.7 liter high output Cummins diesel, which pumps out 400 horsepower, and it gives you a thousand foot pounds of torque. It's made it up with the Isen 6-speed heavy-duty transmission and just a really good-looking truck. This is a limited level one with the black appearance screw. So really a good-looking truck. It's fully loaded, and we're going to go over all the options and just a really good overview of this truck. The first thing that you'll notice is it does come with the painted 20-inch rims. And this one comes with Firestone TransForce AT LT28560R20 tires, kind of an all-terrain tread pattern on them. You get the shock and the spring in the front. Fender flares on here. This one has the power running boards. You get the blacked-out RAM logo, the blacked-out Cummins turbo diesel logo, and the RAM or the 3500 heavy-duty logo is blacked out as well. You get the blacked-out headlight bezels. This one has LED fog lamps, the projector lamp, LED headlamps and running lights, front bumper parking sensors. This one has the 360 camera on it. Also it has the camera on the front grille there. And this one also has the clearance lights up top on the roof. Also power running boards. I'm going to show you the original window sticker here. Feel free to pause this at any second. I'm not going to go through everything, but definitely the high points, such as the 6.7-liter i6 Cummins high output turbo diesel, ice and transmission. Everything on the left is your standard equipment. It comes with the UConnuk 12-inch radio, Android Auto, Apple CarPlay, SiriusXM with 360, SiriusXM, one-year subscription, five-year serious traffic and traveling service, and Sirius Guardian for a year. Exterior, you get those 20-inch rims, the RAM box, 31-gallon fuel tank, full-size spare tire locking tailgate power slide and rear window, LED tail lamps, the receiver hitch and wiring, and then the sprained bed liner by Mopar and the deployable running boards. That all comes standard with the limited package. This one has the black appearance group, which is a $995 option.  Also the tow hooks and the 20-inch. Those rims are actually special for that black appearance group. Diamond black is the color that's a $100 option. The limited level one group gives you the Harman Kardon 17 speaker premium sound, adaptive cruise control, center stop lamp with the cargo view camera, full-spirit collision warning, surround view camera system, trailer reverse guidance and adaptive steering system. That high output Cummins diesel is an $11,995 option, and that comes with a 220 amp alternator. This one has the power sunroof, which is 1,095 clearance lamps, and then that automatic rear level air suspension is $1,705. Total MSRP on this one is $88,720. One of the highest MSRP's I've seen on a RAM, and for good reason, this is probably the best looking RAM we've ever seen. So anyways, very cool stuff. Love the piping on the seats. We'll get to the interior in just a second. I do want to show you the RAM box and everything back here. And of course, that auto level air suspension, there's that. You get the rear airbags back there, and then this is the bar. So once you get a load down on there, it presses down and it'll tell those airbags to actually pump up. And that's a pretty cool system. Do you get the RAM box here? So lots of room back here to store things. Also going to turn the lights on back here as well. And these lock with the ignition key. So just lock up the truck, and these lock too. You can also put ice and drinks in there, so you have like too many coolers wherever you go. LED tail lamps, painted bumpers, parking sensors in that rear bumper, full towing package, of course, with the receiver hitch four pin and seven pin wiring. You get the blacked out RAM logo, four by four logo, and limited logo there. Does the shock down assist. Also the power drop down tailgate. You get the cargo organizer, the bed rail storage system with the cleats, LED bed lighting. And then up there, you have your cargo cam. And just really nice spraying bed liner as well. Tailgate's nice and light. Do you get those heated fold out tail mirrors? So they fold out like so. They do have blind spot monitoring, directional signals, and running lights. And then you get the LED side lights. And then these are your cameras for the 360 camera, which is pretty sweet. And I'm assuming they also power fold in, which they do.  So those little mirrors on the bottom there, you can actually move those. Yeah, press that button and then which side you want to do. And you'll see that you can actually move those mirrors side to side, up and down. So that's pretty cool as well. And you turn those lights on with your cargo lamps. Those LED side lights, they get really bright. It has the nice wood grain trim, the nice intricate stitching on the bolster there. Power windows, power locks, power mirrors, memory driver's seat. Take a look at these real leather bucket seats here. The nice white stitching, the gray piping, driver's side lumbar, heated, cooled seats, all weather formats. Those are special for the limited package as well. Get this protector on the sill here. And auto headlamps, power pedals. And we'll hop inside. Check out the instrument cluster here. Get that cool, get the cool graphics at the beginning of the screen startup there. You get your digital spinometer, outside temp, compass display, can change all four of those corners to read pretty much whatever you want. You have the nice blue hue around everything. Looks really good. And that's special for the limited package that designed there with the blue and everything. You get the wood grain trim steering wheel. Here's your adaptive cruise controls, your regular cruise controls, your gear selector, Bluetooth and information center controls. And you do get audio controls on the back of the steering wheel. Over here is your 12 inch Uconnect 4C radio, AM, FM, Sirius XM radio capabilities. You have the factory navigation system on here. Lane departure, stability control. Push button, four wheel drive, factory brake control. You got your alternate trailer height. So you can set up different trailers if you have multiple trailers to be different heights for each trailer, which is really cool. There are your radio controls, your heated and cooled seat buttons. You can check out your backup camera pretty much at any time. And that's an HD backup camera. You can also zoom in on that backup camera to get right over the receiver hitch. You can check out your cargo cam. You can also check down the sides of the vehicle, which is really helpful when you're towing and parking a trailer. And you can go to either side. So pretty cool stuff there. Definitely a lot that this radio can do. You have all your apps here as well, including projection manager, where you can project your cell phone to the screen via Android Auto or Apple CarPlay. So if you have a different navigation system on your cell phone, which is Waze or Google Maps, you can project that to the screen and use that. Instead of the factory, we actually did a demo on Android Off. You'll want to check that out. It's in the upper right hand part of the screen. I mean, you do have that surround view camera as well. And you can see that on the left there, basically a graphical representation or a picture of everything that's around you using all the cameras around the truck, which is really cool as well. You can turn those step bars off. Just a ton of stuff we could do with this radio. We could talk about it for hours and hours and hours. Factory brake controller. You got two USBs, two USB C's, Augs jack, factory exhaust brake, tow haul, and your parking sensors. You can turn those off and on. It has the RAM cell phone charge pad. Just put your cell phone in there and it'll automatically charge. You have your keyless entry with your remote start. You also have the power drop down the tailgate. The limited's always have this kind of bronze-ish, gold-ish trim on the key fobs. And it tells you that you definitely have a limited truck there. Down here you get a 115 volt, 400 watt plug-in. You get the limited badge on the center console there with the stitching. Really cool. This cup holder slide so you get more storage. In here, in coin slots. And you get the dual glove boxes over there. More of that kind of gold-ish trim throughout. And the wood grain trim. And then of course it does have your auto dimming mirror, your power or your home link system for your garage door security systems and lane systems, SOS and assist. And your power sunroof up here as well. You get the speakers in the ceiling back there. Get the limited leather care guide on the seats. And I'll show you the back seats so you can check out all the room that's in the mega cab. And then we'll do one more final walk around. So a ton of room back here. Does have the latch child safety system for any child car seats you may have. You get that full leather seats back here. That intricate stitching up on the top of the seat. So these seats fold on two different ways. One way, if you have the headrests all the way down in the seat forward, that seat will go down all the way and it'll actually go nice and flat. You do get a little bit of storage back here. Child safety latch tether anchors. Power slide and rear window with the built-in rear defrost. And then if you just want the backrest down, you put that down like so. And you have a higher low floor to put stuff in. Otherwise, when that seat's moved up, you can actually put this seat all the way down flat. And then you can have a nice flat area back here. These back seats are heated. Two more USBs, two more USB C's and 115 volt, 400 watt. Plug in back here again. Get the Harman Kardon speaker cover. Really good looking in child safety locks. So we're gonna do one more walk around so you can see the LED lights and everything, including the LED license plate lights. And I would personally like to thank you for checking out the video today. And hopefully from this HD video, you have gotten a really good idea of the overall looks and styling on the limited level one with the black appearance group. There are those ultra bright headlamps. And hopefully you enjoyed the video. Thanks for checking it out. And remember to like, subscribe and share. And to see more pictures of this truck or one of our other 450 new and used cars, trucks, SUVs, minivans, wranglers, half tons, three quarter tons, one tons. You name it, we got it at our website, www.summitauto.com. Full pictures and descriptions of every single vehicle from two locations all at summitauto.com. And if you'd like to check out more HD videos, you can go to youtube.com slash summitauto. Remember to like, subscribe and share on this video and all the videos that you see there. In fact, in a second you will see a link to subscribe to our YouTube channel on your left. A link to more Ram 3500 truck videos like this one on your right. If you have not been to our website on the bottom link to this vehicle on our website, click those, check us out. And we're super excited to be offering this really good looking 2020 Ram 3500 mega cab, short box, ram box, limited level one with the black appearance group and diamond black clear crystal. Thanks again for checking out the video.


I'm Jared Quested. I'm from Baltic, South Dakota. So what we do on our farm, we farm corn and soybeans, and we have a small feedlot where we feed background cattle. We homesteaded a few miles south of here in 1886, and we've been farming most of our land since then. I've been part of the farm as long as I can remember, I guess, but when I came home from tech school in 2012, I had some different ideas of how I wanted to do things, and we've been starting in no till now on our third year on most pieces and excited to continue on with that. It's just one of those things that the more you do it, I think the more we'll see the benefit. You know, the first year we tried it on a couple pieces and just, you know, went in and kind of tried to figure it out and had to adapt the planter a little bit that first year to do some things, but the next year we decided to do just about all of it into no till, and we had to do a lot of adaptation to the planter to make everything kind of run through like we wanted it to. So, you know, once we got going, it was pretty simple, and then we found, you know, the amount of man hours it didn't take for, you know, running a tillage tractor all day or, you know, just all the fuel that we would have burned, you know, that way too. It just simplified our lives quite a bit to be able to do the no till. The second year when I started telling people, like, well, I think, you know, we're just going to go ahead and leave the disc unhooked and just go ahead and plant fields, and that's when guys were like, are you sure you want to do that? You know, how much yield do you think you're going to give up? And, you know, a lot of these questions come around, and my basic answer was, well, I don't really know, but I'm pretty certain this is going to be the right way to go just because there's a lot of good history around the area of the people that are doing it that seem to be quite successful. We got hills and, you know, valleys and all things like that. Probably that's part of the reason when I started really seeing the benefit was, I think it was two or three years ago, we had a really heavy rain, and we just got done tilling and we had all kinds of washouts and, you know, all kinds of erosion, and it's like, that takes forever to get that back to where it should be. So right after that is like, we got to do something different. So now we've stopped disking all these low spots, you know, that are highly erodible. You know, the low spots aren't so bad, but going up into the hills and such like that, you know, we just leave that alone. We can just farm through them rather than having to till them up and have all the washing happen again. You see that these fields that are all tilled up and everything, I mean, there's just no structure to the soil anymore. It just completely just falls apart, so when we get those big washing rains, we can see why that happens, these fields with higher organic matter and better soil structure from the no-till. When you get heavy rains, rather than it washing away, it catches more through the organic matter, and then it'll go down into the soil where we actually need it. Since we do have the feedlot, we had a lot of manure that we were disking in yet, because that seemed to be the only way to do it, but it's kind of one of those things that you learned to do the application a little bit different, and you might be able to have some different success with no-till with that. So this year, we have right about a hundred and some acres that we're going to have manure spread over lightly, and then we're going to no-till right into that. With the no-till situation, I think the benefit is to towns that are downstream is that maybe more of our nutrients that they're afraid are getting into streams are being absorbed into the soil and being used by crops rather than being washed away, which makes it more economical for us, because then all that money we spend on fertilizer is where we put it, not washing down somewhere else. So I think there's benefit to just about everybody by using no-till. After you spend a little time getting adjusted, I think all that yield that you might lose the first couple of years will come right back to you. You're going to save money on the fuel. You're going to save money with the fertilizer, because that's staying where you put it. And through all these different practices, you're probably saving quite a bit of money, but then in the long run, you're gaining yield because you're increasing the value of the land. Once you get all the good things going, you still got to preserve the land. And if you preserve the land, that's going to help you produce more than anything. So generations have come. You know, hopefully our land is worth more than it was now when I'm starting.  But then in a couple of years, when you start seeing that soil structure change, then you're going to really be happy you did. So, I mean, there's no reason to wait any longer.