 So without further ado, please give a big hand to our next speaker who will be talking about Encrypted Email. Hi. I guess you can hear me, right? Welcome. Buenas. I guess you are not in the wrong talk. We are here to talk about Encrypted privacy-oriented services, especially email. I'm going to confer something. I just finished the slides 10 minutes ago. So this is my practice. A little bit of history. We are in a very interesting place. We are going to talk about old protocols. I'd like to introduce some history about the places we're in. This was a shipping company, a shipping factory that started in 900 and ended in 1984. When I discovered that on Wikipedia, I said, wow, this is a really good omen to talk about privacy. In the riots with the police, one person, one worker was killed here. By the way, the slides are in here, and many of those things are links because I don't want to get too technical. I am here more interested about talking about tools. This is the Karol crane out there. We have the whole year. We have IRC. We have mailing lists to discuss about technical details. Actually, I'm merging two talks. Holger Greco, I guess some of you will know it. I just met him two months ago. He was going to give another talk about a two-word secure email. For personal reasons, he couldn't make it. I decided to put together some of the conversations we were having and try to merge the talks. I'm intending to do two different parts. One more about high-level philosophical questions, if you want, and strategy. We are a community that builds tools. The other part is about actual tools. I work in something called Leap Encryption Access Project. We gathered four years ago to decide to make encryption accessible. My role in the team is this. I'm probably not the best person to be here giving this talk, but I was just passing around Europe and nobody else could come. So forgive me for my ignorance. This is my first talk in kind of a serious manner. I started doing Python 10 years ago, but this is the first time I'm actually trying to present something to the world. So, Leap, what do we want to do? We want to make privacy usable at all levels. And the motto is we kind of feel that we have to defend the right to whisper, because privacy is about the right to whisper. Some of the really smart guys that started this project are coming from these kind of collectives. Someone here has a rise up account. Good. Rise up is a tech support collective that gives support for activists. It's like the Gmail for social movements. And this is a problem, because when we start centralizing things, we have a single point of failure. But we are a non-profit. We are something more than a non-profit. We are kind of a distributed network of people that think alike, that wanted to do something in some specific way and just we look for the way of getting money to do it. Towards by using grants, by using research projects, but we are more people than the people being paid by the particular project. And this is very interesting, because it frees you from the startup mindset. So I probably, since I knew I was going to be very nervous, I probably took the tips for speakers too literally, but I kind of found it fun. So I'm going to present a kind of adventure in which we meet the non-heroes, I'd say the anti-heroes, that go on a quest, find some weapons, you can guess which kind of weapons we use. We met some allies in the road. We, probably this is the only thing important from this talk, the monsters we are finding, because we are kind of learning in their way. The adventurers yet to come and my goal here is to convince you that this is important and interesting and we'd like to have your feedback. Disclaimer. LEAP is a highly opinionated project. With a highly opinionated team that builds highly opinionated tools and this talk is given by a highly opinionated person. So don't take me too seriously. When I say something is bullshit, just take it as a shortcut for, this is what I think, but I like to, yeah, you know. So now you know the team. I'd like to mention that we are not just coders. We tend to forget about the other people in the teams that make that possible. So kudos to the other people that are not cis admin or coders. We have one woman that the only thing she does is trying to get money through funding research for allowing us to keep coding. And that's much appreciated. So the question. I already said that. I guess if you are here is because you are interested in privacy. And so probably it's obvious in this context that privacy is not for privacy-manded persons. We cannot think that privacy is something fundamental. Privacy and communications are a fundamental human right. And it's about the right to whisper. Privacy, as the cypherpunks said, is the right to choose who I communicate with. And we think that we need to be able to choose who we communicate with when talking with our friends. By the way, this is a very interesting link. In case you don't know it, just click on it and read something tonight. This is the typical thing. We need to do privacy-oriented tools for journalists because they have to keep secrets, what sources and so on. Our saints, the whistleblowers, kind of appreciated in the community. And we, everybody, understand that they need privacy and secrecy. You probably work in a startup environment. If you are in China doing some wonderful research for selling a big thing, probably you want secrecy, communicating with your CEO to avoid all the Chinese industrially spinach. Or maybe you are thinking about changing jobs and you want to communicate with another CEO and being able to blast your salary away. How many people here know this guy? This guy was the one that hacking team. Okay? Here you have the whole tutorial about how he did this thing. Let's say I'm interested in interviewing Phineas Fisher. He's probably the most wanted hacker right now that is not in jail. So probably the only way to communicate with him is going to be GPG. How many persons here actively use open PGP encrypted email? Good. Now I understand a bit more where we are. Probably I need secrecy to communicate with my lawyer, with my package maintainers. Thank you guys. But yeah, seriously. When I'm traveling in India, I really, really, really would like to or need to my mom being able to understand what PGP signing a mail means because if not, whenever I'm going to be kidnapped because I'm a little white guy with a credit card in my pocket, it's going to scam her for money. So in general, the whole society, the point is that the whole society would need to, if not understand, at least being able to use the magical trickeries that cryptography gives us. And we have fucking failed to do that for the last 30 years. But you get the point by now. We need, our friendship is the whole society. If, without privacy, the whole society cannot work. You probably, yeah, I think you probably remember the crypto wars some years ago. Now we have a very much interesting movie. For those who don't go to the countryside, this is a silo. A silo is something where you put the grain and from there you get the cookies in the supermarket. So we are now in the silo wars. And this is a very interesting moment to be. This is from a Tim Berners-Lee article some years ago. You can see that the cool things were wearing so cool at the end. Some of them were, some of them died. Haha. Smart guys. In Dante Alighieri Divine Comedy, there is a very big explanation about the layers of hell. It's an interesting thing with a historical value. We now have a special place in hell, in the technological hell we all live in, for the people that use GPG. And I'm not trying to be smart or metaphorical here. This is fucking real. In my surveillance device, I need to have at least four, five different apps to communicate with different kind of friends. I don't know if this is the right order, but you get the idea. Some people think that signal is totally secure. Thanks Moxie, we can discuss about federation. Some people think that WhatsApp is secure, because it has end-to-end encryption. Some people, I don't know why, think Telegram is a cool thing to have. It's kind of open source-ish thing. But you know what? This is complete bullshit. This is my run minute. It's unacceptable that if I want to get Raspberry Pi from some nice guys in there, I have to get a Twitter account. No, no, Twitter is not a tool for communication. Twitter is not a fucking protocol. It's a fucking company. You get the point. This guy, Michael Hayden, former CIA director. The most important fact in the last years probably has been for my bias view, this one, metadata kills people. And it is not a bunch of nerdies that says that this is the important thing. You were called paranoid five years ago. Now it's not that we think they do it. It's that they fucking say it. So we have a nice pun on the concept of the killer app. They are actually, metadata is actually killing people. But in some sense, we all want to have killer applications, killer libraries, killer operative systems, whatever. We are all here selling things or recruiting people. And the key, this is from my Snyder book. The key to being in this place is that the things we do in the clouds, the internet or whatever are convenient and free. Free as in beer, mostly. We believe kind of in free as in freedom, but whatever. All the whole open sources thing. And this is a race, my friends. If we want users to use things, we have to do convenient things and kind of free things. So it's like fighting the enemy with their own weapons. And this is the holy grail for encryption and privacy and all that. We all are kind of looking for the thing that does the right thing in the right manner without the user needing to do a fucking PhD to use your tool. And your tool might be many things. Your tool might be infrastructure, forces admin. How many people here maintains mail servers? So you know the pain, my friends. Things need to be usable also for developers. I'm really amazed by learning so many things about how to make properly usable interfaces for libraries. And at the same time, in the bottom layer of hell, we have the end users because we are highly opinionated and we tell them what they should think like. So this is what LEAP project and its many branches and heads try to do to attack the hard problems and the interesting problems at many levels making things so simple that you cannot screw it. I'm not going to talk about the sysadmin part because that is mostly written in Ruby. No, just because. This is called the LEAP platform and it's for sysadmins to install systems with properly configured defaults and so on. For mail, we also do DPM but I'm going to focus on mail here. We're kind of presenting some libraries. I'll get there in the second part of the talk and we have some desktop applications for users. Intermission. Usually people will get out of the talk at this point saying, ah, but the user doesn't care. The user doesn't care because we don't make them think that it is possible. We are kind of shaping their view of the world and what is possible for them and not. We also think that the user is not going to pay but probably the problem is not in the user. Probably the problem is ourselves. I think it was Tankle that wrote a very nice postmortem on the whiteout thing with secure email and they basically were putting numbers on how hard it is to monetize the market for privacy but it exists. People is willing to pay. After Snowden, governments, universities, like whole sets of huge amounts of people were willing to put money on secure email. We can discuss what security means because they probably want to keep their private keys for their citizens or whatever but the need was there and the tools were ready. And there is another thing. Come on guys, like commodityization goes on many layers. We can put the value on the services and let people earn money through billing for a fucking mail service and it can be as less as 50 cents a month. If you get 50 cents a month or one euro for two months for 100,000 people you get some nice cash for some developers to code in a valley beach. So probably the model we want to go is to cooperate in a way that we are not taking only our fishes but building the tools for everyone to fish and be happy. So in the end we want crypto but we want roses too. This is my fundamental truth. I've been working with email for four years and I fucking don't know what email is or why people don't use it. This kind of puts things in perspective. We think that Twitter or Facebook are the big silos but they are just a tiny spot there on the whole volume of email communication and that is only a small subset of spoken language. So come on, it's not going to die anytime soon. I'm going to skip this. If you are the kind of person that don't take this as a fundamental truth, you have statistics and surveys and you can see the data. So the weapons. We kind of brought some weapons from our previews. People have been like 20 years in this business and for the client parts and the synchronization parts we kind of choose Python because it was kind of obvious. We were very happy four years ago. We were told that all the hard work is done. The crypto is done, you need some glucose, the shoulder giants. It is really true. We have the crypto there and crypto is very effective. It works and we know that it works because in the leaks about NSA we know that there are two things that they really get mad at. Strong crypto and tour. So it works. It works for a bunch of nerds but we cannot explain the whole things that are needed to properly use or to properly be in a kissing party to the persons. This is what Snowden made to make Greenwall able to have a fucking GPG key. It's an ugly 10 minutes video showing how to use GPG in Windows. It doesn't work. When you have a nerd doing usability studies and doing things for the public, it doesn't work. And at the end, this is how we verify things because we are fucking lazy. So what if I told you that we don't really need the users to understand the RSA concept that is awesome but we don't need it. We probably can have just some layers that do the magic underneath. A very good study 16 years ago showed that the mental models that we have to study usability in crypto are not valid. So we probably kind of have the criminals we deserve. So our plan four years ago in the happy moment of the relationship with the whole project was this. Very simple, three points, glue code, everything nice. Oh boy, how long we were. So the thing here is getting GPG key management easy and in a background manner and put it on the cloud because users have multiple devices and they want their GPG keys to be there. Put it on the cloud but at the same time they want to put them on the cloud in a manner that the FBI cannot get them when they get a server. And this was like the later part. Okay, we just use the normal main clients. Simple, right? So we went on a quest and four years later we have ten Python packages that have some shit. This is a very good book. It has two dozen programmers, three years, four hundred bucks. We now have kind of eight thousand bucks in the fucking issue tracker. And we thought our project was simpler. So we do the key management. I'm not going to talk too much about it here. The logic there is probably 20 lines. Just fetching keys from key servers. They are kind of broke so we need to figure out a new model for sharing keys, trolling the web of tasks and all that. Key manager, discover the key and that's the right thing. Trying to establish trust relationships between old keys and new keys and trying to get scores for how good a key is depending on its source. And we want to kind of share the common parts of it out of leap. So the nice part is what do you use for local storage to have your secrets always stored locally in the client and in the server? So it was there. It was done. The only thing you have to do is to hack some setup.py script to do bindings for SQL cipher. SQL cipher does transparent as 256 encryption on top of SQLite. Fine. This package is there. It works. We have to merge the py3.4 because we are fucking lazy but it is there. It is usable for many other projects. So the big, the important part of the talk. It's called something called Soledad. Which is basically the idea of when we manage the keys we put them on a magical library that does the synchronization of data that has been locally encrypted in a way that the server can never tamper with it or infer anything useful about it. The design documents are there and the code is there. Security goals. Encryption in the client side. Encrypt the local storage and has to be resistant to online and offline attacks and to data tampering on the server because we have to assume the server is malicious. Same goals. Consistency, same flag. We don't want to see all the data. Has to be multi-platform. We fail and even think about mobile. We are on the desktop part. And these things are in the far future for now. Well, not so much for this. And for usability we need something that is available so the user can always get this data. User needs to recover the secrets if they forget the password. And we want to have something general because we also want to express this to things like having a pocket application or to do application or whatever. So probably something of this sound similar to what the Ubuntu one guys were doing. So we said, hey, so super nice. They had a library that was basically an abstraction layer to put JSON documents on a storage and sync it. And so we started using it and doing hacks on top of it. Now we kind of have fork. Although if the project gets to the life again, we probably can use the old thing again. So we put Couch on the server and we put SQL Cipher on the client. We have another syncdb for metadata and a pool to do things with KeyManager and UPG. The password never arrives the server because we do something very smart. It's a cello knowledge thing called SRP. We derive keys to get stronger keys from smallest inputs. And we basically do encrypted blobs and put them on the store. And it syncs. So these are the secrets. The blobs have, it's just a JSON document with a Cipher text of the original thing. You put it there, you create things, you sync things. Only that. The thing for mail is that we have like the whole mechanism for mail to arrive from the traditional SNTP world, put it on your inbox, decrypt it, do the pieces, and put them on the storage. So you can process your mail on one device and have your already synced inbox in many other devices as long as your GPG is. And you have a very simple rest API to sync. Alize. We kind of trust on Thunderbird. We wrote a Thunderbird plug-in. We have a desktop client that exposes SNTP proxies locally. Thanks to all these, this server was kind of easy and nice to do. Thanks to all these people. And we kind of started collaborating with ThoughtWorks because they said, oh, this is very nice. Encrypted replication of data. So we can put them on a server. This is our client. And this will be the mail user agent. This is the server part with the CouchDB blogs. And what the Pixelated project is doing is putting all this in a server and serving a Python user agent that does the web mail. So we kind of put our clients in their server, but we also close the loop and we take the web mail and put it in our local client. So you can do the two things. The corporate mode in which the private keys are in the server, you can use it, shipping it inside a desktop-only application. And look like this, and people are really excited about this kind of Gmail-ish things that do all the right magic in the background. Monsters. My biggest regret is not having dealt with complexity before. And that probably comes from our relatively inexperience with big projects and Python and packaging and so on. We start having too many packages. It's fucking unacceptable. Newcomers find it very difficult to understand where each thing is. When you start overloading inheritance, things get crazy very quickly. We also have some kind of complaints about the whole twisted, deferred thing for newcomers, which is kind of a religious war. But right now it is very nicely isolated so people can just use the REST API and forget about the things that are happening in the background. Another thing that has delayed us a lot is trying to get in the client server thing, your local demo, mixing together the QT paradigm with its event loop, the twisted IMAP server, and some other things. Simplify. We are at that point now trying to simplify it. The thing works. The thing has tests. People is contributed. We have a big company like ThoughtWorks contributing code, but we need to lower the barrier to do a significant contribution to the project in general. And some adventures are ahead. Part of the team now is working in a couple of European Union research grants that have to do with key server validation, key exchange, and trying to bridge, trying to tend some bridges across different privacy projects. We want to share some of the knowledge and even code. And Panoramics is another cool project about doing mixed master networks for privacy. We are one of the first clients to implement a new draft, a new standard proposal, which is called Memory Hole, that tries to attack the design error in mail, in Centipede, that all the headers are going in clear text. Last week we were on the OpenPGP Summit, and it seems that Thunderbird has already implemented this. So the whole idea is that you put all the headers, you put them inside the encrypted and signed mail, and you replace the headers with dummy steps. So you have a very nice and simple way of protecting the mail while in transit. There are also some nice proposals to do forward secrecy in OpenPGP, doing something quite similar to what the signal protocol is using, this ratcheting mechanism, to avoid that if an attacker can get some of your keys, it cannot recover the whole... Because it is a story, it is there. So trying to break the reconstruction of the whole communications. This is probably going to be something really, really exciting in the next year. And in Soledad, we are in a point where we are not finding any important bugs now, but we need to do some things for scaling. One of the main things we are going to do in the next month is trying to break the atomicity of the syncs, because right now everything is the same pool, and that's kind of shitty. We want to be able to sync all the keys first in a new device and then probably all the headers and then probably the attachments on demand. And we have to deal with event plan consistency in a nice manner. There's a lot of things that need to be done. That's it. This thing is my fingerprint. This thing is my fingerprint. And for the young people, this is not a Twitter handle. This is something called IRC. We are there and I'd be very, very happy to talk to you guys and learn all the possible things you can communicate with me. So thanks for an absolutely fascinating talk. We have managed to leave a full 10 minutes for questions. In fact, almost 11, which I think is a great idea. I have a million questions, but you don't want to hear my voice, so I hope you have the same questions in your heads that I have in mind. Who would like to have the first one? Thank you very much for the talk. Do you have any idea how to deal with a big amount of encrypted email? How to search in it? What to do with a start-away encrypted email when the keys elapse? What to do in the long run? What we are doing now is that we, it's different in this case. In the original BitMask client, what we do is that we don't store the encrypted blogs anymore. We use the very nice and old code in the standard library for, it has like 10 years ago, 10 years code that pieces, cast the pieces of the MIME3 and we store all the metadata in different documents in the document store and we delete the original encrypted blog. So we can do efficient search mainly by headers. We can build indexes for searching for the main things in headers. Pixelated project is using a different approach. They are using bush, I think it's pronounced like this, and they do full-text search on the whole body of the mail. And they store, what they do is that they build the index for doing full-text search locally and they encrypt the index and they store the key for this blog inside Soledad. So you have locally quite nice and efficient index to do any kind of, we probably could do the same with NodeMatch, just trying to block and grip the things with NodeMatch and just store the keys for the encryption inside the metadata database. I came across an encrypted email client called MailPile, which sounds kind of simpler but less ambitious. Can you compare the two? Because I felt you were trying to get done in time, which was great. But when you started saying, here, let's have a client in the server and a server in the client, I was lost. I need probably better diagrams for that. We are really similar to MailPile. Actually, the Pixelated project started to consider using MailPile for the frontend. I personally found MailPile kind of monolithic and we tried to decouple the things to play nice with the whole provider infrastructure. So MailPile is probably doing this whole thing in the client. They do their web server thingy, they do all the handling for GPG and they do the storage and it's basically the same thing. It's a webmail with encrypted local storage. They don't attack this as far as I remember. They don't attack the replicability problem. So we kind of started from the upper layer and this is a very hardcore strain. I got MailPile running with my agent. So at the end I don't care. We kind of focus on this layer and the user agent should be pluggable. MailPile is really, really nice and for the amount of funding they got, they are really far in terms of features. So I really would like to plug it into the whole Soledad encrypted storage. The main difference is replication. That's great. Any more questions? Yes? Hi, so one of the things I've been struggling with is can we really escape it? I mean, even if we use something encrypted, people will communicate with us Gmail. Even if we use encryption, if it's on the phone, I mean, that's either Android. I mean, it's either Google or Apple. So can we really escape it? Or is the only way to communicate securely is just low tech, just meeting people? I don't think I have an answer for that. It is totally true. Our code now... I kind of screwed it. We had code in GitHub and we are moving to another GitLab instance in which a requirement is that you have an email that is not from one of the big mail providers, because as you say, it doesn't make any sense if you are hosting a mailing list server with some pretensions of privacy and one only person in the mailing list has a Gmail account. End of the game. Have you read Moxie Marlin Spike's recent rant about the end of Federation? It's a very interesting discussion going on in the community because he thinks that having central control allows you to reach a lot of people. Like deploying something. My personal impression is that that is not the main goal. Like Federation doesn't really need to mean that you are sharing... Isn't it the open source problem or the creative problem in an abstract way? We are open, but the big corporations are less open. So they are open to our things, our code, our conversations or whatever. They can do data crunching, they can do data mining on it, they can make money out of it, and they return zero. I really started being scared about the Federation thing when Google closed down the XMPP endpoints because that means they are fucking going to kill all the interoperability. For me, mail is important because it is like the last place or common language. Until now, mail is the only universal identity anchor. If we lose that, we are screwed. More and more, with Facebook, it's going to move towards GSM identity pieces. So I don't know, hard question. I want to believe. You said GSM identity pieces. What was that? What I'm meaning is that right now, for all the social networking silos, mail is the identity provider. It's your reset for everything. But more and more, if you look at the peripheries of the capitalist system, they are starting. New people, younger people, doesn't have an email. They only open an email for opening their Facebook account and they forget the password for the email. And more and more, I'm seeing this trend about the GSM and GSM, the chip, being your identity anchor. They can build about it. So are you saying that email is the only right way and there's no future for protocols like Signal or something like that? No, I'm not saying that. Mail sucks. Mail actually is for spam and we are going to have a big problem about spam if we encrypt all the metadata and for work and for university and whatever. But this is the pragmatic approach. I'm really excited about things like POM that have POM. It's a project I think by Adam Landly, which maybe I'm mistaken, but it's like an experiment towards a new messaging protocol with security considerations from the beginning. Signal is something that 10 nerds are using. My point with this being strategically important is that mail is going to be there for a while and we cannot wait. There are situations in the world, I don't know, you are running an abortion network in Malaysia. You cannot wait 10 years until the hikers can with the right tool. So consider all this crap I've been talking about some transitional strategy until we kind of have some decent protocol in place. It has to be open and federated. And the thing you were talking about was POM? P-O-M-D. Thanks. All questions. What's the time? We've got time for about one more. Yes. Hello, hi. Oh, hello, hi. I think one of the things you mentioned in your talk was really important and it's around the question of why normal people either don't do it or can't do it and it's around usability. And I think in the open source world we have lots and lots of people who are technically very good. We are enthusiastic about pushing the boundaries in terms of protocols and the cryptographic correctness and all the rest of it. And whether it's cryptography and email or a Libre Office, I think there's always a stumbling block which is the usability for normal people. And it's a shame. I mean, I'm older than most people here. I've seen over the years great ideas which are intrinsically excellent fail because Granny Smith didn't understand the word or the icon looked wrong. Something that was relatively easy to fix. So my question is to what extent are you doing the user research, the user testing with normal people to say actually we don't need to put the effort into key replication or whatever it is because the thing that's stopping people is something else completely as observed by a more disciplined understanding of how users interact with what you're building. Let me search for one little thing. I didn't have time to get into it. This is absolutely important and usually it is not hard-coded into the processes of the groups because we have the, I'd say, the engineering bias. We think we know, we think we are gods, we think the users are fucking stupid and that's a very wrong... I'm generalising, just trying to be funny but that's a very wrong approach and we don't realise about it. I've been talking kind of about mail but the first part of the project we were trying to solve another different problem which was secure VPM. The idea was having a Trojan horse because users are not going to install a desktop client for email but they probably won't a desktop client if it is the only way to get VPM. So now we have our regrets, I have to say but we spend some time trying to solve the other problem about VPM, cross-platform and so on and if you don't know this blog, just subscribe it. Subscribe to it. This is Gas Andrews and she gave some workshops about disability studies in a very scientific way and came up with a long list of very interesting things that need to be changed because our mental model, basically for how the user understands and reacts to the application was not optimised and we fucking need more of these things earlier, during, afterwards and I cannot mention that one of the challenges right now is to close the feedback loop with these kind of things in a faster way. Okay that's it, thank you very much. Huge hand for this wonderful security.