Let's roll out mass encryption!
sva
Let's "optimize" the cost of mass surveillance by rolling out encryption for the masses! We're already heading forward on that crossroad of privacy! We're developing pretty Easy privacy (pEp or p≡p) to make encryption easily available for everyone. We've given up on the idea start protecting themselves, so we're writing protocols (and software) compatible with existing crypto and transport protocols. p≡p does what the user would want to do. This approach of taking away crypto needs from users’ view can be plugged into existing communication sofware. p≡p motivates a new standard to securely encrypt and verify written communications without reinventing the wheel: p≡p eases secure communications relying on well-established end-to-end cryptographic methods by design. Following standards like OpenPGPG or OTR it integrates into existing systems for written digital communications and automating key management tasks. p≡p's protocols automate the steps taught to users at cryptoparties, to protect their personal security and privacy by default. For easy integration of p≡p into application programming we provide very simple APIs because ultimately p≡p wants to change the default: from unencrypted, unverified and unanonymized to encrypted, verified and anonymized. We support multiple platforms, multiple languages, multiple crypto technologies and multiple message transports. We will offer a Peer-to-Peer, End-to-End and device based secure synchronization of keys and configuration that is regularly audited Open Source and Free Software.
 Hi, thanks that you're all here. I'll be talking about pretty easy privacy, which comes from pretty good privacy, which you might have guessed. Who knows pretty good privacy? Okay, that's most of it. Who's using it? Okay, a bit less. Who's using it daily? Okay, that's not only what was it three or so. And yeah, that's exactly the problem which we're trying to solve, that pretty good privacy is good but not easy. And we're trying to make it easy so that on the one hand side, techies can use it more at ease, but especially that normal people who are not into tech can just use it. So we're actually not providing a solution for techies. We are glad if techies are still using their, I just recently had someone who was using e-mechs for email and having this with GPG as well. And this is pretty important that we still have those, let's say, pretty good sophisticated solutions. But this is a very low sophisticated solution which is really there for the masses. And yeah, I'll be going into more detail on that. But one more question, who had tried to teach GPG to someone? And who was successful? Yeah. Okay, so thanks for everyone who did that. I also have done lots of crypto parties during, especially after Snowden happened. I was in India and it was like hundreds. I taught GPG and I mean, I don't have contact to all those people visiting a crypto party, but I guess if there is like a handful still using it, I would be very glad about it. So let's see if this scene is going to change in the next couple of years. If we look in the past, there has lots of change happened, but now, yeah, let's start. So I can skip this one as most of you know what it's about. I make an intro about the general problem. Then I introduced the technology for mass encryption, we trying to develop. Then I go more deeper into the general concept of pretty easy privacy. And then I have actually a big chapter on the technology for metadata protection. The so-called GNUnet who has heard about GNUnet before. Okay, just a few. So I hope I have enough time to go into more detail, but at least you get an idea of what it's going to, what it's about. And then yeah, the usual summary and Q and A, but maybe we make the Q and A a bit shorter. Let's see how far we come because we also have a stall in the project area when you enter the room on the left side. We are like the second table around the corner. All right, so I start with the Declaration of Human Rights, Article 12. No one shall be subjected to arbitrary interference with this privacy, family, home or correspondence, nor to attacks upon this honor and reputation. Everyone has the right to the protection of the law against such interference or attacks. So I highlight two points here, arbitrary interference and the right to protection. Just give this little quote. I don't know, I guess most of you have heard about it. This is just published a day before yesterday or three days before that the court has confirmed that the searches and seizures were illegal. So this was an arbitrary interference which was not protected by the law, but done by the law. So and there is another quote, I don't want to live in a world where everything that I say, everything I do, everyone I talk to, every expression or creativity or love or friendship is recorded, which is from Edward Snowden who has shown us that actually the word is like this. So everything I talk, like everyone I talk to online is recorded. So this is one of those thousands of thousands of slides he was publishing. So we have the service providers here and the list of stuff which you can get including special requests so you get literally everything. So yes, we scan. We should actually get an update on this if someone is a designer. But it's not only the governments who are trying to spy on us. There's also this problem where I really like this little picture of those two pigs saying that they don't have to pay for the barn and that even the food is for free, which means that if you're not paying for it, you're not the customer, you're the product being sold. So the general problem is that online communication is visible like a postcard and that this world has mass surveillance. And what we're trying to do as a solution is mass encryption and then mass anonymization. But how we're going to do this, we're trying to do software which does what the user would want to do. So instead of writing how to guides, we write user expectations into software and protocols to automatize all steps a user would need to carry out. Which is key management, key discovery, private key handling and lots of more things. So how we're doing this, we wrote an RFC or an so-called internet draft which is the pre RFC, which is online and ready for discussions together with the ISOC Switzerland. It's been written and this is the abstract. I just read out loud the underlying stuff. Building on already available security formats and mass transports, pretty easy privacy describes protocols to automatize operations, key management, key discovery, private key handling that have been seen to be the barriers to deployment of end to end secure interpersonal messaging. So this is what PEP does. So we're automatizing these things which usually the user should do but which you guys who taught others also most probably figured which is pretty difficult for the users. By the way, what I found out in the last couple of years is also that it turns out to be very difficult for users nowadays to actually use a mail client. So if you're not keen on teaching someone GPG but still think people should get to know more about these stuff, then tell them about email clients. Because this is turning out to be more and more of a problem because people only use web mail and they don't even know the concept of an email program. Call it app then they understand what it means. So this is what PEP does and what does the user do? The user should only do messages. So this is how it works if you have two PEP users but also one can be a normal GPG user but on the picture we have two PEP users so they install PEP. Then one person, this is Bob writing to Alice, writing the first email which is unencrypted like a postcard. But this email already has a key attached. So in that step the key gets generated. The user doesn't even get to know about it. The key gets attached, Alice writes back which is already encrypted. So now those two guys can talk encrypted to each other and if Alice is a normal GPG user all she needs to do is to attach her key as an attachment. If you send a PEP user, oh here's my key, this is the URL, then the PEP user is like okay what are you talking about? But just attach the key, PEP will see this is a key and reply encrypted. So this means you're in the encrypted mode. But we do trust on first use. You see the first key gets unencrypted to the other person. So ideally you also check the fingerprints where we have this concept of trust words where we translate the hexadecimal fingerprints into words. So you call each other, say the words, you make the handshake and now you're encrypted and verified. And the only thing as the user is that you see those colors. So here your email somehow turns yellow, depends on the application. There's some yellow spot and here you are in the green mode. So ideally everyone should be in the green mode. This is another diagram showing this. So first email unencrypted and key exchange, second email is already encrypted. Now you do the verification and then you're in the secure and trusted mode. All right, so what's PEP, a software for various platforms to easily use existing crypto tools. It's designed to encrypt all digital written communication with the starting point of email. I'll explain that later. It encrypts automatically with whatever most privacy enhancing crypto standard available, hence privacy by default. We're going with the opportunistic approach here. So if you have seen the signal and these guys, they started to have this opportunistic approach of having as much as crypto as possible, right? And if not, then not. And all end user software must be hassle free and zero touch. That's why we also don't have a password on the GPG key, for example. What's PEP not, that's also pretty important because we're not yet another crypto tool with a closed user base or something. We're using existing crypto standards. So we're compatible with everything that exists out there. I mean, not everything, but everything that's like widely used. We're not a centralized platform provider. We're not implementing any own crypto. We're not replacing any existing crypto tool. And we're not just an email encryption tool. This is just the beginning. Who are we? This is also very important in these projects. We see ourselves as cipher punks. We want to roll out mass encryption to optimize the costs of mass surveillance. We want to make the use of crypto pretty easy, not only for the users, but also the developer can plug it into their apps and the user can just use it by default. What cipher punks? This is quotes from the cipher punk manifesto. Cipher punks are actively engaged in making the network safer, advocate widespread use of strong cryptography as a route to social and political change. And they aim to achieve privacy and security through proactive use of cryptography. And he's also very nice quote, which I really like because of this whole privacy. Oh, I don't have anything to hide thing. Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know. But a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world. And then last quote, we cannot expect governments, corporations or other large faceless organizations to grant us privacy. We must defend our own privacy if we expect to have any at all. We know that someone has to write software to defend privacy and we're going to write it. So this is where we're coming from. We are actually most of us are a group of people who've done like all these crypto parties and these things. And I, for example, wrote in 2013 the whole crypto party.in the new web page, this whole how to and whatever. And we're just at a point where we were at a point and we still are where we were just like, okay, let's stop writing how tos. Let's write software who's doing what we're trying to tell the users. To just come back to this declaration of human rights, everyone has the right to protection of the law. And this is not the case. We know that. So what we need to do, if the government doesn't help us, if the law doesn't help us, we need to take the help of the law of mathematics, like just physics. That's what we need to do all together. And this just as a really short side note, Cypher is not about cyber. Cyber is also not about internet. It's the study of control and communications. And Cypher is an alternative spelling for Cypher. And also, who's me? I studied anthropology and computer science. So I'm actually a humanist. I'm also carpenter. I'm Schreiner. My name serves as a unique addressing in internet and web. That's why I'm using it widely. If you want to know my real name, just check the board members of these associations. And if you find a female name, it's most probably mine. And this is stuff I've done, which I always like to point out. So please come and visit us in India, for example. Yeah. Now we're actually getting into the things. So I'm telling you about the architecture of PEP, which consists of the engine, adapter, and applications. I show you a quick list of repos, developing platforms, and I also add the organizational forms into the technology chapter. I explain you why once it's about time. So the general architecture is, as I said, applications, adapter, and engine. So we have this engine who knows about the crypto functionalities. We have adapters in various languages, which are then communicating with the applications. I go into more detail on that. But here's some more examples. So for Outlook, you need a com server adapter. For Android, we have this JNI adapter. For iOS, there's an Objective C adapter, and so on. So this engine drives several crypto standards on different digital channels, like message transport protocols, which is at the moment only email, like SMTP, IMAP, Exchange, blah, blah, blah. It's written in C99. It has roughly 10,000 lines of code and has regular code audits. It's not meant to be used in the application code directly, but you can just plug and play the engine as a developer, which means you don't have to maintain any crypto. The plug and play is a bit too much because our documentation is very bad. So if you want to do that, then please contact us as well. If you wonder about the documentation, please. Yeah. So you don't have to maintain any crypto. You're like, okay, what? But we have regular code audits. They're published on this URL also in the blog. Then once they happen and they're done by Section 1 by Bev, maybe some people know him. He's also been part of this crew for quite a while. This engine takes care of the messaging functions, the crypto tech services. It's like a crypto API. Makes this fully automated key management services and the trust rating. It knows about the transport protocols, like the message transport ways. And in the future, there will be this metadata protection, YNN. So this means it does the decryption and encryption, the MIME encoding and decoding, the message processing for the adapter, the key management, which is generation at the beginning and then the verification blacklisting, all these things. And also key synchronization of same account between devices. This is still in testing, but about to come out soon. This will be more or less, I think, something which I hope lots of you are going to be happy about because it is still a problem. Like you get encrypted emails and you're like, oh, sorry, I'm on the road. Please contact me on another channel too if it's important. Otherwise, I'll come back to you tomorrow or something. So this is always very annoying. So this engine gets connected through the adapters to applications. These adapters are language or environment specific interfaces between the engine API and an implication development environment like a programming language or an IDE or something. Basically the adapter is bindings. So and this is a list of adapters we have actively laying around. Not all of them are in use so far. So you're very invited to check with your own communication apps if you want to use one of those adapters. And this is how it works. The app makes calls to the adapter for the function at once like encrypt or decrypt or get the trust words or trust level or something. Then the adapter converts that into a normalized standardized form for the engine, for the messages and makes the C library call. Engine magic happens and the adapter gives the result back to the application. So it's actually pretty easy. The current implementation of PEP is that it handles open 3GP and as MIMe passively without any hassle for the user. It automatically encrypts the subject in line. There's this automatic key management. There's no key server or other centralized infrastructure because the key always gets attached to every email. Those fingerprints get translated into trust words. There's an opt in passphrase for keys. So by default there's no passphrase because the users will stop using it if it starts hassling. And the header gets encrypted and obfuscated and this sync protocol is in the making to get the keys synced over various devices. I have more details on that. So this is the applications which we have at the moment. We have Android, Thunderbird with any mail and PEP for iOS is a very early alpha which I think at the moment is only like a pregroup in testing. But if you're interested, we can give you access as well. This is the list of repositories. You find them all online on various places because we are like a widespread organization. And this is a better overview here. You also find everything on PEP software and on PEP foundation slash PEP software. So here's engine and Raptor, Android, iOS, Outlook and any mail, everything on a different place. And this is development platforms. So basically everything you can think about. And now the organizational forms. So we have a company, a foundation and a cooperative that sign a genocent shaft. The company is selling applications and services and sits in Luxembourg. The foundation is supporting free software and very important, the code belongs to the foundation. So the foundation is actually the heart of this. So the idea is that the company can also get investors money and stuff like that. And then if the company breaks or something fails, the code stays with the foundation. So the code will always be safe. And if something with the company happens, we can still say, okay, bad luck, let's continue. And then there's this cooperative, which is where you can be a member. There's also this nice text in German from Zibli Berg, an author. So it's a cooperative of authors and other artists and lawyers and things like that. They started this to bring people together and also for corporations with others and to create web plugins. Because web, as I said before, most people are using web mail and it's pretty hard to get them into web, into mail applications. So we need to get web plugins, but this is not anything we can do with the company because no investor will give money for free web plugins, unfortunately. Then we have a bunch of more websites, where you get the software as binary and code, the PAP.community with the usual stuff and the PAP.news, which is not there yet, but will be giving an overview of everything. So yeah, and also what's always important with these projects, also where does the money come from? So as I already said, the company gets the usual investor stuff. It's like a startup. It's in Luxembourg because the main guy, we have two founders. One is Swiss, one is Luxembourg. So it also gets funding from the government of Luxembourg, the usual startup tech thing. And the foundation is in Switzerland because Switzerland and foundations fit together nicely. And as I said, most of the people are Swiss. And yeah, so the foundation has all the documents online where you can see on the money. It's mainly private donations in the foundation. Yeah, then the general concept. This is six chapters plus a summary. I just go into directly. This we already seen, PAP does what the user would want to do. So the idea is to take away the crypto needs from the users for a few. Like we have seen this happening with HTTPS. Like before and after Snowden, there was a huge increase of the usage of HTTPS in the web. And a normal user doesn't even see the difference. They just see any green lock or something and they're like, okay, I don't know what that means and it doesn't matter. So this is where we want to go. So they just see emails which are somehow green and they don't even care what's the difference. But ideally, like we have it now with the web that most percentage of the web, okay, I don't know. I haven't seen any numbers on this, but I feel like most percentage of the web is mean by reachable on HTTPS. We would like to have most people being reachable on encrypted channels. And the easy part, pep is easy to install, easy to understand, easy to use. There's no hassle, no training needed. And as already mentioned, also easy for app developers. This is one sub part of the easy. I already explained those trust words. So there's battery or stable instead of EC 5539 and so on. And this is, by the way, a piece we cannot put into software. So to establish trust, you have to look into someone's eyes, basically, even if it's on the phone, right? But that's that we cannot handle on software. Then the key sync also is a part of making it easy. So there are device groups so that you can sync your key on multiple devices. I guess it's easier to explain on this one. So we have a pep user having pep on one device, installing pep on the second device. Now those devices, like the new device, pinks on the group and says, okay, hi, I want to be part of the group. The fingerprints get checked, the handshake gets done, and then all devices exchange their single keys and create a group key which they all agree on. Which means you can not only sync keys but also contacts and calendar. And this also means that you're using finally contacts and calendar in a backup which is not in the cloud, which is others, people's computers, but your own computers. So if you're going on a whatever, a big travel and you take your laptop and your cell phone along, you can just leave one mobile phone at home, leave it plugged with a Wi-Fi, get it synced all the time, and if you happen to get robbed, everything is lost, and you still have this device at home which has all the backups. Then we are trying to do everything right without any compromise. So the whole thing is end to end, peer to peer. There's no centralized infrastructure or any kind of closed services. Because yeah, we don't want to create yet another crypto app where you have to convince all your friends to be part. Then oops, this is German, sorry. So PEP is free software. It's GPL3. It has actually independent external code audits like the Cypherpunks told us 30 years back. And we are compatible with crypto technologies, message transports, platforms and languages. This is more detailed. So the bolded ones are the ones we are already compatible. Asmime passive, if a PEP user gets an asmime message, they can reply on it. But PEP will never start using asmime, I guess you know why. Then we have OTR, OMEMO, Axolotl, that's the stuff we would like to see next earlier. But then if the scene changes like OMEMO two years back, we wouldn't have had OMEMO on that list. But now it's turned out to be really great. So we're trying to support that as well. Same with the transport protocols. So SMTP, IMA, POP3 exchange already supported. And next we would like to see XMPP and also the non-open standards. I guess that's pretty important. Like Twitter DMs or Facebook chats or whatnot. But also stuff like SMS. Then the metadata protection already mentioned that this should be the next thing. If you have people to encrypt, content encryption is not everything. I guess in this audience I don't need to tell too much about it, but the metadata is still there. So what we do right now is we already encrypt the subject inline and we obfuscate and encrypt the rest of the header as much as possible. Like the whole email inclusive header gets wrapped again. So it gets another header which is then obfuscated and gives another information like the one which would originally be there. The problem with the internet is just that there are lots, but to name a few, the problem is that the network generally learns too much. The IP protocol leaks information like crazy, like IP header from where to and so on. We have insecure defaults and rather high complexity for the management. We have centralized components and also administrators. They might be malicious or incompetent, but even if they are nice guys, they can be a target. And these floors are misused already very heavily. We know that. So what we're trying to do is to pipe everything. Oh, this is also German. Sorry about this. I translate on the fly. We're trying to do this whole thing through GNUNET and to explain GNUNET, I try to explain it like this. So when the internet started, we were like in the 70s and 80s, we were like, oh great, I can access your computer and you can access mine. This is awesome. Nowadays, we're right. Okay, sure, I can access other computers, every website, every service I use, I access other computers, but then if you talk to non-techies, they would be what? But they can also access me. This is how I started every crypto party. If you are connected to the internet, the internet is connected to you. This is what lots of people are not aware of. And what we need to have in the far future, this is still like an ongoing project, which will take a lot of time, end to end, encryption and anonymization of all the way the data flows. And this, I go into this more detail in the next chapter. So the summaries that users don't have to think about the crypto anymore, they can just use it by default. We had this journalist writing this sentence once, it is this little hacker inside that decides on the cryptography, choosing to communicate with the message recipient. And this is where we actually want to go. Like in this audience, I guess you all know that you're sitting on your computer, you're talking to someone and then it's going more personal or more private or whatever. And then you decide what medium shift you're doing. And then you continue your conversation. And then maybe your partner says, oh, I'm about to leave the house. Do you have signal? And then you're like, oh, no, I don't have signal, but do you have OMEMO on jobber? Right? Oh, no, I only have OTR. That's not so good if you're on a mobile. And all these things, right? You know about this and you can decide yourself which is the best communication method to use right now. But this is what we cannot expect to all the people out there who are not into technology. And we should also stop to expect them to learn this. This is something which I had to learn over the years. I mean, we are, or lots of us are somewhat missionaries. Is it open source? Is it free software? Is it telling people to go on Linux or something? But we are somewhat missionaries. We are trying to convince the people that this is the better way, even if they don't know. Some people will trust you because they know you as a friend. They don't know about the technology, but they say, okay, if you are telling me, I'll do that. But this, like, small decisions on an everyday basis, we cannot expect the people to do. So this is why we are trying to have this engine who, like, in the future and sometimes knows about the different crypto technologies, knows about the different message transports and can make this decision somehow based on algorithms for the people, which doesn't mean that they are always going to be totally safe. Like I said, the opportunistic approach, as we don't want to hassle the user, worst case, it can even go like, okay, I don't find anything. I sent unencrypted, right? This can also happen. But we just need to get more crypto noise out there. All right. So then the next chapter, this GNU.NET thing, and I actually have quite some time. This is good. So GNU.NET is, you broke the internet. Let's make a GNU one. This is their tagline. So GNU.NET 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 it's really about replacing the internet as we know it. Or not replacing, but like enhancing it with a new version, right? Like I said before, the internet 2.0. It started in 2002, just already quite some time back. It's been followed in academia quite heavily. There was a full department on the university in Munich. And meanwhile, it moved to France. And I think now there's also parted Switzerland and so on. So it's a long process because it's also not something you can do just like on a weekend. To explain what it's about, I made a very hard simplified version of the internet. And this whole thing is based on a talk from Christian Grottof, it's called 45 subsystems in 45 minutes. He already said, oh, this is impossible to do it in 45 minutes. So I'm doing it in 10 now. But if you're interested, you can check it in a much wider version. So this is a very hard simplified version of the internet. You can somehow see the layers, physical layer, Ethernet, IP, TCP, DNS, and then the applications. So I start at the bottom with the physical layer. So rebuilding all the wires and fibers is not a reasonable approach. It won't lead us anywhere, which doesn't mean it's still very important to have stuff like FreeFunk, you can visit them out there that we still make our own infrastructure. But if we start like this, we'll never get ready. So instead, we simply start with what we have, which means we just use existing protocols like TCP, UDP, SNTP, HTTP, Wi-Fi, Bluetooth, whatever is there. There are lots of them. So we make unreliable out-of-order packet delivery semantics on these already existing protocols. So on this layer, the presence will be obfuscated and hiding in the network already, because if you write an email in the concept of email, let's see, but it will not show as an SMTP track in the network, but maybe as an HTTP or something. On this layer, we have this automated transport selection that decides which connection to establish and selects the best transport to use. Like for voice, you can only use transports that have low latency, right? But if you want to do a download or if you want to send a message, you can use something with a higher latency. Then in the next layer, this is called core, where GNUnet runs effectively an off-the-record link encryption between the peers, which means it multiplexes the inbound messages by type to the higher-level subsystems. It hides the connections from or to peers that do not speak the same higher-level protocols. So it's somewhat like the Ethernet layer for GNUnet and simply encrypts that one. Like today, we don't have any encryption there. You can fake and spoof IP addresses as you like. You can listen to communications and so on. So this is all deleted in this layer already. Then the next layer is about decentralized routing. It's decided for an RF5n, so basically it's a routing algorithm that's decentralized. It includes a distributed hash table, which is a randomized variant of Caddemlia, and that works still effectively also in very small networks. Now we come to the heart of the project, Cadet, the transport protocol. This is similar to SCTP, the stream control transmission protocol, and serves end-to-end encryption on this layer. So on top of Cadet, there are additional services created that provide more applications-specific functions. So there's something in development that's called Axolotl that also provides this SCTP-like interface. And SCTP is something like TCP and UDP combined. And Axolotl is this protocol from Signal, and they created something like Axolotl, which protects the metadata. And then they also created something called Lake, which is a further development of Pond. Who knows Pond? Okay. So if you haven't heard about it, then maybe it's like the whole, yeah, I actually have another thing on that because it's happening often. So if you know all, okay, what's happening, what I can tell is by all science and mathematics we know today, all the metadata will be gone that way. And check out the longer talk if you're interested on that. So let's go to another layer. This is the GNU name system. It's very easy because it's just a name system that is secure and decentralized. It provides an alternative public key infrastructure and replaces therefore DNS and X509. And it also does not rely on central root zones or any authorities. It's interoperable with DNS and it achieves query and response privacy. And now the application layer. So application layer is most important in the internet, always been file sharing. This is actually how GNUnet started. It was just like in 2002, the first white paper was only about file sharing. So this file sharing protocol, you can use anonymous or non-animous. And then what we definitely need is to serve all those people who now they say, oh, I go into the internet, what they actually mean is the web. What they mostly mean is one website. And we need to have somewhat social networking things. So some people develop SecoShare for this purpose. Then there is an app called Conversation. Not to mix up with conversations. This is a Java client. Conversation is a voice over IP protocol that works. You have decentralized voice. Then we have an IPv6 to IPv4 translator that already works. And then PEP for messaging. And there is GNUtala for payments. And if you like, you can also do apps for GNUnet yourself. So back to the general concept of GNUnet. This is quotes from their website. It wants to protect the privacy of its users and guard itself against attacks or abuse, become a widely used, reliable, open, non-discriminating, egalitarian, unfettered, and censorship-resistant system of free information exchange. Also wants to serve as a development platform for the next generation of decentralized internet protocols. So please go and check it out. This GNUnet is, as I mentioned, there for 15 years already. It's just gotten a pre-release in June this year, which is the first release since 2014. So if you want to check it out, please do not use the release from 2014 and not the packages you get in your distribution, maybe. But please clone the GIT or take the release from June. And then you can still follow the instructions on the website from that release in 2014. They will fit more or less. If you struggle, you get pretty good help in GNUnet on FreeNode and various mailing lists, which you can use for that. And then please report the bugs, because you will find a lot on GNUnet.org slash bugs. So this project is at the moment at a state where actually now, since just a couple of months, all these protocols I was showing are now in a state that they work. And so this is now, for the first time, a state where we can say, OK, please geeks and nerds and techies all over, go install it, test it, and tell us what's wrong, because there's going to be lots of things wrong. This is an academic project, so it's lots of academic code. And some of it is very old, so we also need to find out which parts have to be rewritten, maybe. And yeah, there's also a GNUnet Java. So GNUnet is generally written in C, but a GNUnet Java exists. And this is more or less just a start for an APE for extensions in Java, which I find pretty important, because this whole thing, it's going to take lots of years until we actually can tell our non-geek friends to upgrade to the internet 2.0. But at that point, I'm afraid, people won't be using any laptops anymore. They won't be using any proper operating systems anymore. But everything's going to be on those mobile systems, so it's actually pretty important, I believe, to have everything somehow available on a Java platform as well. Yeah, that's the summary we had this before. So this is the plan. This is what we're trying to do. It started in 2014 with one person, like a hardcore techie who actually developed the idea. Since 2016, the first couple of developers were employed and starting to actually write software. So on this mass encryption part, we are as far as I showed before, like we have email programs who do PTP without hassle, and we're moving slowly forward. And then the mass anonymization part is, yeah, we need to see the progress on GNUnet, and then we can continue to solve, to rescue the world like that, and to get back to our human rights, as I said before, the rights to protection of the law of mathematics. That's the only thing that's going to help us. And just as a last sentence regarding the law of mathematics, you might have heard that the law of mathematics doesn't apply in Australia. The Australian minister Turnbull said the laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia. So let's show him that this is not true. And here I stop, and I'm there for your questions. Yeah. I repeat the question then. Yeah. I'm here to talk about the first message that you sent to someone you already know, and I think it was at the very beginning, right? So the question was how is the first email key exchange handshake done? So let's use this one because there we have everything. So this is Alison Bob, right? So the first email is actually just unencrypted. So I have two GPG users, and let's say this one is a PEP user, and this is a fresh installment. So the PEP user installed PEP, so the key got generated in the background, and now the user Alice just sends a very normal message, like just a normal email, where the key gets automatically attached, which she doesn't even know about it. So now this first message is a postcard. So this first message is unencrypted. All I need to know is the email address of that person. So I send that email, key is attached, the second person, let's say is also PEP user or GPG user, but the person or the program realizes, oh, this is a message where there is a key attached. Oh, so I import that key and I reply encrypted. So this means we have trust on first use. So you get the key on an untrusted email, actually. Only, yeah, but only by these color indicators. So this is like we have this gray, yellow, and green color indicator and a red one, which makes alarm if whatever the key doesn't fit anymore or something. So the user is not totally aware about it because this email will just look like any other email. Only the second email will be looking different, where there is, depends on the application. So for example, on Android, you have then a bar, the upper bar, which is usually gray, and then it's yellow. And then it gets green at this point. So and in an outlook, I think there is a shield button somewhere where you can also turn off the protection. And this will be gray and like striked out in the first email. In the second email, it will be yellow and maybe showing something that you click on it, because if you click on it, then you get into the verifying fingerprints mode. And then it gets green with the whatever smiling face. So we are also trying not to work with the keys or locks or something to really get this totally out of the user's perspective. Yeah. Yeah. So the question was if I install a new system, how do I get my private key onto the new system? And second part of the question, how to, where are the keys stored? Are they safely stored? So first part is the key gets just normally stored in GPG. So when you are like a Windows user installing pep, the key gets generated automatically. I missed out to mention that actually GPG gets installed automatically. And then so I had this just recently on a very remote spot where we haven't had proper internet. So then the install visit will be very slow because it has to download the whole GPG system first and install that to actually create the key. But then the key will be stored just normal in your GPG settings like on every system. So you can grab it there and get it onto your new system. So yeah, if you have a pep installation, it sure checks if it can find any key. So if it finds a key, it doesn't generate a key, but takes this one. No, it actually does not yet, but it should. So at the moment it doesn't, it just can generate the key. And if you already have an existing key, you need to import it afterwards and kind of override it. But yeah, this is like ideally a key gets detected, but I think that's not there yet. And the second part of the storage, this is a good question because I also haven't mentioned that. So what we need or what we do in this project is that we trust the hardware, which I know we shouldn't do, but I mean, we cannot solve everything, right? So we just at one point said, okay, we assume that the hardware is safe. We need to do that. So we write in all the documentations, like all the user manuals, everything we have, we always write, do folder encryption, take care for your devices, also physical security, everything. But we are also quite aware that especially with this concept of mass encryption, where you want to go to the masses and not to the techies, we'll be having lots of zombie windows systems, which will be doing whatever, but not being safe to store at key. But that's at the end also not the point. So if a person already has such an unsafe system, it also doesn't matter if the GPG key is unsafe, but it matters that the communication that is flying around in the internet is encrypted only at the end, only for the sake of the ones who are protected that way even more like the usual, let's have more crypto noise so that those people who use encryption don't stand out anymore. So but then it's up to you to take care. So it's just stored at the normal spot. And if your normal system is safe, then the key is safe. Is your system is not safe? Then the key is not safe. Yeah. Yeah, that's like either also on the system. So it's only outlined at the moment. So if a person uses map mail on the same device all the time, we can give the option of storing the key on the system. But if you have this webmail, you should also have the option that people actually can use it on different devices. So then it's like the mail-valop approach that you have the key on a stake, which I had actually when I was doing those crypto parties in India, I had this quite often that people haven't had their own device and that we had to use this web plug-in which I already said, okay, everything that has to do with the web is not going to be secure, but okay, there's no other other way to go. So then keep your stick secure. So yeah, then there were two questions. Yeah. So there is, so we just had this discussion on the style yesterday. So we both weren't sure, so I should repeat the question. So how is the scene if you have CC people or BCC people? So if you four here in the first row start now an email, you just sent an email to those three, you attach all their public keys and write an encrypted email to all three, but then those three don't know each other. So they won't be having their keys. So now we weren't sure we need to ask the devs. I actually believe that Pep will be seeing all three keys or all four keys if your key is attached as well. Import then and reply encrypted. My colleague meant that most probably only the key from the person will be seen as the one that gets important, which I don't think makes sense because the software doesn't know who's actually the person except for the email address, but it sees, okay, there is attachments point ASC. So I import them and then once they're imported in the reply, like you make reply all, it'll be encrypted with BCC. It's not possible. I mean, it is possible you can attach all the keys from the people you have in BCC, but then it doesn't make sense, right? There's another approach, AutoCrypt, which I also, it's good to mention actually, it's autocrypt.org, I think. It's a similar approach. They also trying to make encryption more automatic. It's more an approach for the sophisticated users. So what they trying to do is to add the key IDs into the headers. So this is something you could do with a BCC list that you add those into the headers and then only very sophisticated users who knows about the headers can check, okay, who got this email. But generally, if you write BCC to lots of people, you can write them each one of them unencrypted. But then, okay, actually, that's the point, right? Because they cannot reply any, anyhow. Because if they click on reply all, it will be only reply to you. So then, yeah, that works. Really, that's a weird bug. Okay. Yeah, yeah, definitely, definitely. But I don't have those. I mean, I have lots of encrypted email stuff and there are people see seed and then if I do reply all, maybe you can come over to the stall and we talk about this happening more detail. Yeah. Was it an Apple user? Okay. No, no, no, nothing against Apple or maybe, but I just had, I made an experience once. Yeah. Okay. Just why I was asking, I made an experience once, experiment once. It's like two years back or so where I created a GPG key without an email address attached to see how other clients are handling this. And Apple Mail, finally, was also saying, oh my God, I don't know what to do. So I take the own key. So I got encrypted emails from someone else using Apple Mail with their key encrypted, not with mine, so I couldn't read them. That's why I thought maybe if it was an Apple user, it was the same bug. Okay. Then there was a question down there. How is key lifetime handled? Yeah. Um, that's, uh, not really, I don't know exactly, but I think it expires automatically and gets redone. I know that if you have like, if you have a device that's compromised and you want to replace your key, um, the only solution is to broadcast your key. So we've already been thinking about that that in that case you could click on something like, okay, please broadcast my key to everyone I've been talking to encrypted in the last this much time spam, spam, or to everyone in my address book, which I had GPG communication with. Um, but generally this is a problem because people like, as it all happens automatically, you cannot start sending telling people, oh, I have a new key because they wouldn't even know what is the key, but you can send them a broadcast message of, um, which ideally doesn't even then is, isn't even visible of this is my new key. It gets imported by pep and in the future, just the new key will be used. But then if you, um, make the broadcast only to the ones I had contact with the last two weeks, but then someone writes you who you haven't had contact, then they will be using the own keys, so old key. So here we definitely have an unsolved problem of redistributing new keys, but the lives, if time it's actually good question, I think it gets re done once in a while cycle like, but I'm not sure about this. You shouldn't need to ask the others. Okay. Any more question? That's great because it's like perfectly in time 15. Thank you. Thank you.
 Hi, thanks that you're all here.  I'll be talking about pretty easy privacy, which comes from pretty good privacy, which  you might have guessed.  Who knows pretty good privacy?  Okay, that's most of it.  Who's using it?  Okay, a bit less.  Who's using it daily?  Okay, that's not only what was it three or so.  And yeah, that's exactly the problem which we're trying to solve, that pretty good privacy  is good but not easy.  And we're trying to make it easy so that on the one hand side, techies can use it more  at ease, but especially that normal people who are not into tech can just use it.  So we're actually not providing a solution for techies.  We are glad if techies are still using their, I just recently had someone who was using  e-mechs for email and having this with GPG as well.  And this is pretty important that we still have those, let's say, pretty good sophisticated  solutions.  But this is a very low sophisticated solution which is really there for the masses.  And yeah, I'll be going into more detail on that.  But one more question, who had tried to teach GPG to someone?  And who was successful?  Yeah.  Okay, so thanks for everyone who did that.  I also have done lots of crypto parties during, especially after Snowden happened.  I was in India and it was like hundreds.  I taught GPG and I mean, I don't have contact to all those people visiting a crypto party,  but I guess if there is like a handful still using it, I would be very glad about it.  So let's see if this scene is going to change in the next couple of years.  If we look in the past, there has lots of change happened, but now, yeah, let's start.  So I can skip this one as most of you know what it's about.  I make an intro about the general problem.  Then I introduced the technology for mass encryption, we trying to develop.  Then I go more deeper into the general concept of pretty easy privacy.  And then I have actually a big chapter on the technology for metadata protection.  The so-called GNUnet who has heard about GNUnet before.  Okay, just a few.  So I hope I have enough time to go into more detail, but at least you get an idea of what  it's going to, what it's about.  And then yeah, the usual summary and Q and A, but maybe we make the Q and A a bit shorter.  Let's see how far we come because we also have a stall in the project area when you  enter the room on the left side.  We are like the second table around the corner.  All right, so I start with the Declaration of Human Rights, Article 12.  No one shall be subjected to arbitrary interference with this privacy, family, home or correspondence,  nor to attacks upon this honor and reputation.  Everyone has the right to the protection of the law against such interference or attacks.  So I highlight two points here, arbitrary interference and the right to protection.  Just give this little quote.  I don't know, I guess most of you have heard about it.  This is just published a day before yesterday or three days before that the court has confirmed  that the searches and seizures were illegal.  So this was an arbitrary interference which was not protected by the law, but done by  the law.  So and there is another quote, I don't want to live in a world where everything that I  say, everything I do, everyone I talk to, every expression or creativity or love or  friendship is recorded, which is from Edward Snowden who has shown us that actually the  word is like this.  So everything I talk, like everyone I talk to online is recorded.  So this is one of those thousands of thousands of slides he was publishing.  So we have the service providers here and the list of stuff which you can get including  special requests so you get literally everything.  So yes, we scan.  We should actually get an update on this if someone is a designer.  But it's not only the governments who are trying to spy on us.  There's also this problem where I really like this little picture of those two pigs saying  that they don't have to pay for the barn and that even the food is for free, which means  that if you're not paying for it, you're not the customer, you're the product being sold.  So the general problem is that online communication is visible like a postcard and that this world  has mass surveillance.  And what we're trying to do as a solution is mass encryption and then mass anonymization.  But how we're going to do this, we're trying to do software which does what the user would  want to do.  So instead of writing how to guides, we write user expectations into software and protocols  to automatize all steps a user would need to carry out.  Which is key management, key discovery, private key handling and lots of more things.  So how we're doing this, we wrote an RFC or an so-called internet draft which is the  pre RFC, which is online and ready for discussions together with the ISOC Switzerland.  It's been written and this is the abstract.  I just read out loud the underlying stuff.  Building on already available security formats and mass transports, pretty easy privacy describes  protocols to automatize operations, key management, key discovery, private key handling that have  been seen to be the barriers to deployment of end to end secure interpersonal messaging.  So this is what PEP does.  So we're automatizing these things which usually the user should do but which you guys who  taught others also most probably figured which is pretty difficult for the users.  By the way, what I found out in the last couple of years is also that it turns out to be very  difficult for users nowadays to actually use a mail client.  So if you're not keen on teaching someone GPG but still think people should get to know  more about these stuff, then tell them about email clients.  Because this is turning out to be more and more of a problem because people only use  web mail and they don't even know the concept of an email program.  Call it app then they understand what it means.  So this is what PEP does and what does the user do?  The user should only do messages.  So this is how it works if you have two PEP users but also one can be a normal GPG user  but on the picture we have two PEP users so they install PEP.  Then one person, this is Bob writing to Alice, writing the first email which is unencrypted  like a postcard.  But this email already has a key attached.  So in that step the key gets generated.  The user doesn't even get to know about it.  The key gets attached, Alice writes back which is already encrypted.  So now those two guys can talk encrypted to each other and if Alice is a normal GPG user  all she needs to do is to attach her key as an attachment.  If you send a PEP user, oh here's my key, this is the URL, then the PEP user is like  okay what are you talking about?  But just attach the key, PEP will see this is a key and reply encrypted.  So this means you're in the encrypted mode.  But we do trust on first use.  You see the first key gets unencrypted to the other person.  So ideally you also check the fingerprints where we have this concept of trust words  where we translate the hexadecimal fingerprints into words.  So you call each other, say the words, you make the handshake and now you're encrypted  and verified.  And the only thing as the user is that you see those colors.  So here your email somehow turns yellow, depends on the application.  There's some yellow spot and here you are in the green mode.  So ideally everyone should be in the green mode.  This is another diagram showing this.  So first email unencrypted and key exchange, second email is already encrypted.  Now you do the verification and then you're in the secure and trusted mode.  All right, so what's PEP, a software for various platforms to easily use existing crypto tools.  It's designed to encrypt all digital written communication with the starting point of email.  I'll explain that later.  It encrypts automatically with whatever most privacy enhancing crypto standard available,  hence privacy by default.  We're going with the opportunistic approach here.  So if you have seen the signal and these guys, they started to have this opportunistic approach  of having as much as crypto as possible, right?  And if not, then not.  And all end user software must be hassle free and zero touch.  That's why we also don't have a password on the GPG key, for example.  What's PEP not, that's also pretty important because we're not yet another crypto tool  with a closed user base or something.  We're using existing crypto standards.  So we're compatible with everything that exists out there.  I mean, not everything, but everything that's like widely used.  We're not a centralized platform provider.  We're not implementing any own crypto.  We're not replacing any existing crypto tool.  And we're not just an email encryption tool.  This is just the beginning.  Who are we?  This is also very important in these projects.  We see ourselves as cipher punks.  We want to roll out mass encryption to optimize the costs of mass surveillance.  We want to make the use of crypto pretty easy, not only for the users, but also the developer  can plug it into their apps and the user can just use it by default.  What cipher punks?  This is quotes from the cipher punk manifesto.  Cipher punks are actively engaged in making the network safer, advocate widespread use  of strong cryptography as a route to social and political change.  And they aim to achieve privacy and security through proactive use of cryptography.  And he's also very nice quote, which I really like because of this whole privacy.  Oh, I don't have anything to hide thing.  Privacy is necessary for an open society in the electronic age.  Privacy is not secrecy.  A private matter is something one doesn't want the whole world to know.  But a secret matter is something one doesn't want anybody to know.  Privacy is the power to selectively reveal oneself to the world.  And then last quote, we cannot expect governments, corporations or other large faceless organizations  to grant us privacy.  We must defend our own privacy if we expect to have any at all.  We know that someone has to write software to defend privacy and we're going to write  it.  So this is where we're coming from.  We are actually most of us are a group of people who've done like all these crypto parties  and these things.  And I, for example, wrote in 2013 the whole crypto party.in the new web page, this whole  how to and whatever.  And we're just at a point where we were at a point and we still are where we were just  like, okay, let's stop writing how tos.  Let's write software who's doing what we're trying to tell the users.  To just come back to this declaration of human rights, everyone has the right to protection  of the law.  And this is not the case.  We know that.  So what we need to do, if the government doesn't help us, if the law doesn't help us, we need  to take the help of the law of mathematics, like just physics.  That's what we need to do all together.  And this just as a really short side note, Cypher is not about cyber.  Cyber is also not about internet.  It's the study of control and communications.  And Cypher is an alternative spelling for Cypher.  And also, who's me?  I studied anthropology and computer science.  So I'm actually a humanist.  I'm also carpenter.  I'm Schreiner.  My name serves as a unique addressing in internet and web.  That's why I'm using it widely.  If you want to know my real name, just check the board members of these associations.  And if you find a female name, it's most probably mine.  And this is stuff I've done, which I always like to point out.  So please come and visit us in India, for example.  Yeah.  Now we're actually getting into the things.  So I'm telling you about the architecture of PEP, which consists of the engine, adapter,  and applications.  I show you a quick list of repos, developing platforms, and I also add the organizational  forms into the technology chapter.  I explain you why once it's about time.  So the general architecture is, as I said, applications, adapter, and engine.  So we have this engine who knows about the crypto functionalities.  We have adapters in various languages, which are then communicating with the applications.  I go into more detail on that.  But here's some more examples.  So for Outlook, you need a com server adapter.  For Android, we have this JNI adapter.  For iOS, there's an Objective C adapter, and so on.  So this engine drives several crypto standards on different digital channels, like message  transport protocols, which is at the moment only email, like SMTP, IMAP, Exchange, blah,  blah, blah.  It's written in C99.  It has roughly 10,000 lines of code and has regular code audits.  It's not meant to be used in the application code directly, but you can just plug and  play the engine as a developer, which means you don't have to maintain any crypto.  The plug and play is a bit too much because our documentation is very bad.  So if you want to do that, then please contact us as well.  If you wonder about the documentation, please.  Yeah.  So you don't have to maintain any crypto.  You're like, okay, what?  But we have regular code audits.  They're published on this URL also in the blog.  Then once they happen and they're done by Section 1 by Bev, maybe some people know him.  He's also been part of this crew for quite a while.  This engine takes care of the messaging functions, the crypto tech services.  It's like a crypto API.  Makes this fully automated key management services and the trust rating.  It knows about the transport protocols, like the message transport ways.  And in the future, there will be this metadata protection, YNN.  So this means it does the decryption and encryption, the MIME encoding and decoding,  the message processing for the adapter, the key management, which is generation at the  beginning and then the verification blacklisting, all these things.  And also key synchronization of same account between devices.  This is still in testing, but about to come out soon.  This will be more or less, I think, something which I hope lots of you are going to be happy  about because it is still a problem.  Like you get encrypted emails and you're like, oh, sorry, I'm on the road.  Please contact me on another channel too if it's important.  Otherwise, I'll come back to you tomorrow or something.  So this is always very annoying.  So this engine gets connected through the adapters to applications.  These adapters are language or environment specific interfaces between the engine API  and an implication development environment like a programming language or an IDE or something.  Basically the adapter is bindings.  So and this is a list of adapters we have actively laying around.  Not all of them are in use so far.  So you're very invited to check with your own communication apps if you want to use  one of those adapters.  And this is how it works.  The app makes calls to the adapter for the function at once like encrypt or decrypt or  get the trust words or trust level or something.  Then the adapter converts that into a normalized standardized form for the engine, for the messages  and makes the C library call.  Engine magic happens and the adapter gives the result back to the application.  So it's actually pretty easy.  The current implementation of PEP is that it handles open 3GP and as MIMe passively  without any hassle for the user.  It automatically encrypts the subject in line.  There's this automatic key management.  There's no key server or other centralized infrastructure because the key always gets  attached to every email.  Those fingerprints get translated into trust words.  There's an opt in passphrase for keys.  So by default there's no passphrase because the users will stop using it if it starts  hassling.  And the header gets encrypted and obfuscated and this sync protocol is in the making to  get the keys synced over various devices.  I have more details on that.  So this is the applications which we have at the moment.  We have Android, Thunderbird with any mail and PEP for iOS is a very early alpha which  I think at the moment is only like a pregroup in testing.  But if you're interested, we can give you access as well.  This is the list of repositories.  You find them all online on various places because we are like a widespread organization.  And this is a better overview here.  You also find everything on PEP software and on PEP foundation slash PEP software.  So here's engine and Raptor, Android, iOS, Outlook and any mail, everything on a different  place.  And this is development platforms.  So basically everything you can think about.  And now the organizational forms.  So we have a company, a foundation and a cooperative that sign a genocent shaft.  The company is selling applications and services and sits in Luxembourg.  The foundation is supporting free software and very important, the code belongs to the  foundation.  So the foundation is actually the heart of this.  So the idea is that the company can also get investors money and stuff like that.  And then if the company breaks or something fails, the code stays with the foundation.  So the code will always be safe.  And if something with the company happens, we can still say, okay, bad luck, let's continue.  And then there's this cooperative, which is where you can be a member.  There's also this nice text in German from Zibli Berg, an author.  So it's a cooperative of authors and other artists and lawyers and things like that.  They started this to bring people together and also for corporations with others and  to create web plugins.  Because web, as I said before, most people are using web mail and it's pretty hard to  get them into web, into mail applications.  So we need to get web plugins, but this is not anything we can do with the company because  no investor will give money for free web plugins, unfortunately.  Then we have a bunch of more websites, where you get the software as binary and code, the  PAP.community with the usual stuff and the PAP.news, which is not there yet, but will  be giving an overview of everything.  So yeah, and also what's always important with these projects, also where does the money  come from?  So as I already said, the company gets the usual investor stuff.  It's like a startup.  It's in Luxembourg because the main guy, we have two founders.  One is Swiss, one is Luxembourg.  So it also gets funding from the government of Luxembourg, the usual startup tech thing.  And the foundation is in Switzerland because Switzerland and foundations fit together nicely.  And as I said, most of the people are Swiss.  And yeah, so the foundation has all the documents online where you can see on the money.  It's mainly private donations in the foundation.  Yeah, then the general concept.  This is six chapters plus a summary.  I just go into directly.  This we already seen, PAP does what the user would want to do.  So the idea is to take away the crypto needs from the users for a few.  Like we have seen this happening with HTTPS.  Like before and after Snowden, there was a huge increase of the usage of HTTPS in the  web.  And a normal user doesn't even see the difference.  They just see any green lock or something and they're like, okay, I don't know what  that means and it doesn't matter.  So this is where we want to go.  So they just see emails which are somehow green and they don't even care what's the  difference.  But ideally, like we have it now with the web that most percentage of the web, okay,  I don't know.  I haven't seen any numbers on this, but I feel like most percentage of the web is mean  by reachable on HTTPS.  We would like to have most people being reachable on encrypted channels.  And the easy part, pep is easy to install, easy to understand, easy to use.  There's no hassle, no training needed.  And as already mentioned, also easy for app developers.  This is one sub part of the easy.  I already explained those trust words.  So there's battery or stable instead of EC 5539 and so on.  And this is, by the way, a piece we cannot put into software.  So to establish trust, you have to look into someone's eyes, basically, even if it's on  the phone, right?  But that's that we cannot handle on software.  Then the key sync also is a part of making it easy.  So there are device groups so that you can sync your key on multiple devices.  I guess it's easier to explain on this one.  So we have a pep user having pep on one device, installing pep on the second device.  Now those devices, like the new device, pinks on the group and says, okay, hi, I want to  be part of the group.  The fingerprints get checked, the handshake gets done, and then all devices exchange their  single keys and create a group key which they all agree on.  Which means you can not only sync keys but also contacts and calendar.  And this also means that you're using finally contacts and calendar in a backup which is  not in the cloud, which is others, people's computers, but your own computers.  So if you're going on a whatever, a big travel and you take your laptop and your cell phone  along, you can just leave one mobile phone at home, leave it plugged with a Wi-Fi, get  it synced all the time, and if you happen to get robbed, everything is lost, and you  still have this device at home which has all the backups.  Then we are trying to do everything right without any compromise.  So the whole thing is end to end, peer to peer.  There's no centralized infrastructure or any kind of closed services.  Because yeah, we don't want to create yet another crypto app where you have to convince  all your friends to be part.  Then oops, this is German, sorry.  So PEP is free software.  It's GPL3.  It has actually independent external code audits like the Cypherpunks told us 30 years back.  And we are compatible with crypto technologies, message transports, platforms and languages.  This is more detailed.  So the bolded ones are the ones we are already compatible.  Asmime passive, if a PEP user gets an asmime message, they can reply on it.  But PEP will never start using asmime, I guess you know why.  Then we have OTR, OMEMO, Axolotl, that's the stuff we would like to see next earlier.  But then if the scene changes like OMEMO two years back, we wouldn't have had OMEMO on  that list.  But now it's turned out to be really great.  So we're trying to support that as well.  Same with the transport protocols.  So SMTP, IMA, POP3 exchange already supported.  And next we would like to see XMPP and also the non-open standards.  I guess that's pretty important.  Like Twitter DMs or Facebook chats or whatnot.  But also stuff like SMS.  Then the metadata protection already mentioned that this should be the next thing.  If you have people to encrypt, content encryption is not everything.  I guess in this audience I don't need to tell too much about it, but the metadata is still  there.  So what we do right now is we already encrypt the subject inline and we obfuscate and encrypt  the rest of the header as much as possible.  Like the whole email inclusive header gets wrapped again.  So it gets another header which is then obfuscated and gives another information like the one  which would originally be there.  The problem with the internet is just that there are lots, but to name a few, the problem  is that the network generally learns too much.  The IP protocol leaks information like crazy, like IP header from where to and so on.  We have insecure defaults and rather high complexity for the management.  We have centralized components and also administrators.  They might be malicious or incompetent, but even if they are nice guys, they can be a  target.  And these floors are misused already very heavily.  We know that.  So what we're trying to do is to pipe everything.  Oh, this is also German.  Sorry about this.  I translate on the fly.  We're trying to do this whole thing through GNUNET and to explain GNUNET, I try to explain  it like this.  So when the internet started, we were like in the 70s and 80s, we were like, oh great,  I can access your computer and you can access mine.  This is awesome.  Nowadays, we're right.  Okay, sure, I can access other computers, every website, every service I use, I access  other computers, but then if you talk to non-techies, they would be what?  But they can also access me.  This is how I started every crypto party.  If you are connected to the internet, the internet is connected to you.  This is what lots of people are not aware of.  And what we need to have in the far future, this is still like an ongoing project, which  will take a lot of time, end to end, encryption and anonymization of all the way the data  flows.  And this, I go into this more detail in the next chapter.  So the summaries that users don't have to think about the crypto anymore, they can just  use it by default.  We had this journalist writing this sentence once, it is this little hacker inside that  decides on the cryptography, choosing to communicate with the message recipient.  And this is where we actually want to go.  Like in this audience, I guess you all know that you're sitting on your computer, you're  talking to someone and then it's going more personal or more private or whatever.  And then you decide what medium shift you're doing.  And then you continue your conversation.  And then maybe your partner says, oh, I'm about to leave the house.  Do you have signal?  And then you're like, oh, no, I don't have signal, but do you have OMEMO on jobber?  Right?  Oh, no, I only have OTR.  That's not so good if you're on a mobile.  And all these things, right?  You know about this and you can decide yourself which is the best communication method to  use right now.  But this is what we cannot expect to all the people out there who are not into technology.  And we should also stop to expect them to learn this.  This is something which I had to learn over the years.  I mean, we are, or lots of us are somewhat missionaries.  Is it open source?  Is it free software?  Is it telling people to go on Linux or something?  But we are somewhat missionaries.  We are trying to convince the people that this is the better way, even if they don't  know.  Some people will trust you because they know you as a friend.  They don't know about the technology, but they say, okay, if you are telling me, I'll  do that.  But this, like, small decisions on an everyday basis, we cannot expect the people to do.  So this is why we are trying to have this engine who, like, in the future and sometimes  knows about the different crypto technologies, knows about the different message transports  and can make this decision somehow based on algorithms for the people, which doesn't  mean that they are always going to be totally safe.  Like I said, the opportunistic approach, as we don't want to hassle the user, worst case,  it can even go like, okay, I don't find anything.  I sent unencrypted, right?  This can also happen.  But we just need to get more crypto noise out there.  All right.  So then the next chapter, this GNU.NET thing, and I actually have quite some time.  This is good.  So GNU.NET is, you broke the internet.  Let's make a GNU one.  This is their tagline.  So GNU.NET 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 it's really about replacing the internet as we know it.  Or not replacing, but like enhancing it with a new version, right?  Like I said before, the internet 2.0.  It started in 2002, just already quite some time back.  It's been followed in academia quite heavily.  There was a full department on the university in Munich.  And meanwhile, it moved to France.  And I think now there's also parted Switzerland and so on.  So it's a long process because it's also not something you can do just like on a weekend.  To explain what it's about, I made a very hard simplified version of the internet.  And this whole thing is based on a talk from Christian Grottof, it's called 45 subsystems  in 45 minutes.  He already said, oh, this is impossible to do it in 45 minutes.  So I'm doing it in 10 now.  But if you're interested, you can check it in a much wider version.  So this is a very hard simplified version of the internet.  You can somehow see the layers, physical layer, Ethernet, IP, TCP, DNS, and then the applications.  So I start at the bottom with the physical layer.  So rebuilding all the wires and fibers is not a reasonable approach.  It won't lead us anywhere, which doesn't mean it's still very important to have stuff like  FreeFunk, you can visit them out there that we still make our own infrastructure.  But if we start like this, we'll never get ready.  So instead, we simply start with what we have, which means we just use existing protocols  like TCP, UDP, SNTP, HTTP, Wi-Fi, Bluetooth, whatever is there.  There are lots of them.  So we make unreliable out-of-order packet delivery semantics on these already existing  protocols.  So on this layer, the presence will be obfuscated and hiding in the network already, because  if you write an email in the concept of email, let's see, but it will not show as an SMTP  track in the network, but maybe as an HTTP or something.  On this layer, we have this automated transport selection that decides which connection to  establish and selects the best transport to use.  Like for voice, you can only use transports that have low latency, right?  But if you want to do a download or if you want to send a message, you can use something  with a higher latency.  Then in the next layer, this is called core, where GNUnet runs effectively an off-the-record  link encryption between the peers, which means it multiplexes the inbound messages by type  to the higher-level subsystems.  It hides the connections from or to peers that do not speak the same higher-level protocols.  So it's somewhat like the Ethernet layer for GNUnet and simply encrypts that one.  Like today, we don't have any encryption there.  You can fake and spoof IP addresses as you like.  You can listen to communications and so on.  So this is all deleted in this layer already.  Then the next layer is about decentralized routing.  It's decided for an RF5n, so basically it's a routing algorithm that's decentralized.  It includes a distributed hash table, which is a randomized variant of Caddemlia, and  that works still effectively also in very small networks.  Now we come to the heart of the project, Cadet, the transport protocol.  This is similar to SCTP, the stream control transmission protocol, and serves end-to-end  encryption on this layer.  So on top of Cadet, there are additional services created that provide more applications-specific  functions.  So there's something in development that's called Axolotl that also provides this SCTP-like  interface.  And SCTP is something like TCP and UDP combined.  And Axolotl is this protocol from Signal, and they created something like Axolotl, which  protects the metadata.  And then they also created something called Lake, which is a further development of Pond.  Who knows Pond?  Okay.  So if you haven't heard about it, then maybe it's like the whole, yeah, I actually have  another thing on that because it's happening often.  So if you know all, okay, what's happening, what I can tell is by all science and mathematics  we know today, all the metadata will be gone that way.  And check out the longer talk if you're interested on that.  So let's go to another layer.  This is the GNU name system.  It's very easy because it's just a name system that is secure and decentralized.  It provides an alternative public key infrastructure and replaces therefore DNS and X509.  And it also does not rely on central root zones or any authorities.  It's interoperable with DNS and it achieves query and response privacy.  And now the application layer.  So application layer is most important in the internet, always been file sharing.  This is actually how GNUnet started.  It was just like in 2002, the first white paper was only about file sharing.  So this file sharing protocol, you can use anonymous or non-animous.  And then what we definitely need is to serve all those people who now they say, oh, I go  into the internet, what they actually mean is the web.  What they mostly mean is one website.  And we need to have somewhat social networking things.  So some people develop SecoShare for this purpose.  Then there is an app called Conversation.  Not to mix up with conversations.  This is a Java client.  Conversation is a voice over IP protocol that works.  You have decentralized voice.  Then we have an IPv6 to IPv4 translator that already works.  And then PEP for messaging.  And there is GNUtala for payments.  And if you like, you can also do apps for GNUnet yourself.  So back to the general concept of GNUnet.  This is quotes from their website.  It wants to protect the privacy of its users and guard itself against attacks or abuse,  become a widely used, reliable, open, non-discriminating, egalitarian, unfettered, and censorship-resistant  system of free information exchange.  Also wants to serve as a development platform for the next generation of decentralized internet  protocols.  So please go and check it out.  This GNUnet is, as I mentioned, there for 15 years already.  It's just gotten a pre-release in June this year, which is the first release since 2014.  So if you want to check it out, please do not use the release from 2014 and not the  packages you get in your distribution, maybe.  But please clone the GIT or take the release from June.  And then you can still follow the instructions on the website from that release in 2014.  They will fit more or less.  If you struggle, you get pretty good help in GNUnet on FreeNode and various mailing lists,  which you can use for that.  And then please report the bugs, because you will find a lot on GNUnet.org slash bugs.  So this project is at the moment at a state where actually now, since just a couple of  months, all these protocols I was showing are now in a state that they work.  And so this is now, for the first time, a state where we can say, OK, please geeks and  nerds and techies all over, go install it, test it, and tell us what's wrong, because  there's going to be lots of things wrong.  This is an academic project, so it's lots of academic code.  And some of it is very old, so we also need to find out which parts have to be rewritten,  maybe.  And yeah, there's also a GNUnet Java.  So GNUnet is generally written in C, but a GNUnet Java exists.  And this is more or less just a start for an APE for extensions in Java, which I find  pretty important, because this whole thing, it's going to take lots of years until we  actually can tell our non-geek friends to upgrade to the internet 2.0.  But at that point, I'm afraid, people won't be using any laptops anymore.  They won't be using any proper operating systems anymore.  But everything's going to be on those mobile systems, so it's actually pretty important,  I believe, to have everything somehow available on a Java platform as well.  Yeah, that's the summary we had this before.  So this is the plan.  This is what we're trying to do.  It started in 2014 with one person, like a hardcore techie who actually developed the  idea.  Since 2016, the first couple of developers were employed and starting to actually write  software.  So on this mass encryption part, we are as far as I showed before, like we have email  programs who do PTP without hassle, and we're moving slowly forward.  And then the mass anonymization part is, yeah, we need to see the progress on GNUnet, and  then we can continue to solve, to rescue the world like that, and to get back to our human  rights, as I said before, the rights to protection of the law of mathematics.  That's the only thing that's going to help us.  And just as a last sentence regarding the law of mathematics, you might have heard that  the law of mathematics doesn't apply in Australia.  The Australian minister Turnbull said the laws of mathematics are very commendable, but the  only law that applies in Australia is the law of Australia.  So let's show him that this is not true.  And here I stop, and I'm there for your questions.  Yeah.  I repeat the question then.  Yeah.  I'm here to talk about the first message that you sent to someone you already know,  and I think it was at the very beginning, right?  So the question was how is the first email key exchange handshake done?  So let's use this one because there we have everything.  So this is Alison Bob, right?  So the first email is actually just unencrypted.  So I have two GPG users, and let's say this one is a PEP user, and this is a fresh installment.  So the PEP user installed PEP, so the key got generated in the background, and now the  user Alice just sends a very normal message, like just a normal email, where the key gets  automatically attached, which she doesn't even know about it.  So now this first message is a postcard.  So this first message is unencrypted.  All I need to know is the email address of that person.  So I send that email, key is attached, the second person, let's say is also PEP user  or GPG user, but the person or the program realizes, oh, this is a message where there  is a key attached.  Oh, so I import that key and I reply encrypted.  So this means we have trust on first use.  So you get the key on an untrusted email, actually.  Only, yeah, but only by these color indicators.  So this is like we have this gray, yellow, and green color indicator and a red one, which  makes alarm if whatever the key doesn't fit anymore or something.  So the user is not totally aware about it because this email will just look like any  other email.  Only the second email will be looking different, where there is, depends on the application.  So for example, on Android, you have then a bar, the upper bar, which is usually gray,  and then it's yellow.  And then it gets green at this point.  So and in an outlook, I think there is a shield button somewhere where you can also turn off  the protection.  And this will be gray and like striked out in the first email.  In the second email, it will be yellow and maybe showing something that you click on it,  because if you click on it, then you get into the verifying fingerprints mode.  And then it gets green with the whatever smiling face.  So we are also trying not to work with the keys or locks or something to really get this  totally out of the user's perspective.  Yeah.  Yeah.  So the question was if I install a new system, how do I get my private key onto the new system?  And second part of the question, how to, where are the keys stored?  Are they safely stored?  So first part is the key gets just normally stored in GPG.  So when you are like a Windows user installing pep, the key gets generated automatically.  I missed out to mention that actually GPG gets installed automatically.  And then so I had this just recently on a very remote spot where we haven't had proper  internet.  So then the install visit will be very slow because it has to download the whole GPG system  first and install that to actually create the key.  But then the key will be stored just normal in your GPG settings like on every system.  So you can grab it there and get it onto your new system.  So yeah, if you have a pep installation, it sure checks if it can find any key.  So if it finds a key, it doesn't generate a key, but takes this one.  No, it actually does not yet, but it should.  So at the moment it doesn't, it just can generate the key.  And if you already have an existing key, you need to import it afterwards and kind of override  it.  But yeah, this is like ideally a key gets detected, but I think that's not there yet.  And the second part of the storage, this is a good question because I also haven't mentioned  that.  So what we need or what we do in this project is that we trust the hardware, which I know  we shouldn't do, but I mean, we cannot solve everything, right?  So we just at one point said, okay, we assume that the hardware is safe.  We need to do that.  So we write in all the documentations, like all the user manuals, everything we have,  we always write, do folder encryption, take care for your devices, also physical security,  everything.  But we are also quite aware that especially with this concept of mass encryption, where  you want to go to the masses and not to the techies, we'll be having lots of zombie windows  systems, which will be doing whatever, but not being safe to store at key.  But that's at the end also not the point.  So if a person already has such an unsafe system, it also doesn't matter if the GPG  key is unsafe, but it matters that the communication that is flying around in the internet is encrypted  only at the end, only for the sake of the ones who are protected that way even more  like the usual, let's have more crypto noise so that those people who use encryption don't  stand out anymore.  So but then it's up to you to take care.  So it's just stored at the normal spot.  And if your normal system is safe, then the key is safe.  Is your system is not safe?  Then the key is not safe.  Yeah.  Yeah, that's like either also on the system.  So it's only outlined at the moment.  So if a person uses map mail on the same device all the time, we can give the option of storing  the key on the system.  But if you have this webmail, you should also have the option that people actually can use  it on different devices.  So then it's like the mail-valop approach that you have the key on a stake, which I  had actually when I was doing those crypto parties in India, I had this quite often that  people haven't had their own device and that we had to use this web plug-in which I already  said, okay, everything that has to do with the web is not going to be secure, but okay,  there's no other other way to go.  So then keep your stick secure.  So yeah, then there were two questions.  Yeah.  So there is, so we just had this discussion on the style yesterday.  So we both weren't sure, so I should repeat the question.  So how is the scene if you have CC people or BCC people?  So if you four here in the first row start now an email, you just sent an email to those  three, you attach all their public keys and write an encrypted email to all three, but  then those three don't know each other.  So they won't be having their keys.  So now we weren't sure we need to ask the devs.  I actually believe that Pep will be seeing all three keys or all four keys if your key  is attached as well.  Import then and reply encrypted.  My colleague meant that most probably only the key from the person will be seen as the  one that gets important, which I don't think makes sense because the software doesn't know  who's actually the person except for the email address, but it sees, okay, there is attachments  point ASC.  So I import them and then once they're imported in the reply, like you make reply all, it'll  be encrypted with BCC.  It's not possible.  I mean, it is possible you can attach all the keys from the people you have in BCC,  but then it doesn't make sense, right?  There's another approach, AutoCrypt, which I also, it's good to mention actually, it's  autocrypt.org, I think.  It's a similar approach.  They also trying to make encryption more automatic.  It's more an approach for the sophisticated users.  So what they trying to do is to add the key IDs into the headers.  So this is something you could do with a BCC list that you add those into the headers and  then only very sophisticated users who knows about the headers can check, okay, who got  this email.  But generally, if you write BCC to lots of people, you can write them each one of them  unencrypted.  But then, okay, actually, that's the point, right?  Because they cannot reply any, anyhow.  Because if they click on reply all, it will be only reply to you.  So then, yeah, that works.  Really, that's a weird bug.  Okay.  Yeah, yeah, definitely, definitely.  But I don't have those.  I mean, I have lots of encrypted email stuff and there are people see seed and then if  I do reply all, maybe you can come over to the stall and we talk about this happening  more detail.  Yeah.  Was it an Apple user?  Okay.  No, no, no, nothing against Apple or maybe, but I just had, I made an experience once.  Yeah.  Okay.  Just why I was asking, I made an experience once, experiment once.  It's like two years back or so where I created a GPG key without an email address attached  to see how other clients are handling this.  And Apple Mail, finally, was also saying, oh my God, I don't know what to do.  So I take the own key.  So I got encrypted emails from someone else using Apple Mail with their key encrypted,  not with mine, so I couldn't read them.  That's why I thought maybe if it was an Apple user, it was the same bug.  Okay.  Then there was a question down there.  How is key lifetime handled?  Yeah.  Um, that's, uh, not really, I don't know exactly, but I think it expires automatically and gets  redone. I know that if you have like, if you have a device that's compromised and you want  to replace your key, um, the only solution is to broadcast your key.  So we've already been thinking about that that in that case you could click on something  like, okay, please broadcast my key to everyone I've been talking to encrypted in the last  this much time spam, spam, or to everyone in my address book, which I had GPG communication  with.  Um, but generally this is a problem because people like, as it all happens automatically,  you cannot start sending telling people, oh, I have a new key because they wouldn't even  know what is the key, but you can send them a broadcast message of, um, which ideally doesn't  even then is, isn't even visible of this is my new key.  It gets imported by pep and in the future, just the new key will be used.  But then if you, um, make the broadcast only to the ones I had contact with the last two  weeks, but then someone writes you who you haven't had contact, then they will be using  the own keys, so old key.  So here we definitely have an unsolved problem of redistributing new keys, but the lives,  if time it's actually good question, I think it gets re done once in a while cycle like,  but I'm not sure about this.  You shouldn't need to ask the others.  Okay.  Any more question?  That's great because it's like perfectly in time 15.  Thank you.  Thank you.
