We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

USE OTR or how we learned to start worrying and love cryptography

00:00

Formal Metadata

Title
USE OTR or how we learned to start worrying and love cryptography
Title of Series
Number of Parts
199
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
USE OTR (USable Encryption with OTR) is an organisation with a simple goal: improving security, usability and encryption of IM software. This talk will outline our organization, the ecosystem of Off The Record Messaging (OTR) and how to start loving end-to-end encryption. We are an organisation that works on security, encryption and usability of open source instant messengers (IM). One key aspect is to have developers, resources and funds available to maintain OTR software over time and thus making them sustainable, up-to-date and secure. While we have already started collaborating with the LEAP project, we want to extend our network and reach out to more people. By developing safer, usable encryption instant messaging tools we believe that it directly supports freedom of speech and expression worldwide. Following this, we will explain what "Off The Record Messaging" is, the current state of the ecosystem around it. We want to raise awareness about the importance of using end-to-end encryption and bring the open source community together to help with this endeavour!
Bit rateCategory of beingStability theoryPlotterEndliche ModelltheorieProjective planeGoodness of fitSoftware developerRule of inferenceSelf-organizationPhysical systemProcess (computing)Kernel (computing)Module (mathematics)Level (video gaming)Line (geometry)Cartesian coordinate systemFrame problemLetterpress printingDampingPerfect groupNeuroinformatikStaff (military)TelecommunicationEncryptionRevision controlClient (computing)Server (computing)Multiplication signWordUsabilityTwitterState of matterOptical character recognitionSlide ruleAttribute grammarPlug-in (computing)Software bugData miningSoftware testingMereologyRootkitMetropolitan area networkRootLecture/Conference
Point (geometry)Service (economics)Process (computing)Group actionPlanningGreatest elementWordFingerprintFormal verificationLevel (video gaming)AdditionWikiEncryptionXML
Arithmetic meanMereologyCommunications protocolAuthenticationFormal verificationPlug-in (computing)Point (geometry)WordHeat transferTransformation (genetics)Lecture/ConferenceXML
Water vaporCryptographyOrder (biology)Multiplication signInformation privacyStress (mechanics)Metropolitan area networkDistribution (mathematics)Prisoner's dilemmaFingerprintPoint (geometry)Residual (numerical analysis)CountingKey (cryptography)Message passingTracing (software)Error messageExecution unitBootingTerm (mathematics)MereologyTelecommunicationAttribute grammarInformation securityComputer animationLecture/Conference
Term (mathematics)Optical disc driveClient (computing)Execution unitMathematical optimizationSoftware developerProjective planeCuboidMassQuicksortOrbitWordInformation securityCategory of beingFocus (optics)Electronic visual displayMessage passingVideo gameCommunications protocolMathematicsCryptographyPoint (geometry)Process (computing)Moment (mathematics)Data conversionMereologyJava appletLibrary (computing)Stress (mechanics)Field (computer science)Pattern languageGreatest elementSpacetimeInformation privacyElectronic program guideUsabilityWindowInstance (computer science)HypermediaEncryptionPatch (Unix)Default (computer science)Ultraviolet photoelectron spectroscopyFile formatComputer programMultiplication signLevel (video gaming)Functional (mathematics)Medical imagingSoftware testingBitPhysical systemSummierbarkeitRootCodeRoutingLine (geometry)Grass (card game)CollaborationismSoftware bugTwitterAnalytic continuationGoodness of fitOpen sourceOnline chatGame theoryLoginState of matterElectronic mailing listInstant MessagingEmailCASE <Informatik>Translation (relic)Bridging (networking)Computer animationLecture/Conference
Instance (computer science)Euler anglesCellular automaton1 (number)Revision controlMoment (mathematics)BitMereologyInformation securityMultiplication signOnline helpProjective planeExtension (kinesiology)CodeKernel (computing)Field (computer science)Library (computing)Order (biology)Arithmetic progressionAreaLine (geometry)Exception handlingDataflowDigitizingSheaf (mathematics)Endliche ModelltheoriePoint (geometry)PlanningNormal (geometry)Block (periodic table)Focus (optics)Instant MessagingSoftwareAtomic numberMathematicsSoftware developerProcess (computing)Digital photographyElectric generatorVideo gamePRINCE2CryptographyPole (complex analysis)Right angleWorkstation <Musikinstrument>Pattern languageWindowComputing platformDistribution (mathematics)ImplementationTerm (mathematics)Physical systemDirect numerical simulationBridging (networking)Bit rateError messageNetwork topologyGoodness of fitInterpreter (computing)System callClient (computing)Software maintenanceCuboidBinary codePatch (Unix)Software bugSelf-organizationPlug-in (computing)Communications protocolSinc functionDifferent (Kate Ryan album)Cross-platformMathematical analysisSlide ruleFingerprintDemosceneShared memoryCartesian coordinate systemAuthenticationMetadataMobile WebLecture/Conference
Web browserArithmetic meanCondition numberGroup actionInformation securityoutputMathematical analysisProjective planeMultiplicationWeb pageMultiplication signOnline chatEncryptionSoftwareLine (geometry)Latent heatPlanningPoint (geometry)CryptographyUsabilityLevel (video gaming)ACIDObservational studyEndliche ModelltheorieMessage passingCartesian coordinate systemInterface (computing)Affine spaceClient (computing)MathematicsVector spaceDivisorMetropolitan area networkCategory of beingMereologyFormal languageQuicksortCommunications protocolDifferent (Kate Ryan album)Texture mappingProcess (computing)Software developerVideo gamePlug-in (computing)CuboidWater vaporGodLink (knot theory)Slide ruleReal numberInstance (computer science)Goodness of fitTerm (mathematics)TelecommunicationAsynchronous communicationNormal (geometry)FacebookGame theoryMetadataDrop (liquid)Open setComputer clusterServer (computing)BitComputer virusCASE <Informatik>Angular resolutionLecture/Conference
Link (knot theory)Client (computing)Plug-in (computing)Semiconductor memoryMultiplication signMereologyData conversionSound effectDiskreter LogarithmusEncryptionPrimitive (album)Elliptic curveCone penetration testEndliche ModelltheorieContent (media)CryptographyPhysical lawVideo gameProjective planeError messageDrop (liquid)Forcing (mathematics)Different (Kate Ryan album)QuicksortCommunications protocolOrder (biology)Element (mathematics)Gamma functionInsertion lossMessage passingGroup actionPlanningEllipseInternetworkingMathematicsServer (computing)Natural numberGeometric quantizationOnline helpIncidence algebraOracleProof theoryTelecommunicationContext awarenessParameter (computer programming)SubsetPersonal digital assistantElectronic mailing listCoefficient of determinationPressureForm (programming)Software testingBuildingBitPoint (geometry)Information securityMachine visionRight angleStaff (military)Web pageMiniDiscComputer architectureCASE <Informatik>Utility softwareComputer programPublic-key cryptographyFunctional (mathematics)MultiplicationLatent heatFront and back endsWhiteboardFrequencyMobile appPattern languageClassical physicsPhysical systemScripting languageEmailMetadataOpen setIdentity managementTouchscreenAxiom of choiceLoginComputer animationLecture/Conference
Transcript: English(auto-generated)
All right. So this is working. All right. So hi, everyone. I'm David. This is Yoda. We're going to talk about the use of OCR, which is the organization we created a while back ago, a year and a half ago, called usable encryption with OCR. So yes, it's an OCR talk.
We're going to go over OCR, the state of OCR, the ecosystem, and what's wrong and good about it. So it shows a man here who heard about OCR. So you heard about OCR. So I'm guessing you're using OCR, show of hands, every day. Great. OK.
So there's going to be a small introduction about what is OCR and what is the properties of OCR. But before that, we're going to introduce ourselves, of course. So I'm David Goulet. This is my Twitter and OCR key. The slide's going to be online anyway, so you can get it afterwards. Just to change this plug before we start, I do work on the new version of Tor socks
at Tor. I'm not employed by Tor, so I'm just a contributor. So please check it out, test it, use it. We fix a shitload of stuff. RSSI OCR plugin has been rewritten from scratch also because it was unmaintained and had a huge amount of problems.
RSSI OCR plugin is hosted by Koutou Dares. KJackal, that's pretty nice, it's a small project of mine. It's a kernel rootkit scanner. Linux kernel root scanner, it works on 3.13. You load the module, it scans your kernel and it checks if there's a rootkit. And finally, LTTNG is what I do in my day job. Linux trace toolkit, maybe some of you saw me yesterday at the LTTNG tracing talk.
So please contribute, test them, it's pretty fun stuff. And Yuda. So my name is Yuda, I'm also known as Dr. Wax. I would actually like to add something about the ASC plugin we have been creating. If there are any ASC developers out there,
we've been struggling with a bug for a long time. So if you're an RSSI or ASC developer, please come later to us. We would like to have a chat with you. Alright, so what is OCR?
Yeah, you ready? So what is OCR? Use OCR project, a small recap of what is a use OCR project, how you can contribute, how you can help us. And then the state of OCR, and now afterwards. Is it nothing working? Great.
So, OCR is end-to-end encryption. It means it goes to client to client, and in between there's nothing going on for servers to see what's, to be involved in the encrypted communication. It provides four incredible attributes. This is why OCR is awesome, is that it's encryption, of course, authentication, so you know who you're talking to,
deniability, and perfect forward secrecy. We're going to explain more in depth the deniability and perfect forward secrecy part because those are the two main attributes that are very useful for OCR. So, maybe some of you use Pigeon. This is an example of the Pigeon OCR plugin that is maintained by actually Ian Goldberg,
the guy who actually maintained the label to your reference, and also the guy who not created it but is working extensively on that. So, yeah, you've got this, I think those are from the pressfreedomfoundation.org. Go see there, they have wikis about that, great stuff.
So, unverified and private. So, unverified, you're starting to create a chat with someone else, and you don't know if you're talking to that person, but you're encrypted. So, you're unverified, but it's secure, but you're not sure. So, at some point, you do a verification. Verification of fingerprints, which is kind of a tedious process, not very user-friendly, and you
get to private. The bottom one is where it says private. It means you're encrypted and verified. So, you know you're talking to someone, to the person you're expecting to be. So, OTR, a while back ago, introduced the socialist millionaire protocol.
This is pretty neat. You ask a question to the other person, and this question, only this person should be able to answer it. And the answer comes out. If it works, you're authenticated, you're verified. So, this is the authentication part of OTR. Pretty useful,
every plugin that exists are supposedly supporting S&P. I think some of them are not. I'm not sure. This is a good thing, because often, and especially nowadays, journalists use a lot of tools. For example, I think, hopefully, they use TILs, which is like the distribution using Tor, but it doesn't leave
any traces. So, every time you boot up TILs, you have to generate a new key. And because you need to generate a new key, you can't verify that the people who use a new key on that account is actually the same person you are talking to. So, this is why S&P is really useful, because you can ask the person a question, even though they have a new fingerprint.
So, you can verify that the people you're talking to are the people you are talking to. And we can't stress this enough. Please do that every time you use OTR. It's very important to verify the person in front of us. Or, if you're trying to be anonymous, of course they don't verify, right? All right. So, then, perfect forward secrecy.
So, this is a very, very nice feature, and it has especially been brought up in the public debate as of the Snowden era, since 2013, where HTTPS now also support, of course, can use perfect forward secrecy. So, basically, you had a session, you're transmitting messages,
it's going well, and at some point, your keys get, like, not compromised. So, this means that from that point on, every message you're going to create will be readable by the person you get your key. But perfect forward secrecy makes sure that the message previously,
well, you can't do shit about it. That's the beauty of that. So, it makes things much more harder for our friend up north to America. So, yeah, there you're going to small schematic of what's going on perfect forward secrecy. So, this is very, very important in terms
of cryptographic and security standpoint of view, where it adds very strong cryptographic attributes and guarantee to your communication that are pretty much secure. So, all right. So, the deniability part. So, OTR has been created with the deniability feature, which
explains like this in lamest term. Hopefully, we didn't make any mistake because, to be honest, we're not cryptographers at all. We're just developers. But, basically, deniability means you are pretty assured that you receive a message from Alice. So, this is what OTR provides you as
grantee. But you can't prove that it's been written by Alice. So, what's going on with that is if you ever get compromised with OTR, for instance, you're just your communication. Well, mathematically, it can't be proven that you actually wrote the message. So, yeah, it seems like a pretty nice feature, but
actually, we don't know if it's been used in court or legal battle at all. And if someone here knows only one case where OTR logs have been used, deniability, the deniability feature of OTR has been used, please raise your hand coming from speak up. It's very important. Because later on in the talk, we're going to talk about the multi-party
OTR situation, and deniability is one of the big problems in there. All right, so, yes, protocol agnostic, this is very important. Basically, OTR is just base 64 messages that are translated over in any protocol. So, you, if you want, you can create a Twitter OTR session. So, this is very great.
This is pretty great, pretty good feature, so this is why it's being implemented in a lot of protocol. RC, Jabber, XMPP, and all of those unknown protocol. Offers great security, of course. It's a peer-reviewed design, and I cannot stress this enough. You all open-source people, yes,
but peer-reviewed is very important. Collaboration is very important. And OTR, for the last 10 years, exists for the last, approximately the last 10 years. The design or peer-reviewed, the design are checked, are worked in a collaboration on OTR mailing list in the academy with cryptographers and developers.
And this is a key feature where we know it's working, it's a good, it's a good protocol, and there's a community around it. What we try to use with OTR is grow that community bigger, so stuff get maintained, and don't have abandoned ware. And, yeah, of course, open-source. And the good thing about it is that that's what Snowden is still alive, because people
use OTR, together with Glenn Greenwald and a lot of poet fields, and Jacob Applebaum and a lot of other journalists around the world will use it. So thanks to OTR, which we know we work, and it was not as sad that it can be cracked by the NSA, as of yet, as we know. It's good stuff, as we can see, because people are still alive and working continuously.
Yeah, as it was, I was told last night, OTR fucking works, because it was not still alive, as he said. Use OTR project. So, back in December 2012, we have been working on, and even before, we've been working on securing existing clients,
for example, Pitian and Adium, which are based on libPurple. We found out that these clients are being used quite a bit by a lot of people, and we've been hearing quite a lot from the security community that although Pitian is a really great client and it has a lot of functionality,
not always usable for everyone, but it has a lot of support for protocols, it has some security issues. So, we have been auditing some stuff, and we found a lot of awful bugs, I have to say. And at that point in time, we were like, gosh, if this is going to be so easy, we're just going to submit
a thousand patches, and it's going to be a secure client in a year, and everybody can use it. Turns out, it was a bit harder than we thought it would be. We found eleven bugs in the Windows build alone, which means every dynamic library was compromised.
The oldest bug was six years old, which was pretty good. So, then we submitted some patches, and we said, hey, you know, if you're just going to ship with new libraries, you should be okay. Unfortunately, that bats took six months for Python to ship. I have no idea why. Maybe they elect a lot of people.
I'm not sure. So, in February 2011, they shipped the security update. So, at that point in time, we were like, gosh, is this still a good idea to mainly focus on the security of the existing clients? And then we were like, probably not, because if we have to audit, and we'll come back to that later in our talk,
if we have to audit 300,000 lines of code, that's going to be kind of an issue in C. So, we've decided to take another route at that point in time, and just to say, hey, why don't we write a new chat client with usability, privacy, anonymity, and encryption by default,
which is going to be really minimal. It's going to be usable. We want to work with usability people, we want to bridge gaps with journalists, with the end users quite a bit, translators. And then we were like, well, there's some other stuff as well, and that is that we want to grow the OTR community.
So, at the moment, we are kind of involved into coming up with ways to make this all better, and make the protocols work, the new protocols, like, for example, multi-party off-direct messaging, and I think discussions about deniability, how we can improve the clients, and what is actually,
what do people need from a new chat client in a really digital age, where everybody is on this mobile and having, like, sending a message, and then 15 minutes later, you're sending another message. It's really asynchronous. It's not so synchronous as it was maybe, you know, six or seven years ago. So, we've changed our
mission throughout, well, one and a half years, and I think what we have now is we're going to be stuck with this for fixing everything. Fixing everything. Yeah. Want to go in? Yeah. So, as we've said, usability is the name of the game because usability is actually a security feature. So,
for example, some clients make it, well, it's not always a client issue. It's that sometimes security principles are hard to grasp for the end user. So, for example, if you start an OTR conversation and after you're done with the OTR conversation and the person is still online, you finish it. So, the other
person finishes the OTR conversation and the other people say, oh, it's finished, but if I'm going to send a message, it will say that the OTR conversation is finished and I actually can't send the message. So, what does the user do? They will start up Skype or some other client
and start chatting with that thing and that's when you lose the OTR property because you're not using OTR anymore. You are using a normal chat client and that's fucked up. Then you lose the security of the end user. So, usability is a security feature and we would actually like,
you know... Sorry. Yeah. We would like to have more discussions with people who have been working on chat clients, for example, like Pitian, LitPurple, Pitian, Adium and Jitsi and there's countless of others. I think CryptoCat is a pretty good example of how a chat client can
actually work and it's pretty usable for the end user, at least more than all the others. Maybe it's not perfect, but it's pretty good. So, we would like to have more discussions with developers about usability and also about some security bugs we have found in some clients.
So, if there are any Jitsi people, for example, in the room, we would like to have a chat with you later on. Yeah. So, as Julie said, usability is very important. I'm pretty sure, like, in the last
years, everyone has been hearing that, being remembered about that, listening about that. So, now the state of OTR. This is the OTR SQL system in terms of stand-alone IAM clients. So, there we go. We have PsiPlus, Adium, Adium on Mac, of course, Pidgin, RSSI, Jitsi. So, all
of those uses custom plugins. So, OTR plugins are created for that application alone and so, some of them use implementation from Java, the OTR4G, Jitsi, for instance, I think, and the Guardian project, if you know,
the mobile area. I have another slide for mobile, though. Or they use the label-tr. Label-tr is a C implementation, an API. But they all created, there's no, like, best practices of creating a plugin. You just use the library and you try to understand what Ian wrote in the comments section and
then that's it. So, what happened is, when we took a look at this situation in the IAM's client, it turns out that most of the clients, except for some of them, the most commonly used, Pidgin, Adium, PsiPlus is being maintained.
Well, actually, the plugins are not maintained, or they're badly broken, they're not maintained, or there's one person sometimes trying to work on that. And this is actually a big issue because as OTR progress, and actually it doesn't progress that fast, but when it usually changes version, or protocol version, well, those plugins need to follow because else there's a huge amount of problems, security
problems. So, this is one of the reasons we need your help, just to help maintain this thing. So, for instance, there's the OTR RFC that is being started by what is it, Peter? Peter and Paul Waters. And Paul Waters. It started on GitHub there.
If you want to add a contribution or review, great, the OTR RFC, so we can then have clean request for comment and use and implement OTR. Well, the DNN authentication also, it's a draft from Paul Waters. Yesterday, there was this
talk about DNN DNN authentication. I think it's a post. That was great. This is the same for TIR fingerprints. So, again, please review those drafts. Check those drafts. They're pretty interesting. We're going to have two slides about Pigeon in purple, and Yodev is going to explain why
just to show you the issue here. So, as I've been telling previously, we've been looking into Pigeon and how we can make things better. So, what we found out is that Pigeon is just a bit more than 300,000 lines of C code, which is quite a bit of code.
As you can see, if you look at the Tor code size, which is for just a Tor binary alone, it's about 120,000 lines of code. So, it's almost two and a half times, three times the size of Tor. And I think Pigeon, do we count plug-ins in,
or is this just the base? It's the old Pigeon called LibSiri. So, it's LibPurple, Pigeon and stuff. LibPurple, Pigeon. Which is quite a bit of stuff there. And, of course, it also has to be multi-party, so that's why I think it's a bit bigger than efforts. But, as you can see, it's quite a bit of C code.
So, I've been auditing the internals, and it has a lot of dependencies and other stuff. So, we've been auditing that stuff, and I think it's a bit too big at the moment. Could you do the next one? So, since then,
you know, this actually came out, I think, a few days ago, which was a pretty good talk about somebody putting in two days of his own time into auditing Pigeon and fixing some bugs and submitting patches. A security patch also went out, I think. So, since 2005, it had about
60 CVEs. So, we've been auditing mainly the 2.0 codebase, which is, it's getting old and getting a bit sloppy. The tree is upcoming, and I'm really hopeful for that. Apparently, it's going to look cleaner as well.
It looks better. So, I'm really looking forward and from what I've seen, it looks more structured, and it looks like they cleaned up a lot of old code and made it better. So, I'm really hopeful that Pigeon 3.0 is going to change a lot of things because it's shipped by a lot of distributions and it works on multi-platform
on Windows and on Linux. So, actually, could I see some hands over who uses Pigeon? Yeah, okay. Yeah, we need to fix this. So, there's one point that's very, very important is that if there's a little purple in the room or Pigeon in the room, it's very important to
like, we need to talk about it. We're not bashing Pigeon at all. The Pigeon situation here is that security is not their focus of development. And so, it's not an issue of they don't, they do bad work. It's not that at all. Maybe they don't have the resources to put out in security or they just don't have the experience and so on and so forth. This is why we need to
work in multiple fields to create that kind of secure item chat. Because, as you've seen, it's half size of the Linux kernel networking stack. It's a lot of code to maintain, especially in C. So, they need help if they need, they really, really need help to improve in terms of security. There's a slide share.
Go there. It's pretty awesome. Quick analysis of what's going on with Pigeon. All right, so I'm pretty sure you guys know Moxie Whisper System. So, there's this nice quote that came out, I think, last year
when a new IAM chat client on mobile was created. I don't remember his name at all. So, there's one thing here. It says, they generally fucked up. So, in terms of own crypto, of course, you know, you shouldn't do that. This is why OCR has been created a while back ago
to address a problem and developers can use it. They don't have to create their own crypto. So, of course, you create your own crypto, generally you fucked up even though you're cryptographers or developers. I mean, mathematics is kind of closed from computing but there's a big gap in between in terms of security.
But, the other part is that there's a small community of people. And this is actually changing in the mobile scene. As you see there this are just some of the mobile secure chat client you can have. So, the thing about why
we put on the moxie's quote is it's not like if you want to get involved in creating an IAM chat we're helping that. It's not because you're a newcomer you're going to fuck it up. It's because there's not too much people. So, we don't really agree with the moxie, but again don't run out your own crypto. That's the basics. But we need developers to help.
So, yeah the mobile scene is quite impressive also. And we're going to just talk about one thing here. The Guardian project. So, show hands who knows the Guardian project. And it's not the newspaper. No, it's not the newspaper. It's something different. Alright, so the Guardian project is
a small organization that's been created I think they're based in New York and one of the maintainers there, Nathan is someone else. Anyway, it's in the United States. They created this OTR client that goes through Thor also. So, it uses Jabber with OTR to
Thor on your mobile phone. I just don't remember what's the name. The Orbot or Orweb. It's been switched recently, right? Or Fox now. Yeah. So, this is a mobile metadata issue. And why metadata issue is that with that kind of solution the metadata problem goes away where it goes to Thor to answer that.
If you know the TechSecure thing TechSecure, right? In Redfel. It goes to SMS with the OTR kind of protocol and the metadata is still there. So, think about it when you use a secret client on your mobile phone. The metadata
is very important, especially when we know what they're doing with the metadata nowadays. So, yes, Garden Project is awesome. They need contributors so go help them. Yes. All right. MPO-CR.
again, show of hands who heard about MPO-CR? The discussion about that. So, that's kind of something new, right? OK, so MPO-CR means multi-party OTR, means group chat. So, as of now, if you apart from RSC or some fancy jabber room group chat is pretty difficult. So,
yeah, Skype made it happen but we all know what happened, what's going on in Skype nowadays. So, maybe it's not a good idea to use Skype. So, at OHM 2013 in real world cryptography in 2014 there was a lot of discussion with cryptographers and some developers
to come up with a solution with the group chat because in cryptography this is actually a very hard I think it's a kind of unsolved situation for this OCR case. And so they came together, they talked a lot, they had sessions, so the two paths that are there are the notes from those two conferences. You can check it out.
Of course, they're open. The main problem is that when you put a lot of cryptographers in the same room trying to come up with a solution of MPO-CR which uses group chats new requirements. What is a group chat? What's going on there? In terms of technicality, language, OS and so on. Well, this is what
happened. The conclusion was yes, there's some requirements we need. Sorry, we have some problem over there but in the end it's just I want that name on that protocol and that's it. But MPO-CR is extremely important nowadays
so Cryptocat started very recently this project plan and they have very ambitious deadlines to come up with MPO-CR specification. I think it's March or April 2014 of this year to come up with the first draft of the specification after the notes. Thank you.
Please check it out. Again, they need help. MPO-CR is very difficult but it's very important to have it right now. Group chat, secure group chat is very important. Deniability of that thing is a huge issue. This is why MPO-CR does not exist today. Putting 100% in the room
talking to each other and having this deniability feature, I repeat deniability I'm not sure who wrote that but I'm pretty sure it's come from that person makes it extremely hard. So for the last months the discussion were do we drop deniability or not? And again, there's a huge discussion about the legal precedent of deniability
and is it useful? But hopefully we try to come up with solutions soon because this is really, really needed. Just going to talk quickly about Cryptocat here. Cryptocat is inside a browser. I'm pretty sure you all heard about Cryptocat. There's
been some issues with Cryptocat. Of course, if you don't write code, you don't write bugs. It's inside a browser. It's a plugin. The name of the game of that was usability and easy access because with Cryptocat you can still stalk and share your delusions on Facebook while chatting security.
So this user interface, there was a lot of work in the UX and the UI. I didn't have a slide for that but they worked hard for that but the problem is that of course they have security issues and people are using it so this is kind of dangerous so it's a kind of catch-22. You don't have users of course. You can't progress.
You can't progress and improve but you need security in the end to have more users. But again, Cryptocat as of now, in terms of group chat, it's the only solution out there, like reality solution in terms of OCR and group chat. One does not simply. Usability property, yeah, we got that.
We do need standalone IAM client today. Of course we need because desktop are still being used and it's a good thing not to put everything on your mobile phone. So yes, I'm trying to go fast because it's 10 minutes. So yeah, IAM client is immigration so you have a Facebook account that works with XMPP. Well, use that, fine.
We'll put OCR on that and that's it. And just don't depend on the web browser also because this is today's biggest attack vector. So maybe it's a good idea to have a chat in a web browser but it's also a good idea to not have that. So yeah, you remember those in 2000, right? So those
are the old AOL MSN stuff. Nothing has really changed. So the issue is that nothing changed in 2014. Still today, nothing's changed. We still see that kind of interface. But the problem is that you have this new reality now where when you send a message, you don't expect the person to be online or offline.
You expect just this person to receive it. So yeah, the text is pretty funny but there's also one thing here is the date. So I send a message and then an hour later I send another message and at some point this person's gonna reply. But this means that chat brings a synchronous the new chat now being used on
multiple devices. They sync and async. It's protocol agnostic. Basically your mobile phone integrate everything nowadays and so why are we still using those old AOL's thing? That doesn't work anymore. So the protocol needs to be improved as LTR needs to be in MPO-TR
and LTR has to be changed, improved to support asynchronous communication for instance and stop being that difficult to use in normal client. So last slide. Go check that link. It's pretty awesome. It's the chat festo. Thanks with the guy at Leap. The
L encryption access project. Chat Festo. It's actually new basic requirements of what a chat is today and we should think about that to create chat IAM communication software. So yes I'm going fast but this is the time we have. Big thanks to Leap. Come on our channel. Use OTR. Go on OTR and OTR dev
if you're interested. This is where the dev happens. Well use OTR is just to chat the people who create plugins OTR. Go on that channel. We bridge developers from different projects there. Guardian project is there. The ADM guy also has an ISSR of course. And yes thanks to Leap that is helping us a lot. So question time. Questions?
Yes. Hello. I have a bit of a critique. I've been trying to get into OTR for some time. You're going to speak a bit louder. I was saying that I've been trying to use OTR for quite some time. I knew about the Guardian project
which now they changed the server client whatever which doesn't make OTR easy at all. In fact it's not clear when your communication is encrypted or not. You can really start it. See if the person is offline and will not do anything. I was looking as you spoke with the
main OTR page and the plugins for many clients the links are broken. So I think one thing that is important for more people to use this is it seems that the basic tools to start using it are not really yet. It seems to me that there is a strong need for this kind of
work first. For more people to use it and make it useful. Yeah, so we agree with you that you're basically saying that we need more easy access to understand how to use those tools, those OTR tools. So just maybe fix
the broken links on OTR pages and stuff like that. Right, so yeah. So yeah, this is exactly why use OTR has been created is that there is an issue of using OTR in secure IAMs because it doesn't exist right now so we can't rely on any client as of now, unfortunately.
So yes, yes, more access to OTR. Yes, you. So have you looked into the work done by Open Whisper Systems? They have improved OTR also they claim. They've added support for offline communication they've improved deniability
and messed with the protocol. And second question is there a plan transition for the OTR to elliptic curve cryptography? Because there's predicted Can you repeat this because I'm not I can't hear. Is there a transition to elliptic curve cryptography plan for
OTR? Because there is script apocalypse predicted for the discrete logarithm and there are drop-in replacements for the primitives used by OTR today that use elliptic curves. So why not migrate to them? Is that planned? So the question is about the Whisper System OTR So the question
is kind of like why OTR isn't using elliptic curve cryptography right now? Yes, so there has been discussions over the past I think one or two years now about Louder? Louder. There's been discussions
about this for like the last year or so or two years and there have been some things holding it back and that's because of patterns basically. There's been a lot of discussions especially on the OTR dev list and the main argument was that if Red Hat didn't want to ship it or didn't
dare to ship it because they don't they do some elliptic curve stuff, they ship it now again in OpenSSL but there's a really big issue with patterns that people are afraid to get prosecuted or whatever so there are some issues there but we would like to see it happen and I hope it will happen
soon. Patterns might be gone for some elliptic curve stuff in the next two years maybe then it's hard to say Have you heard about Telegram? It's a new app and desktop
I'm gonna walk next to you because we don't have any... Telegram which they have published their own protocol and my question is if you think they are kind of newcomers who are fucking it up or it is really secure because a lot of people is using it
so I actually have no idea I have to say I've heard of Telegram, I haven't really looked into it in depth Have you? Telegram is kind of, they were very
outspoken Moxie who you quoted just now kind of destroyed that protocol in a couple of like hours That's your answer. Any other questions? I have two questions so first in the case of
an architecture like with Biddlebee you have IRC and Biddlebee where do you think that OTR should be? Should it be a plugin in Biddlebee? Or should it be a plugin in the frontend client so that even Biddlebee itself doesn't see what you're communicating?
I can answer you right away So Biddlebee I'm pretty sure can be set up remotely so you can access a Biddlebee server through the internet So there you got your answer you don't want to add into an encryption if you do that so use SSR OTR not Biddlebee OTR just for that reason And the second question
most of the clients you showed have logging functionalities and I've only found one client where it's possible to when you go OTR automatically turn off the logging. Is this something you're planning on doing or should somebody else do? We've been discussing as well with the ADM person who unfortunately isn't here but he has been working
on a new release for a while now and he has some pretty neat features including logging disabled Finally, fucking finally There's a debate about that where you say well maybe I want to be able to log or not be able to log so now the consensus is well just give the choice not to log I think the choice should be
that for every OTR conversation you start you give some kind of screen that says do you want to log this conversation or not or even if it's locked after the fact that you finished the conversation it should still be a memory and not on the disk itself There is also the bit
message protocol. What are your thoughts on that? The what? The protocol of bit message Bit message? It's also a client which aims for metadata hiding email so basically each message is encrypted with the public key of the receiver
and all the messages are mixed within all the clients so you don't know who sent the message So I think when bit message actually got started I think a year ago or something like that, people looked at it and I also looked at it and I laughed at it. I think it got better now
but it's still new it's still a new protocol so it needs some time for people to evaluate it and make it better so all these things take time to make it better I have no idea I heard that the security model for the multi-party OTR is not fixed
because at each conference you don't say exactly the same things Do you think that you will let some time for the cryptographer to propose protocol when you have the security model or you will just do with the cryptographer that you have in your team and
try something and don't go to the classical academic stuff and publishing and testing? The question is do we plan to use a different threat model for protocols?
Do you plan to publish the security model you want first and let time to different teams of cryptographers to propose stuff? Or do you think you just do it yourself? Well, one thing here is that if there needs to be changes to OTR
of course we need a long period of time to have this discussion I'm just talking for the multi-party OTR multi-party OTR yes, if you go in the Cryptocat MPO-TR project plan there's a reviewers board there's a specification that needs to be reviewed and at some point it's accepted
so there's a long path a long way through accepting the specification which is trying to use it as a proof of concept and then getting it accepted does that answer the question? I'm not sure my question was is it an instance that other teams of cryptographers
submit something or is it just already there's already people you can contribute I have no idea how it's working right now a Cryptocat but usually it would be good if yes there's
multiple teams of cryptographers looking at it so of course I'm pretty sure they're going to go that way also thank you time's up so if you have any other questions you can see us in front or something else thank you