 So, hi. I'm Vincent. I'm here to talk about auto-crypt for a bit. It's a lightning talk, so I'm just going to give a short overview. I can talk about this stuff for many, many hours, and I'm trying to cram the most interesting parts into this presentation. So, let's start. A bit about myself. As I said, I'm Vincent. I got into the OpenPGP community working on Open Keychain, which is OpenPGP for Android. I worked on this during 2014-15, something like that, as a GSWAC student, as well, and then kind of stuck with it. In 2016, I acquired some funding from the OpenTech Fund to get OpenPGP support into K9 Mail, because that was a bit of a bigger project than I wanted to do in my free time, because it requires some rewrites. And during this time, working on K9 Mail, I found that a single client can try as hard as it wants to really be polished and offer end-to-end email encryption. It can try, but it can never succeed on its own, because there are just some parts missing in the ecosystem. There are conventions missing. There is a concept missing for key management for some consistency in the UI. And from this, talking to other people at different conferences, we got together and said, okay, let's try and do that. Let's build a specification on top of established OpenPGP that makes email encryption workable. At this point, a quick shout-out to some of the people that were involved with this, especially Holger Kreke, Daniel Kahn-Gilmore, Azul was there from the start, Björn Petersen, Patrik Wunschig was involved from Enig Mail. Tons of people involved. This is not all mine. I'm very happy that it's a community effort. So the specification, just a quick overview. What are our goals in terms of some requirements engineering? Our first and primary goal is to make it easy to encrypt email. So encrypting email is a use case that people do ask for, and people still do send emails in the business context all the time, but encryptions are not really there. And we said, okay, we just want to encrypt email. Let's focus on that. Let's not do any other specialized use cases like signing. Let's try and not confront the user at all with key management choices and automate all of that away. And the how-to, the vision of how can I encrypt email with my client should be just install an auto-crypt capable email client and you're good. That should be the training that is required to actually use the software. We're not quite there yet, but that's the vision. Second thing is don't rely on any infrastructure. As soon as you depend on infrastructure, there's just many, many moving parts. So we said, okay, we don't want to use key servers. We don't want to rely on any support from the email provider to be able to encrypt. And any other outside influence, we just want it to work if the email clients can do it. If we're talking end-to-end, we have to have email clients because those are end points. But, yeah. So, and the fourth thing is it should work on multiple devices because the reality is people do use multiple devices in their daily email workflows if we have anything in our design that needs to keep state, for example, for a longer time and synchronize that between different mail clients, things will get hard. So we try to keep things as simple and separate as possible and avoid the requirement of synchronization between different email clients from the same user. Right. Almost as important as the goals that we have are the non-goals. We were very strict in descoping stuff that we didn't think fit in, especially we say for a first iteration, we disregard active attackers. Our slogan is a bit that we want to raise the floor and not the ceiling of encrypted email. We don't want to make it hard for a very strong attacker or we don't want to make it impossible for a very strong attacker to man in the middle people and get to the content of encrypted messages. We want to make it hard for a passive eavesdropper to just read the message that is sent and so we're competing with plain text and not with encrypted mail as it was. We stick to a very simple trust model for that. Basically it's just tofu in most cases and we don't want to impose encryption by default because the ecosystem is not quite there yet. If you do encrypt an email then you impose costs on yourself as well as the recipient because it's hard to search through encrypted email, it's hard to archive it, it's just hard to handle in general. So what we want is to be able to encrypt email if we want to but not impose too much on the user. So let's just establish a baseline of what we envision the UI to look like in the email client. That's it. We want pretty much nothing else. If the mail client is capable of encrypting a message it should be this checkbox and the user can check it. In some circumstances it will be checked by default but that's not the baseline of where we want to start. Having said that, just quickly about how we, about the governance of the spec and how we work on it, it's a community effort. There's a bunch of projects involved. There is ending mail, delta chat, mail pile, mail fans, people with their Sikoya, Leap Next Leap, different people. We try to get them together often and we still try to keep our workflows open. Almost everything that we did, the document that we wrote was written by GitHub pull requests. I think we have 250 of them at this point. And even when we met as prints, which we did a bunch of times, we always tried to keep things approachable and if somebody wanted to give us input we tried to work with that. Yeah. We work on the spec and implementation side by side. Going back to the minimum implementation complexity thing, we sometimes got back to the drawing board after trying to implement something and said, okay, no, this was too hard. I couldn't do it in two weeks so apparently it's too hard. Let's make it simpler than that. Cool. So how do we do this? What do we actually do what's in spec? So the primary thing that we do is we exchange public keys in band with emails by attaching, not attaching, by putting headers in the, an autocrat header in the metadata of the email. In every email you send from an autocrat enabled email client, there is an autocrat header that has the key data of the key that can be used to encrypt to this email address and the specific email address that this key data is valid for. This is important because of remailers so we don't accidentally associate keys with addresses from remailers. It's a simple attribute-based format and the typical size right now is about two kilobytes, which is a usual RSA 3072 key with one sub key that's the format that we said, okay this is the most common denominator that is supported in every implementation. At this point we felt comfortable enough to move to ECC but when we worked on this a couple years back RSA was still the only thing that you could say okay this actually works in most implementations. Yeah, we have some forward and backward compatibility in there by having optional and critical attributes but those are not super important, not used a lot. So when these emails are received by an email client it just does some basic bookkeeping remembering what was the last email that I saw from a person and what was the autocrat like in there and from that we have a recommendation algorithm that for a given set of email addresses of recipients it will calculate what is the status of encryption for this recipient and that can either be unavailable which is well we don't have all the keys and that's the only case in which that happens. It can be available which means I have the keys if the user chooses to encrypt you can. We have discouraged which happens if we have the client has reason to believe that the keys are stale for example if we have received messages that didn't include auto-crypt headers and some time has passed since those messages then it will be discouraged and it will give the user a warning like okay you can encrypt but be aware that the recipient might not be able to read this email because maybe he didn't maybe he uninstalled the auto-crypt capable email client and there is encrypt which says do encrypt this mail by default but this is already kind of the expert mode you can do it if you want to you can consensually ask others to encrypt messages to you by default but this only works if it was set in the metadata in the auto-crypt header as an optional attribute that it's okay to do so with a key. So one more use case that everyone has probably experienced who has tried to work with encrypted email in the past is if you send a message to multiple people or you receive a message that was addressed to multiple people then it was encrypted to five and you want to reply and you're missing the keys of two of those people and then you can't encrypt and it's super annoying. If you know a lot about all of these formats you can try and get the long key IDs from the encrypted message and download those if they are on the key servers but it's a hassle and generally my experience is encrypted email to five people you're extremely likely to get plain text messages back just because people don't have the keys. So what we do is we have an auto-crypt gossip header and this auto-crypt gossip header is allowed to convey the keys of others in the encrypted payload so when I send a message encrypted to four people I will just include the keys of all those four people and then the reply all works. We make sure that way or we try to make sure this way that if the user hits reply all to an encrypted message the message can still be encrypted because it's important to keep one thread once one message is encrypted to try and keep it encrypted otherwise we leak the plain text in the quotes very easily. Right so just quickly about where we are we started this at the end of this in December 2016 we released the first version of our spec the level one spec in 2017 in December and since then a bit more than a year has passed and I'm happy to say that auto-crypt headers do come up in the wild. I have mostly stopped doing manual key management at all and in my open key chain I see a bunch of keys just popping up from auto-crypt headers that people send which probably are in the majority enigma users because enigma supports this since I think March of last year something like that. Also K9Mail supports it where I worked on and there's delta chat which is messaging over email thing that got involved with us and they also have just working end-to-end encrypted there's a bunch of other more experimental or development branches in projects that work with auto-crypt there is a mail pile, DKG is working on a not much thing, Balsa recently the Balsa email client recently announced that they had a branch and they're testing it and if the tests go well they will merge it. There is MUA-crypt which is a Python implementation by Holger that works as a proxy thing and a bunch of other projects that are at least considering and I'm hoping that as the rate of auto-crypt headers that people just see in emails increases that also the email client implementers will consider implementing it because otherwise they're just missing out on all the nice public keys that they can get. Right and that's it. Thank you for your time. We have some one minute for questions. Thank you very much. So I think we have time for one quick question if someone has a burning question that you should want the whole audience to hear. Yes. So why do you think this is sufficient protection if you decide to ignore Active Attacker? So it's very clearly a weaker secure threat model than traditional encrypted email has and the reason that we went for that is as we said we want to raise the floor not the ceiling. We can build on that and add better trust models after we have some traction with users and after public keys are just out there and there is established workflows that are actually at least a bit consistent between email clients. But a strong argument for me is that if you're in any way at risk, if you actually have high security requirements, probably don't use email. It leaks tons of metadata. It's relatively easy to capture because there's a bunch of hops involved. You can't even be sure that transport encryption is enabled between the email hops at this point. So high security applications based on email are not really what we're going for. But I would be super happy if I can just hit a button and invoices that I sent to some customer are encrypted then. That would be super nice if that just works. And for that model we don't need to have super strong protection. But one of the things that we are planning to do in the next iteration of this is to have some kind of relatively simple but verification mechanism. Okay, can I ask for a warm applause for Vincent? Thank you very much.