 I also brought some stickers. I just leave them here, then you can pick them up later. I'm telling you about PEP project called Pretty Easy Privacy. And we want to do privacy by default. So my name is Sva and I'll be also having an intro later about my person. As you might have guessed, this name Pretty Easy Privacy comes from Pretty Good Privacy. Who knows about Pretty Good Privacy? Okay, who's using it? Okay, who's using it daily? Alright, great. So at least two. So I think as more than half of you knew about PGP, we can skip that one. So this is going to be my talk. I make an intro where I also introduce myself. Then I introduce the general concept, which was a rather long chapter. Then very short, I'll be explaining the organizational structure of Pretty Easy Privacy, then going into... Pardon? I need to restart it. Okay. Then going into technology. And then showing you the current implementations and maybe some quick demos of apps depending on how much time we have left. So Edward Snowden said once, I don't want to live in a world where everything that I say, everything I do, everything, everyone I talk to, every expression of creativity or love or friendship is recorded. So unfortunately, we do live in such a world now. So it's not only about US and UK and Prism and that it's also, for example, in Asia, I know about the Indian Central Monitoring System where they started in 2013 to just monitor everything without giving any information what is actually happening with it and who has success on it. And I'm pretty sure that Singapore can also tell quite a story about this. It seemed to be even harder. So problem, most communication online is visible like a postcard and this world has mass surveillance. So what we need is mass encryption. And so... But that's also just the starting point because most probably all of you know mass encryption is not everything. We also need to anonymize all the metadata. So we're here just at a starting point. We see ourselves as cipherpunks and we want to optimize the costs of mass surveillance. So we're trying to roll out mass encryption to not only have privacy for citizens but security for everyone, also for companies, espionage, all that stuff. It shall be easy to make it just usable for everyone without even noticing it at all, ideally. So briefly to my person, I'm coming from the humanities. I also had computer science and side course but I'm generally from the humanities. I'm a co-founder of this like CryptoParty.in, Helax.in, Hackbeach.in. So that's like the Asian stuff. My name Sva is a unique addressing in the internet. I'm at least trying to have it like that. If you want to have my legal name just check the board members of Kiosk Computer Club or Hackers Without Borders to find out what's my legal name. So now the first chapter, the concept. So that's six points where I'm going through privacy by default, pretty easy privacy, peer-to-peer and end-to-end free software, compatibility and anonymity. So directly starting, privacy by default. So that does what the user would want to do. So we're coming from this, yeah, CryptoParty background explaining, teaching GPG to so many people and then we just were at this point where we said, why don't we just instead of writing all those how-tos and explaining this thing so often just write this into protocols, software and standards. Just whatever the user should be doing then will be done by software. So and this is what we've done. So we created pretty easy privacy which makes privacy easy. By default it's easy to install, easy to understand, easy to use. There's no hassle, there's no training needed. People who are using PEP in the current implementation just write emails. Nothing else but they'll be encrypted. Also we want to make it easy for app developers. I'll explain this in the chapter of Tech a bit more. So one sub part of the easy concept is we created this concept of trust words. So instead of hexadecimal-based fingerprints that I have to read out loud on the phone, we just transfer them into words like battery horse staple instead of EC5539C8FECF. We all know this reading out fingerprints on the phone is pretty annoying. So reading out 10 words instead is much nicer. And this by the way is the only part that still needs to be done by the user and it doesn't have to be done. I mean we all used OTR without checking the fingerprints, right? So this but this establishing trust that's no software can establish trust. That's only something humans can do by looking into eyes or listening to voices. So another part where we're trying to make it easy is we are trying to solve the problem of the syncing of keys over various devices. So this is still in testing. It's not live yet. We realized this with the help of device group. I'll explain it rather with those pictures. So a new device generates a device key and pinks with this one in the device group. So and then the existing devices and the users verify that new device with the fingerprints again and then they make the handshake and they agree on a secret key for the group and then all devices exchange their keys. And that can also be used then for syncing contacts and calendar and then also finally the problem of backups has been solved without the cloud because then you have like your own cloud because you all know there is no cloud. There's just other people's computers. So instead of using other people's computers you just use your own for like backuping your stuff. This is how it looks like in testing. So we already on it phone outlook. So another part of the concept is peer to peer transport and to end encryption. So we're trying to do things right. If it's about crypto, it has to fulfill these things. And we also don't want to have any new like yet another crypto messaging service where you have a centralized infrastructure and or a closed service where you can only chat to your friends whom you actually convinced to also install this particular piece of software. So what perhaps trying to do and I come to this later is to just use all the existing stuff. We want to be compatible with everything which is there and ideally not even creating any own apps but just being plugged in to the existing stuff to have like to have it easy for the user. So another part of the concept is that it's free software. Again, if you want to do crypto, it's like has to be free software. Otherwise, it's not trustworthy at all. So yeah, you find the code under these URLs. You can already see where we're coming from. The CSR and let's encrypt. It's GPL and we for sure do regular independent external code audits. So we also just started. So there has been one code outed on the engine so far, but it'll be code outed every time when there is a new release before the release. So and like then it'll fixed and then it will be code outed again and then it'll be released. So that's at least the process we thought we'll have. Yeah, another part of the concept compatibility what I just mentioned. So we want to be compatible with all the crypto technologies. All the message transports. We have multiple platforms and we want to provide multiple languages. So that's what is already implemented. The bolded one open PGP, no PGP as mine. And UTR or Memo signal protocol axolotl whatever is going to come out there. We also hope that our engine will be speaking it soon as well as the following transport protocols. So at the moment it's only email. I mean, we just needed something to start. So email is still the most widely used transport protocol out there. Then we want to support XMPP and also non open standards. So for example, Twitter, private messages, you can also just put GPG on them as well as with SMS. Maybe someone remembers that signal actually started in 2012 or something with the app called SMS secure. It was not doing anything. Then OTR on SMS. So every SMS to just cost you double. So it's pretty easy to actually encrypt SMS as well. And we should do that because we need mass encryption. So another part of the concept is anonymity. So content encryption is not everything. I guess we all know this. For example, email metadata stays visible. There is the subject. There's the from to the IP addresses. I've been sitting when I was connecting to my SMPTP or IMAP server, the size of the message, that's all visible. And what we're trying to do or what we already do is to encrypt the subject in line. So Thunderbird can already handle this. So you have an inline. You just put the subject in the body and the client just puts it back into the subject thingy of your client. So that's basically it pretty easy. And then we also try to obfuscate and encrypt as much as possible from the header. Yeah, so, but that's also not everything. So there's also this idea to pipe it by a GNUnet. So what's GNUnet? To explain this, I go through this rough timeline. So in the 1780s when it started with this internet, we were like, wow, I can access your computer and you can access my computer. This is great, right? So then nowadays we are saying, yeah, sure, I can access computers and use their services. But wait, what? They can also access mine. So this is not actually 21st century internet anymore. So what those guys are doing and they started this in 2002 in academia already. So it's a really long, long research process ongoing, end-to-end encryption and anonymization of all the way data flows. So they have this tagline, you broke the internet, let's make a GNU1. So I guess everyone agrees that this would be something really nice to have a GNU internet. GNUnet is a mesh routing layer for end-to-end encrypted networking and a framework for distributed applications designed to replace the old insecure internet protocol stack. So what those guys do is they actually replace TCP IP and write a new protocol and they put a whole stack on top of it. So that at the end, the applications can be still the same, but they're just using different transport protocols. So we're waiting very eagerly, but I think it's going to take some more years. But please keep an eye on them. I expect them to release a new version, let's say within this year. And then you should definitely install it, check it out and be a note in the GNUnet and see where this internet 2.0 is going to lead us. So concept summary, users don't have to think about the crypto anymore. They can just use it by default. So there's this quote which a journalist wrote once. It is this little hacker inside that decides on the cryptography choosing to communicate with a message recipient. So this is what we do every day. Like you open a query with someone in IRC and then you're like, oh, you cannot do OTR in IRC, so let's move over to Jabber. And then you open up Jabber and then you're like, oh, and then can you do O-Memo in Jabber? Or you say, oh, let's move over to Signal because I'm already just leaving the house or whatever. So you do these decisions every day consciously, but we cannot expect this from the people out there. So this is why we want to create software who's actually deciding all these things which we are just deciding because we are techies for us ourselves privately each day. So a quick overview on the organization. We are a company and a foundation. So we're trying to be sustainable and not the usual, we code on the weekends and at nights project, even though we have done this for many years now. But we have a company that sells applications, applications and services, and we have a foundation which supports free software and the code belongs to the foundation, which is, and I'm coming later to do this, the code of the engine and the adapter. So applications, as said, the company is selling applications. So every one of you who's having an application, let's say an SMS application, you can still sell this application, but you can still put PEP inside. So sure, the application is not owned by the foundation and the applications also necessarily don't have to be free. But the engine and the adapters are free. So what's engine and adapters? This is the technology architecture I'm explaining to you and showing you the list of adapters and development platforms we're already on. So the basic architecture, I already mentioned it multiple times. We have this engine, which is doing the crypto functions and the key management and knows about the transport protocols and everything. And then the engine can be plugged into applications via those adapters. So here you see the Outlook examples. So we have this Outlook plugin, which PEPs Outlook. So if you're using Outlook, writing an email, you just write and try it without even having any hassle about it. So that Outlook plugin is using the com server adapter to plug in this engine. So here's another few. So for example, Thunderbird in the middle. Thunderbird has Enigmail as a plugin to actually add encryption to Thunderbird. So this Enigmail works on different desktop environments. So there's then always this JSON adapter needed to actually put the engine, which is on the bottom, into Enigmail. So this is the list of adapters and dribbles. You see there's Java, JSON, Python, QT, iOS, everything's there. So please go ahead and plug PEP into your applications. It also not necessarily needs to be a communication application. Now recently, last year in India, we had this problem with the cache system. People were thinking about a bot where people could upload their tax papers and then they also said, oh, and then we need encryption on that. Could we use PEP for this? And I said, yeah, theoretically, sure. Why not? It's just GPGing the files. That's already nice because, yeah, uploading tax papers as an application. Oh, I'm very much in time. So the developing platforms, iOS, Android, Linux, BSD, macOS, Windows, and this is the engine. And regarding the time, I'm sorry, the other one was also going five minutes more. So I will be finished at 30 points promised. That's the engine. I already explained. It'll have all the crypto tech, the message transports, and then, yeah, to giving all these functionalities. So now the current implementations. Again, we are at the very beginning. So at the moment it only does GPG on email. So we only have this crypto technology and that transport protocol, but that's not all. So if you plug in PEP into your application, you can just lean back and we are caring for the rest. So what it does at the moment, it automatically encrypts. Encrypts the subject in line. No key management is needed. No key server as a centralized services. Fingerprints are trustworthy. Fast words. You have an opt-in passphrase for keys so that the normal user who doesn't care don't even have to type in any passphrase. And you have the encrypted, obfuscated, and this PEP sync thing. So there is Android K9 fork, which is ready to use, available on Play Store and AfterAid. Then there is an Outlook add-on, available on PrettyEasyPrivacy.com free as in freedom, not as in free beer. Please ping us if you want to have a test license, just mention FOSAsia in the contact. We also now have an Hindi version, so some people in the group got very excited about having this in Asia. So if you want to have other languages, please go ahead. Then there is Thunderbird and Enigmail. It's coming with the next release of Enigmail and the Advanced Expert mode then still stays available. Next roadmap, next going to be browser plugins and stuff, even though as very deep techies, it's not easy for us to see browser plugins, but we also see the reality out there. So this is the demos, as I said, only if I have time, so I just briefly go through it. You can just get an idea, like you install, then you make the handshake, make the trust and then you're encrypted. And it's the same with Outlook. So you install it and then you go from this insecure to the secure mode where you just now you're just emailing encrypted and now you do the handshake if you want to and then you get into the green mode. So and this is solved by just attaching the key automatically. So if you want to talk to a person who's not having PEP installed but normal GPG, just tell them, please attach your key just normal as an ASC file and then PEP will automatically get it inside. So yeah, that's the different screenshots from the demos and that's it. So now I'm even in time to take some questions. Yeah. If, for example, my private keys got leaked, for example, like I was in the US border and my phone was like scanned by the security, how does normal people handle that kind of stuff when their private keys are stolen or leaked? If you want to revoke the key. Yeah, and how do I tell my friends that I have a new key? Hi, as the key will be attached to every email. So this is also what we like to see as a standard in the future to get rid of the key servers. So Thunderbird already has this since quite a while or Enigmail that you have this attach my public key button. So as the key will like theoretically be attached to any email, the client just sees, oh, this email address has now another key like and just imports it and throws away the old one. So ideally this also just works automatically, which only happens if then other clients also get to know about this. Okay, the key will always be attached. So otherwise, I mean, you can use the full band of also putting the new key on the key server and all that. But the like non sophisticated user will just create a new key and then it will be attached to the emails all the time and then the clients can just see, okay, there's a new key attached. So apparently something happened with the old one. Any other question? Why do you say you're moving away from key servers? Centralized infrastructure. First of all, which is not a good thing per se. Second, the whole web of trust, which is showing your social graph, which is also a big, big problem. People are revealing a lot about their like social graphs out there. And then also there's a lot of other failures. For example, you can by accident then bring together multiple entities of yours because you're pushing like the same key with various email addresses and stuff like that. But I mean, the question is more to do is if they're only pushing out public keys into these servers, is there still a concern? Yeah, because of the of the social graph and the like the fact that it stays there forever. So if, for example, I lose my key for whatever reason and I forgot to make a revocation certificate, then my key stays there forever and I cannot even use it. So then people write you emails and then you're always like, Oh, no, sorry, don't use this key. Please use that key. So and that's always very annoying and that happens very often. So generally it's one of the main rules to avoid any kind of centralized service when it's about like proper crypto. So, yeah. All right, then I'm perfectly in time. I think.