2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_0_179.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_180_3551.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_3552_3647.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_3648_4895.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_4896_4943.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_4944_5495.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_5496_6047.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_6048_6371.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_6372_6539.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_6540_7103.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_7104_7223.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_7224_7367.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_7368_7631.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_7632_7811.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_7812_8231.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_8232_8819.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_8820_9047.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_9048_9227.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_9228_9839.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_9840_11003.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_11004_11147.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_11148_11315.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_11316_13499.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_13500_13859.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_13860_15083.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_15084_15779.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_15780_16355.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_16356_18683.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_18684_19235.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_19236_19559.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_19560_20555.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_20556_20651.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_20652_21095.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_21096_21503.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_21504_21839.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_21840_23975.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_23976_25043.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_25044_28283.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_28284_28559.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_28560_32999.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_33000_33203.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_33204_34763.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_34764_35723.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_35724_36011.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_36012_37643.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_37644_38159.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_38160_44243.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_44244_48059.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_48060_48443.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_48444_49763.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_49764_50723.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_50724_50903.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_50904_54407.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_54408_60419.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_60420_64463.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_64464_65963.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_65964_66155.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_66156_66743.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_66744_67871.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_67872_67967.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_67968_68015.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68016_68063.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68064_68111.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68112_68159.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68160_68207.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68208_68291.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68292_68339.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68340_68387.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68388_68603.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68604_68867.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_68868_73835.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_73836_78659.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_78660_88091.png 2018_-_Let_s_roll_out_mass_encryption__dAL5i6EFmPM_88092_88336.png
Hi, thanks that you're all here. I'll be talking about pretty easy privacy, which comes from pretty good privacy, which you might have guessed. Who knows pretty good privacy? Okay, that's most of it. Who's using it? Okay, a bit less. Who's using it daily? Okay, that's not only what was it three or so. And yeah, that's exactly the problem which we're trying to solve, that pretty good privacy is good but not easy. And we're trying to make it easy so that on the one hand side, techies can use it more at ease, but especially that normal people who are not into tech can just use it. So we're actually not providing a solution for techies. We are glad if techies are still using their, I just recently had someone who was using e-mechs for email and having this with GPG as well. And this is pretty important that we still have those, let's say, pretty good sophisticated solutions. But this is a very low sophisticated solution which is really there for the masses. And yeah, I'll be going into more detail on that. But one more question, who had tried to teach GPG to someone? And who was successful? Yeah. Okay, so thanks for everyone who did that. I also have done lots of crypto parties during, especially after Snowden happened. I was in India and it was like hundreds. I taught GPG and I mean, I don't have contact to all those people visiting a crypto party, but I guess if there is like a handful still using it, I would be very glad about it. So let's see if this scene is going to change in the next couple of years. If we look in the past, there has lots of change happened, but now, yeah, let's start. So I can skip this one as most of you know what it's about. I make an intro about the general problem. Then I introduced the technology for mass encryption, we trying to develop. Then I go more deeper into the general concept of pretty easy privacy. And then I have actually a big chapter on the technology for metadata protection. The so-called GNUnet who has heard about GNUnet before. Okay, just a few. So I hope I have enough time to go into more detail, but at least you get an idea of what it's going to, what it's about. And then yeah, the usual summary and Q and A, but maybe we make the Q and A a bit shorter. Let's see how far we come because we also have a stall in the project area when you enter the room on the left side. We are like the second table around the corner. All right, so I start with the Declaration of Human Rights, Article 12. No one shall be subjected to arbitrary interference with this privacy, family, home or correspondence, nor to attacks upon this honor and reputation. Everyone has the right to the protection of the law against such interference or attacks. So I highlight two points here, arbitrary interference and the right to protection. Just give this little quote. I don't know, I guess most of you have heard about it. This is just published a day before yesterday or three days before that the court has confirmed that the searches and seizures were illegal. So this was an arbitrary interference which was not protected by the law, but done by the law. So and there is another quote, I don't want to live in a world where everything that I say, everything I do, everyone I talk to, every expression or creativity or love or friendship is recorded, which is from Edward Snowden who has shown us that actually the word is like this. So everything I talk, like everyone I talk to online is recorded. So this is one of those thousands of thousands of slides he was publishing. So we have the service providers here and the list of stuff which you can get including special requests so you get literally everything. So yes, we scan. We should actually get an update on this if someone is a designer. But it's not only the governments who are trying to spy on us. There's also this problem where I really like this little picture of those two pigs saying that they don't have to pay for the barn and that even the food is for free, which means that if you're not paying for it, you're not the customer, you're the product being sold. So the general problem is that online communication is visible like a postcard and that this world has mass surveillance. And what we're trying to do as a solution is mass encryption and then mass anonymization. But how we're going to do this, we're trying to do software which does what the user would want to do. So instead of writing how to guides, we write user expectations into software and protocols to automatize all steps a user would need to carry out. Which is key management, key discovery, private key handling and lots of more things. So how we're doing this, we wrote an RFC or an so-called internet draft which is the pre RFC, which is online and ready for discussions together with the ISOC Switzerland. It's been written and this is the abstract. I just read out loud the underlying stuff. Building on already available security formats and mass transports, pretty easy privacy describes protocols to automatize operations, key management, key discovery, private key handling that have been seen to be the barriers to deployment of end to end secure interpersonal messaging. So this is what PEP does. So we're automatizing these things which usually the user should do but which you guys who taught others also most probably figured which is pretty difficult for the users. By the way, what I found out in the last couple of years is also that it turns out to be very difficult for users nowadays to actually use a mail client. So if you're not keen on teaching someone GPG but still think people should get to know more about these stuff, then tell them about email clients. Because this is turning out to be more and more of a problem because people only use web mail and they don't even know the concept of an email program. Call it app then they understand what it means. So this is what PEP does and what does the user do? The user should only do messages. So this is how it works if you have two PEP users but also one can be a normal GPG user but on the picture we have two PEP users so they install PEP. Then one person, this is Bob writing to Alice, writing the first email which is unencrypted like a postcard. But this email already has a key attached. So in that step the key gets generated. The user doesn't even get to know about it. The key gets attached, Alice writes back which is already encrypted. So now those two guys can talk encrypted to each other and if Alice is a normal GPG user all she needs to do is to attach her key as an attachment. If you send a PEP user, oh here's my key, this is the URL, then the PEP user is like okay what are you talking about? But just attach the key, PEP will see this is a key and reply encrypted. So this means you're in the encrypted mode. But we do trust on first use. You see the first key gets unencrypted to the other person. So ideally you also check the fingerprints where we have this concept of trust words where we translate the hexadecimal fingerprints into words. So you call each other, say the words, you make the handshake and now you're encrypted and verified. And the only thing as the user is that you see those colors. So here your email somehow turns yellow, depends on the application. There's some yellow spot and here you are in the green mode. So ideally everyone should be in the green mode. This is another diagram showing this. So first email unencrypted and key exchange, second email is already encrypted. Now you do the verification and then you're in the secure and trusted mode. All right, so what's PEP, a software for various platforms to easily use existing crypto tools. It's designed to encrypt all digital written communication with the starting point of email. I'll explain that later. It encrypts automatically with whatever most privacy enhancing crypto standard available, hence privacy by default. We're going with the opportunistic approach here. So if you have seen the signal and these guys, they started to have this opportunistic approach of having as much as crypto as possible, right? And if not, then not. And all end user software must be hassle free and zero touch. That's why we also don't have a password on the GPG key, for example. What's PEP not, that's also pretty important because we're not yet another crypto tool with a closed user base or something. We're using existing crypto standards. So we're compatible with everything that exists out there. I mean, not everything, but everything that's like widely used. We're not a centralized platform provider. We're not implementing any own crypto. We're not replacing any existing crypto tool. And we're not just an email encryption tool. This is just the beginning. Who are we? This is also very important in these projects. We see ourselves as cipher punks. We want to roll out mass encryption to optimize the costs of mass surveillance. We want to make the use of crypto pretty easy, not only for the users, but also the developer can plug it into their apps and the user can just use it by default. What cipher punks? This is quotes from the cipher punk manifesto. Cipher punks are actively engaged in making the network safer, advocate widespread use of strong cryptography as a route to social and political change. And they aim to achieve privacy and security through proactive use of cryptography. And he's also very nice quote, which I really like because of this whole privacy. Oh, I don't have anything to hide thing. Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know. But a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world. And then last quote, we cannot expect governments, corporations or other large faceless organizations to grant us privacy. We must defend our own privacy if we expect to have any at all. We know that someone has to write software to defend privacy and we're going to write it. So this is where we're coming from. We are actually most of us are a group of people who've done like all these crypto parties and these things. And I, for example, wrote in 2013 the whole crypto party.in the new web page, this whole how to and whatever. And we're just at a point where we were at a point and we still are where we were just like, okay, let's stop writing how tos. Let's write software who's doing what we're trying to tell the users. To just come back to this declaration of human rights, everyone has the right to protection of the law. And this is not the case. We know that. So what we need to do, if the government doesn't help us, if the law doesn't help us, we need to take the help of the law of mathematics, like just physics. That's what we need to do all together. And this just as a really short side note, Cypher is not about cyber. Cyber is also not about internet. It's the study of control and communications. And Cypher is an alternative spelling for Cypher. And also, who's me? I studied anthropology and computer science. So I'm actually a humanist. I'm also carpenter. I'm Schreiner. My name serves as a unique addressing in internet and web. That's why I'm using it widely. If you want to know my real name, just check the board members of these associations. And if you find a female name, it's most probably mine. And this is stuff I've done, which I always like to point out. So please come and visit us in India, for example. Yeah. Now we're actually getting into the things. So I'm telling you about the architecture of PEP, which consists of the engine, adapter, and applications. I show you a quick list of repos, developing platforms, and I also add the organizational forms into the technology chapter. I explain you why once it's about time. So the general architecture is, as I said, applications, adapter, and engine. So we have this engine who knows about the crypto functionalities. We have adapters in various languages, which are then communicating with the applications. I go into more detail on that. But here's some more examples. So for Outlook, you need a com server adapter. For Android, we have this JNI adapter. For iOS, there's an Objective C adapter, and so on. So this engine drives several crypto standards on different digital channels, like message transport protocols, which is at the moment only email, like SMTP, IMAP, Exchange, blah, blah, blah. It's written in C99. It has roughly 10,000 lines of code and has regular code audits. It's not meant to be used in the application code directly, but you can just plug and play the engine as a developer, which means you don't have to maintain any crypto. The plug and play is a bit too much because our documentation is very bad. So if you want to do that, then please contact us as well. If you wonder about the documentation, please. Yeah. So you don't have to maintain any crypto. You're like, okay, what? But we have regular code audits. They're published on this URL also in the blog. Then once they happen and they're done by Section 1 by Bev, maybe some people know him. He's also been part of this crew for quite a while. This engine takes care of the messaging functions, the crypto tech services. It's like a crypto API. Makes this fully automated key management services and the trust rating. It knows about the transport protocols, like the message transport ways. And in the future, there will be this metadata protection, YNN. So this means it does the decryption and encryption, the MIME encoding and decoding, the message processing for the adapter, the key management, which is generation at the beginning and then the verification blacklisting, all these things. And also key synchronization of same account between devices. This is still in testing, but about to come out soon. This will be more or less, I think, something which I hope lots of you are going to be happy about because it is still a problem. Like you get encrypted emails and you're like, oh, sorry, I'm on the road. Please contact me on another channel too if it's important. Otherwise, I'll come back to you tomorrow or something. So this is always very annoying. So this engine gets connected through the adapters to applications. These adapters are language or environment specific interfaces between the engine API and an implication development environment like a programming language or an IDE or something. Basically the adapter is bindings. So and this is a list of adapters we have actively laying around. Not all of them are in use so far. So you're very invited to check with your own communication apps if you want to use one of those adapters. And this is how it works. The app makes calls to the adapter for the function at once like encrypt or decrypt or get the trust words or trust level or something. Then the adapter converts that into a normalized standardized form for the engine, for the messages and makes the C library call. Engine magic happens and the adapter gives the result back to the application. So it's actually pretty easy. The current implementation of PEP is that it handles open 3GP and as MIMe passively without any hassle for the user. It automatically encrypts the subject in line. There's this automatic key management. There's no key server or other centralized infrastructure because the key always gets attached to every email. Those fingerprints get translated into trust words. There's an opt in passphrase for keys. So by default there's no passphrase because the users will stop using it if it starts hassling. And the header gets encrypted and obfuscated and this sync protocol is in the making to get the keys synced over various devices. I have more details on that. So this is the applications which we have at the moment. We have Android, Thunderbird with any mail and PEP for iOS is a very early alpha which I think at the moment is only like a pregroup in testing. But if you're interested, we can give you access as well. This is the list of repositories. You find them all online on various places because we are like a widespread organization. And this is a better overview here. You also find everything on PEP software and on PEP foundation slash PEP software. So here's engine and Raptor, Android, iOS, Outlook and any mail, everything on a different place. And this is development platforms. So basically everything you can think about. And now the organizational forms. So we have a company, a foundation and a cooperative that sign a genocent shaft. The company is selling applications and services and sits in Luxembourg. The foundation is supporting free software and very important, the code belongs to the foundation. So the foundation is actually the heart of this. So the idea is that the company can also get investors money and stuff like that. And then if the company breaks or something fails, the code stays with the foundation. So the code will always be safe. And if something with the company happens, we can still say, okay, bad luck, let's continue. And then there's this cooperative, which is where you can be a member. There's also this nice text in German from Zibli Berg, an author. So it's a cooperative of authors and other artists and lawyers and things like that. They started this to bring people together and also for corporations with others and to create web plugins. Because web, as I said before, most people are using web mail and it's pretty hard to get them into web, into mail applications. So we need to get web plugins, but this is not anything we can do with the company because no investor will give money for free web plugins, unfortunately. Then we have a bunch of more websites, where you get the software as binary and code, the PAP.community with the usual stuff and the PAP.news, which is not there yet, but will be giving an overview of everything. So yeah, and also what's always important with these projects, also where does the money come from? So as I already said, the company gets the usual investor stuff. It's like a startup. It's in Luxembourg because the main guy, we have two founders. One is Swiss, one is Luxembourg. So it also gets funding from the government of Luxembourg, the usual startup tech thing. And the foundation is in Switzerland because Switzerland and foundations fit together nicely. And as I said, most of the people are Swiss. And yeah, so the foundation has all the documents online where you can see on the money. It's mainly private donations in the foundation. Yeah, then the general concept. This is six chapters plus a summary. I just go into directly. This we already seen, PAP does what the user would want to do. So the idea is to take away the crypto needs from the users for a few. Like we have seen this happening with HTTPS. Like before and after Snowden, there was a huge increase of the usage of HTTPS in the web. And a normal user doesn't even see the difference. They just see any green lock or something and they're like, okay, I don't know what that means and it doesn't matter. So this is where we want to go. So they just see emails which are somehow green and they don't even care what's the difference. But ideally, like we have it now with the web that most percentage of the web, okay, I don't know. I haven't seen any numbers on this, but I feel like most percentage of the web is mean by reachable on HTTPS. We would like to have most people being reachable on encrypted channels. And the easy part, pep is easy to install, easy to understand, easy to use. There's no hassle, no training needed. And as already mentioned, also easy for app developers. This is one sub part of the easy. I already explained those trust words. So there's battery or stable instead of EC 5539 and so on. And this is, by the way, a piece we cannot put into software. So to establish trust, you have to look into someone's eyes, basically, even if it's on the phone, right? But that's that we cannot handle on software. Then the key sync also is a part of making it easy. So there are device groups so that you can sync your key on multiple devices. I guess it's easier to explain on this one. So we have a pep user having pep on one device, installing pep on the second device. Now those devices, like the new device, pinks on the group and says, okay, hi, I want to be part of the group. The fingerprints get checked, the handshake gets done, and then all devices exchange their single keys and create a group key which they all agree on. Which means you can not only sync keys but also contacts and calendar. And this also means that you're using finally contacts and calendar in a backup which is not in the cloud, which is others, people's computers, but your own computers. So if you're going on a whatever, a big travel and you take your laptop and your cell phone along, you can just leave one mobile phone at home, leave it plugged with a Wi-Fi, get it synced all the time, and if you happen to get robbed, everything is lost, and you still have this device at home which has all the backups. Then we are trying to do everything right without any compromise. So the whole thing is end to end, peer to peer. There's no centralized infrastructure or any kind of closed services. Because yeah, we don't want to create yet another crypto app where you have to convince all your friends to be part. Then oops, this is German, sorry. So PEP is free software. It's GPL3. It has actually independent external code audits like the Cypherpunks told us 30 years back. And we are compatible with crypto technologies, message transports, platforms and languages. This is more detailed. So the bolded ones are the ones we are already compatible. Asmime passive, if a PEP user gets an asmime message, they can reply on it. But PEP will never start using asmime, I guess you know why. Then we have OTR, OMEMO, Axolotl, that's the stuff we would like to see next earlier. But then if the scene changes like OMEMO two years back, we wouldn't have had OMEMO on that list. But now it's turned out to be really great. So we're trying to support that as well. Same with the transport protocols. So SMTP, IMA, POP3 exchange already supported. And next we would like to see XMPP and also the non-open standards. I guess that's pretty important. Like Twitter DMs or Facebook chats or whatnot. But also stuff like SMS. Then the metadata protection already mentioned that this should be the next thing. If you have people to encrypt, content encryption is not everything. I guess in this audience I don't need to tell too much about it, but the metadata is still there. So what we do right now is we already encrypt the subject inline and we obfuscate and encrypt the rest of the header as much as possible. Like the whole email inclusive header gets wrapped again. So it gets another header which is then obfuscated and gives another information like the one which would originally be there. The problem with the internet is just that there are lots, but to name a few, the problem is that the network generally learns too much. The IP protocol leaks information like crazy, like IP header from where to and so on. We have insecure defaults and rather high complexity for the management. We have centralized components and also administrators. They might be malicious or incompetent, but even if they are nice guys, they can be a target. And these floors are misused already very heavily. We know that. So what we're trying to do is to pipe everything. Oh, this is also German. Sorry about this. I translate on the fly. We're trying to do this whole thing through GNUNET and to explain GNUNET, I try to explain it like this. So when the internet started, we were like in the 70s and 80s, we were like, oh great, I can access your computer and you can access mine. This is awesome. Nowadays, we're right. Okay, sure, I can access other computers, every website, every service I use, I access other computers, but then if you talk to non-techies, they would be what? But they can also access me. This is how I started every crypto party. If you are connected to the internet, the internet is connected to you. This is what lots of people are not aware of. And what we need to have in the far future, this is still like an ongoing project, which will take a lot of time, end to end, encryption and anonymization of all the way the data flows. And this, I go into this more detail in the next chapter. So the summaries that users don't have to think about the crypto anymore, they can just use it by default. We had this journalist writing this sentence once, it is this little hacker inside that decides on the cryptography, choosing to communicate with the message recipient. And this is where we actually want to go. Like in this audience, I guess you all know that you're sitting on your computer, you're talking to someone and then it's going more personal or more private or whatever. And then you decide what medium shift you're doing. And then you continue your conversation. And then maybe your partner says, oh, I'm about to leave the house. Do you have signal? And then you're like, oh, no, I don't have signal, but do you have OMEMO on jobber? Right? Oh, no, I only have OTR. That's not so good if you're on a mobile. And all these things, right? You know about this and you can decide yourself which is the best communication method to use right now. But this is what we cannot expect to all the people out there who are not into technology. And we should also stop to expect them to learn this. This is something which I had to learn over the years. I mean, we are, or lots of us are somewhat missionaries. Is it open source? Is it free software? Is it telling people to go on Linux or something? But we are somewhat missionaries. We are trying to convince the people that this is the better way, even if they don't know. Some people will trust you because they know you as a friend. They don't know about the technology, but they say, okay, if you are telling me, I'll do that. But this, like, small decisions on an everyday basis, we cannot expect the people to do. So this is why we are trying to have this engine who, like, in the future and sometimes knows about the different crypto technologies, knows about the different message transports and can make this decision somehow based on algorithms for the people, which doesn't mean that they are always going to be totally safe. Like I said, the opportunistic approach, as we don't want to hassle the user, worst case, it can even go like, okay, I don't find anything. I sent unencrypted, right? This can also happen. But we just need to get more crypto noise out there. All right. So then the next chapter, this GNU.NET thing, and I actually have quite some time. This is good. So GNU.NET is, you broke the internet. Let's make a GNU one. This is their tagline. So GNU.NET 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 it's really about replacing the internet as we know it. Or not replacing, but like enhancing it with a new version, right? Like I said before, the internet 2.0. It started in 2002, just already quite some time back. It's been followed in academia quite heavily. There was a full department on the university in Munich. And meanwhile, it moved to France. And I think now there's also parted Switzerland and so on. So it's a long process because it's also not something you can do just like on a weekend. To explain what it's about, I made a very hard simplified version of the internet. And this whole thing is based on a talk from Christian Grottof, it's called 45 subsystems in 45 minutes. He already said, oh, this is impossible to do it in 45 minutes. So I'm doing it in 10 now. But if you're interested, you can check it in a much wider version. So this is a very hard simplified version of the internet. You can somehow see the layers, physical layer, Ethernet, IP, TCP, DNS, and then the applications. So I start at the bottom with the physical layer. So rebuilding all the wires and fibers is not a reasonable approach. It won't lead us anywhere, which doesn't mean it's still very important to have stuff like FreeFunk, you can visit them out there that we still make our own infrastructure. But if we start like this, we'll never get ready. So instead, we simply start with what we have, which means we just use existing protocols like TCP, UDP, SNTP, HTTP, Wi-Fi, Bluetooth, whatever is there. There are lots of them. So we make unreliable out-of-order packet delivery semantics on these already existing protocols. So on this layer, the presence will be obfuscated and hiding in the network already, because if you write an email in the concept of email, let's see, but it will not show as an SMTP track in the network, but maybe as an HTTP or something. On this layer, we have this automated transport selection that decides which connection to establish and selects the best transport to use. Like for voice, you can only use transports that have low latency, right? But if you want to do a download or if you want to send a message, you can use something with a higher latency. Then in the next layer, this is called core, where GNUnet runs effectively an off-the-record link encryption between the peers, which means it multiplexes the inbound messages by type to the higher-level subsystems. It hides the connections from or to peers that do not speak the same higher-level protocols. So it's somewhat like the Ethernet layer for GNUnet and simply encrypts that one. Like today, we don't have any encryption there. You can fake and spoof IP addresses as you like. You can listen to communications and so on. So this is all deleted in this layer already. Then the next layer is about decentralized routing. It's decided for an RF5n, so basically it's a routing algorithm that's decentralized. It includes a distributed hash table, which is a randomized variant of Caddemlia, and that works still effectively also in very small networks. Now we come to the heart of the project, Cadet, the transport protocol. This is similar to SCTP, the stream control transmission protocol, and serves end-to-end encryption on this layer. So on top of Cadet, there are additional services created that provide more applications-specific functions. So there's something in development that's called Axolotl that also provides this SCTP-like interface. And SCTP is something like TCP and UDP combined. And Axolotl is this protocol from Signal, and they created something like Axolotl, which protects the metadata. And then they also created something called Lake, which is a further development of Pond. Who knows Pond? Okay. So if you haven't heard about it, then maybe it's like the whole, yeah, I actually have another thing on that because it's happening often. So if you know all, okay, what's happening, what I can tell is by all science and mathematics we know today, all the metadata will be gone that way. And check out the longer talk if you're interested on that. So let's go to another layer. This is the GNU name system. It's very easy because it's just a name system that is secure and decentralized. It provides an alternative public key infrastructure and replaces therefore DNS and X509. And it also does not rely on central root zones or any authorities. It's interoperable with DNS and it achieves query and response privacy. And now the application layer. So application layer is most important in the internet, always been file sharing. This is actually how GNUnet started. It was just like in 2002, the first white paper was only about file sharing. So this file sharing protocol, you can use anonymous or non-animous. And then what we definitely need is to serve all those people who now they say, oh, I go into the internet, what they actually mean is the web. What they mostly mean is one website. And we need to have somewhat social networking things. So some people develop SecoShare for this purpose. Then there is an app called Conversation. Not to mix up with conversations. This is a Java client. Conversation is a voice over IP protocol that works. You have decentralized voice. Then we have an IPv6 to IPv4 translator that already works. And then PEP for messaging. And there is GNUtala for payments. And if you like, you can also do apps for GNUnet yourself. So back to the general concept of GNUnet. This is quotes from their website. It wants to protect the privacy of its users and guard itself against attacks or abuse, become a widely used, reliable, open, non-discriminating, egalitarian, unfettered, and censorship-resistant system of free information exchange. Also wants to serve as a development platform for the next generation of decentralized internet protocols. So please go and check it out. This GNUnet is, as I mentioned, there for 15 years already. It's just gotten a pre-release in June this year, which is the first release since 2014. So if you want to check it out, please do not use the release from 2014 and not the packages you get in your distribution, maybe. But please clone the GIT or take the release from June. And then you can still follow the instructions on the website from that release in 2014. They will fit more or less. If you struggle, you get pretty good help in GNUnet on FreeNode and various mailing lists, which you can use for that. And then please report the bugs, because you will find a lot on GNUnet.org slash bugs. So this project is at the moment at a state where actually now, since just a couple of months, all these protocols I was showing are now in a state that they work. And so this is now, for the first time, a state where we can say, OK, please geeks and nerds and techies all over, go install it, test it, and tell us what's wrong, because there's going to be lots of things wrong. This is an academic project, so it's lots of academic code. And some of it is very old, so we also need to find out which parts have to be rewritten, maybe. And yeah, there's also a GNUnet Java. So GNUnet is generally written in C, but a GNUnet Java exists. And this is more or less just a start for an APE for extensions in Java, which I find pretty important, because this whole thing, it's going to take lots of years until we actually can tell our non-geek friends to upgrade to the internet 2.0. But at that point, I'm afraid, people won't be using any laptops anymore. They won't be using any proper operating systems anymore. But everything's going to be on those mobile systems, so it's actually pretty important, I believe, to have everything somehow available on a Java platform as well. Yeah, that's the summary we had this before. So this is the plan. This is what we're trying to do. It started in 2014 with one person, like a hardcore techie who actually developed the idea. Since 2016, the first couple of developers were employed and starting to actually write software. So on this mass encryption part, we are as far as I showed before, like we have email programs who do PTP without hassle, and we're moving slowly forward. And then the mass anonymization part is, yeah, we need to see the progress on GNUnet, and then we can continue to solve, to rescue the world like that, and to get back to our human rights, as I said before, the rights to protection of the law of mathematics. That's the only thing that's going to help us. And just as a last sentence regarding the law of mathematics, you might have heard that the law of mathematics doesn't apply in Australia. The Australian minister Turnbull said the laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia. So let's show him that this is not true. And here I stop, and I'm there for your questions. Yeah. I repeat the question then. Yeah. I'm here to talk about the first message that you sent to someone you already know, and I think it was at the very beginning, right? So the question was how is the first email key exchange handshake done? So let's use this one because there we have everything. So this is Alison Bob, right? So the first email is actually just unencrypted. So I have two GPG users, and let's say this one is a PEP user, and this is a fresh installment. So the PEP user installed PEP, so the key got generated in the background, and now the user Alice just sends a very normal message, like just a normal email, where the key gets automatically attached, which she doesn't even know about it. So now this first message is a postcard. So this first message is unencrypted. All I need to know is the email address of that person. So I send that email, key is attached, the second person, let's say is also PEP user or GPG user, but the person or the program realizes, oh, this is a message where there is a key attached. Oh, so I import that key and I reply encrypted. So this means we have trust on first use. So you get the key on an untrusted email, actually. Only, yeah, but only by these color indicators. So this is like we have this gray, yellow, and green color indicator and a red one, which makes alarm if whatever the key doesn't fit anymore or something. So the user is not totally aware about it because this email will just look like any other email. Only the second email will be looking different, where there is, depends on the application. So for example, on Android, you have then a bar, the upper bar, which is usually gray, and then it's yellow. And then it gets green at this point. So and in an outlook, I think there is a shield button somewhere where you can also turn off the protection. And this will be gray and like striked out in the first email. In the second email, it will be yellow and maybe showing something that you click on it, because if you click on it, then you get into the verifying fingerprints mode. And then it gets green with the whatever smiling face. So we are also trying not to work with the keys or locks or something to really get this totally out of the user's perspective. Yeah. Yeah. So the question was if I install a new system, how do I get my private key onto the new system? And second part of the question, how to, where are the keys stored? Are they safely stored? So first part is the key gets just normally stored in GPG. So when you are like a Windows user installing pep, the key gets generated automatically. I missed out to mention that actually GPG gets installed automatically. And then so I had this just recently on a very remote spot where we haven't had proper internet. So then the install visit will be very slow because it has to download the whole GPG system first and install that to actually create the key. But then the key will be stored just normal in your GPG settings like on every system. So you can grab it there and get it onto your new system. So yeah, if you have a pep installation, it sure checks if it can find any key. So if it finds a key, it doesn't generate a key, but takes this one. No, it actually does not yet, but it should. So at the moment it doesn't, it just can generate the key. And if you already have an existing key, you need to import it afterwards and kind of override it. But yeah, this is like ideally a key gets detected, but I think that's not there yet. And the second part of the storage, this is a good question because I also haven't mentioned that. So what we need or what we do in this project is that we trust the hardware, which I know we shouldn't do, but I mean, we cannot solve everything, right? So we just at one point said, okay, we assume that the hardware is safe. We need to do that. So we write in all the documentations, like all the user manuals, everything we have, we always write, do folder encryption, take care for your devices, also physical security, everything. But we are also quite aware that especially with this concept of mass encryption, where you want to go to the masses and not to the techies, we'll be having lots of zombie windows systems, which will be doing whatever, but not being safe to store at key. But that's at the end also not the point. So if a person already has such an unsafe system, it also doesn't matter if the GPG key is unsafe, but it matters that the communication that is flying around in the internet is encrypted only at the end, only for the sake of the ones who are protected that way even more like the usual, let's have more crypto noise so that those people who use encryption don't stand out anymore. So but then it's up to you to take care. So it's just stored at the normal spot. And if your normal system is safe, then the key is safe. Is your system is not safe? Then the key is not safe. Yeah. Yeah, that's like either also on the system. So it's only outlined at the moment. So if a person uses map mail on the same device all the time, we can give the option of storing the key on the system. But if you have this webmail, you should also have the option that people actually can use it on different devices. So then it's like the mail-valop approach that you have the key on a stake, which I had actually when I was doing those crypto parties in India, I had this quite often that people haven't had their own device and that we had to use this web plug-in which I already said, okay, everything that has to do with the web is not going to be secure, but okay, there's no other other way to go. So then keep your stick secure. So yeah, then there were two questions. Yeah. So there is, so we just had this discussion on the style yesterday. So we both weren't sure, so I should repeat the question. So how is the scene if you have CC people or BCC people? So if you four here in the first row start now an email, you just sent an email to those three, you attach all their public keys and write an encrypted email to all three, but then those three don't know each other. So they won't be having their keys. So now we weren't sure we need to ask the devs. I actually believe that Pep will be seeing all three keys or all four keys if your key is attached as well. Import then and reply encrypted. My colleague meant that most probably only the key from the person will be seen as the one that gets important, which I don't think makes sense because the software doesn't know who's actually the person except for the email address, but it sees, okay, there is attachments point ASC. So I import them and then once they're imported in the reply, like you make reply all, it'll be encrypted with BCC. It's not possible. I mean, it is possible you can attach all the keys from the people you have in BCC, but then it doesn't make sense, right? There's another approach, AutoCrypt, which I also, it's good to mention actually, it's autocrypt.org, I think. It's a similar approach. They also trying to make encryption more automatic. It's more an approach for the sophisticated users. So what they trying to do is to add the key IDs into the headers. So this is something you could do with a BCC list that you add those into the headers and then only very sophisticated users who knows about the headers can check, okay, who got this email. But generally, if you write BCC to lots of people, you can write them each one of them unencrypted. But then, okay, actually, that's the point, right? Because they cannot reply any, anyhow. Because if they click on reply all, it will be only reply to you. So then, yeah, that works. Really, that's a weird bug. Okay. Yeah, yeah, definitely, definitely. But I don't have those. I mean, I have lots of encrypted email stuff and there are people see seed and then if I do reply all, maybe you can come over to the stall and we talk about this happening more detail. Yeah. Was it an Apple user? Okay. No, no, no, nothing against Apple or maybe, but I just had, I made an experience once. Yeah. Okay. Just why I was asking, I made an experience once, experiment once. It's like two years back or so where I created a GPG key without an email address attached to see how other clients are handling this. And Apple Mail, finally, was also saying, oh my God, I don't know what to do. So I take the own key. So I got encrypted emails from someone else using Apple Mail with their key encrypted, not with mine, so I couldn't read them. That's why I thought maybe if it was an Apple user, it was the same bug. Okay. Then there was a question down there. How is key lifetime handled? Yeah. Um, that's, uh, not really, I don't know exactly, but I think it expires automatically and gets redone. I know that if you have like, if you have a device that's compromised and you want to replace your key, um, the only solution is to broadcast your key. So we've already been thinking about that that in that case you could click on something like, okay, please broadcast my key to everyone I've been talking to encrypted in the last this much time spam, spam, or to everyone in my address book, which I had GPG communication with. Um, but generally this is a problem because people like, as it all happens automatically, you cannot start sending telling people, oh, I have a new key because they wouldn't even know what is the key, but you can send them a broadcast message of, um, which ideally doesn't even then is, isn't even visible of this is my new key. It gets imported by pep and in the future, just the new key will be used. But then if you, um, make the broadcast only to the ones I had contact with the last two weeks, but then someone writes you who you haven't had contact, then they will be using the own keys, so old key. So here we definitely have an unsolved problem of redistributing new keys, but the lives, if time it's actually good question, I think it gets re done once in a while cycle like, but I'm not sure about this. You shouldn't need to ask the others. Okay. Any more question? That's great because it's like perfectly in time 15. Thank you. Thank you.
we're trying to make it easy so that on the one into software and protocols to automatize all security formats and mass transports, pretty easy platforms to easily use existing crypto tools. It's designed to encrypt all digital written enhancing crypto standard available, hence privacy by default. We're going with the standards. So we're compatible with everything to optimize the costs of mass surveillance. We developing platforms, and I also add the message transport protocols, which is at the processing for the adapter, the key management, also key synchronization of same account between come out soon. This will be more or less, I on that. So this is the applications which we seen, PAP does what the user would want to do. So the idea is to take away the crypto needs from those devices, like the new device, pinks on the technologies, message transports, platforms and someone and then it's going more personal or more and then the applications. So I start at the on these already existing protocols. So on this You can listen to communications and so on. So very easy because it's just a name system that is website. It wants to protect the privacy of its to the masses and not to the techies, we'll be their public keys and write an encrypted email to encryption more automatic. It's more an approach