 It's nice to see people because this is not a project that has a community yet. And that's why I'm here, hoping that people will be interested and want to work with me. As she said, my name is Bjarni. This project is a spin-off from my work on MailPile, which was supposed to be a secure email client. And we've had some ups and downs there. Project's not dead, but there's not much to use at the moment. Done a few other things, been around for a while. This is a joke, but you have to be as old as me to get it. So I want to start with a funny story about MailPile. So MailPile was an email client. And we wanted to focus on privacy from the very start. We wanted to write an application that took really good care of people's data and information. And the obvious tool for that is encryption. So we wanted to download all of your email from whatever providers were handling it for you, store it locally, encrypt the storage, use Tor, use whatever tools were applicable to maintain privacy. And we also took usability very seriously. We had people do tests. We walked through the setup of the app. And when you're doing encryption locally, you always have to have some sort of key. And so one of the first things that people had to do in the setup phase, so they were installing this brand new app, and it asked them to choose a passphrase. And because email is super important, and this is really sensitive data, we encouraged them to choose a really, really long, strong passphrase. Four or five words, we even had a little generator that would suggest passphrases for people. And people did. They chose a passphrase, and they typed it in once, and they typed it in again. And then they went and used the app a bit, and then they went back to log in and had forgotten their passphrase. And this happened the majority of the time. Hello, everybody. Welcome. So most people that went through this particular usability test forgot the passphrase that they had just chosen within about a minute or two. It was amazing. There's a little happy ending there, is that there was something that came out of these tests. And what came out of it was a bug. So the application, the setup flow, you type in your passphrase, and it's like, OK, now we can encrypt everything, lock it down. And it booted the user out. It's like, OK, the session is now invalid. So now they have to log in again. And it's like, eh, I just typed in my passphrase twice. You want me to type it in again? And that worked. Suddenly people stopped forgetting their passphrase. So usability testing is great. And software design matters. I'm already into this. It's hard to remember things. Repetition helps. But it took me a really long time to reach this final insight that I've got on the slide. And this is a problem that is common to so many of the tools that we're using. We're asking our users, now speaking of we, the developers of these tools and the advocates of these tools, asking our users to make decisions about security way before they even know what the app is for. Like they haven't used it. They have no experience. And it has no information and it has no data. There's nothing of value there. Like these bitcoins, they're worthless. It doesn't matter. It's OK if I forget the passphrase. Or it's OK if I choose an insecure one. And then we don't revisit that. So we ask people to make really important decisions when they have absolutely no ability to do so. So we're setting people up to fail right there. And this brings me to how the other guys deal with this stuff. There's always a way to undo stuff if you're in the cloud. If you've forgotten your passphrase or lost your tokens, whatever, there's usually a way to reset and regain access. So for the general public and for the average person who is forgetful, the availability and the reliability of putting your data in the cloud is so much greater than encrypting it and storing it locally. There's just failure modes that they've fixed and we don't have solutions for. Google, Microsoft, all these big guys, even little guys, I think WordPress has a really nice password reset flow built into it. Every single web app does. But when you enter the world of encryption, we're making important information and we're encrypting it, we don't have that. If you forget your passphrase to your PGP key, you create a new key. And you probably don't know how to publish that new key in a way that other people will find it. It's a bit of a nightmare. Same for hard drive encryption, the Bitcoin wallet stories, everyone's heard those a million times. Some of us like to laugh, some of us are really sad. But I think there's this really interesting duality here when we compare cloud-based storage solutions, having other people hold our data with doing it ourselves using strong crypto. And that the pros and the cons are the same thing. We consider it from a privacy point of view, we consider it a huge problem that these big corporations have our information until we need access to it again. And then suddenly that's a huge feature. It's a benefit that there's this really nice person who can give us access to our data again when we forgot our stuff. And then we go over to the crypto side. And we consider it to be a feature and a benefit that without the keys, nobody has access. Math protects our data. The structure of the universe protects our data. It's wonderful until we lose the key. And then math protects our data, structure of the universe says no, and our data is gone. So I'm not saying this. I'm not asking crypto to be less secure. But I would like some form of password reset that normal users that do not have extreme threat models can use and trust and rely on. And then we can deploy crypto in more places. So I started working on this and thinking, how do we solve this? And these are sort of the building blocks that I was working with. The first one, Shamir's secret sharing, how many people in here have heard of that algorithm? About half of you. It's pretty good. It's a really interesting algorithm. It lets you take basically a number. And you can ask it to generate five other numbers. And if you have three of them, you can reassemble the first one. Keys are just numbers. Keys are big numbers. And these parameters are tunable. You can say, I want all five to be found. Or I want just one. So you can have one of five, or you can have four of five, or you can have one of 10. So you can just pick and choose how you want to use this algorithm. So it's very flexible. The other thing I wanted to build on is I want to build on the cloud accounts that people already have. They have these things where there is an established flow for identifying and authenticating users. I just want to piggyback on top of that. And servers and storage are really cheap. So we have a lot of things that we can build on and use. The design goals that I had, I want to solve this problem. I want us to be able to recover a lost encryption key. And although the title of the talk is passwords, those boil down to the same thing. Because usually a password is converted into a key using a hashing function or something like that. There is ultimately a key that protects access to your stuff. And there can be chains of them. There can be a key that encrypts another key that encrypts another key. And we can step in at some point and say, OK, this key, we're going to make this key recoverable. And the use case is for this. It's not just about forgetting things. Maybe you lost something. Maybe you were using a key card or a hardware token or something, and you've lost it. Or it got broken. Someone ran over it. Or there's the use case where you are dead. And you would like to have a way for your family or your friends to gain access to your digital legacy, really. So there are interesting use cases, important use cases. It needs to be secure enough. I mean, if we're going to remove all of the encryption, then why bother? It needs to be something where people can tune it for their needs and their threats. So that's one of the goals. Has to be user-friendly, so people can use it and not fail. And it has to be developer-friendly, because I can invent this system and be really proud of it. But if nobody builds it into their software, then this is all a wasted effort. So I want to reach out to any developers. If there are developers in the room, come talk to me. And finally, because there is a server component, and I would like it to be not just me running the server. I would like a community of servers. I would like you to be able to take fragments of your key and put them here and there and there and trust different people. We need a community of sysadmins, and so the software needs to be accessible for them and something that they're willing to run and manage. So those are the goals. Here is a really dense one-slide summary of how Pascal works. This is the core of the thing. So as I said earlier, usually you have a key that unlocks your information. What I want to do is I want to take that key and I want to encrypt it with another key. So I generate a throwaway key that is only used to encrypt this really important secret. And that is then stored in the same place as your encrypted data. So those things live together. I don't take that and put it anywhere else. It's just sitting there in the same place. So shared fate. If that device functions, you've lost both things. Doesn't matter. They protect the same thing. They're the same thing. This recovery key, which we use to encrypt that little bit of information, we split that using Shamir. So we split that into what I'm calling fragments. Shamir calls them shares. We split it into fragments and then we give those fragments to the people running the servers. But we do this carefully. The servers then make a promise. So this is a community and the server promises, I will not give you back this fragment unless you prove who you are using an identity of your choice. So you can tell me, I'm the server operator and you say, hey, only give me my fragment back if I can verify that I have the right telephone number or the right email address or a GitHub account or something like that. So what we have, that's the core of the idea. I'm going to go back into it again. I'm going to give you a little demo, show you how the software behaves. Today we have most of the building blocks. So basically I have a first iteration of all of these things. Some documentation, I've tried really hard, but documentation is hard. So if anyone wants to read it and complain, that's very welcome. If it confuses you, then I fail. I need to fix it. There's a client library for people that are working in Python. If this takes off, there should be libraries for other languages as well, but Python is where I've started. There is a very simple server implementation. Doesn't perform very well, it doesn't do anything fancy, but it does work. And then there's a command line tool because, as I said, this isn't built into anyone's software yet. So there is a command line tool so you can experiment with it and play with it. You can set up manual recovery yourself and imagine that we're in a magical future where this is built into our software. There's a website, pasco.org. It has a little intro. It has an overview of which servers are live that will help with this recovery process. And at the moment there are two, both of which are run by me. One of them is for testing and the other one is for more serious testing or actual data if you trust it. That's the URL and the amazing logo that Crayon generated for me. So if you were to go and install this, I decided to do a slideshow instead of walking through on my laptop. But the first thing I'm doing there, can everyone see this? Yeah? So the first thing is you can install it from PyPy. So you just pip install pascro. And then you run the first command, would you just be pascro in it? And what that does, it just sets up a directory for storing information and what I'm calling a default policy. And you can look at what's in that default policy. So that's that last line there. I'm opening it with VI because I'm a hacker. You can see some interesting things here. I've edited the defaults to add some bits. I'm specifying the ratio. That's hard to read. It says three quarters, three out of four. So if I give pascro four identities, it will require three of them for recovery to succeed by tuning the parameters to the Shamir algorithm, as I mentioned earlier. And there are some timeouts. I can say I want this data to expire in a year or in 10 years or in five days. These are things that can be tuned. And then there's a timeout. Has anyone here not recovered a password from something like Gmail? Everyone's done it. So you're all familiar with the fact that these little codes that they send you are time limited. That's that timeout. So we have the same concept. I created a very valuable script. I created a file called secret.txt. And then I say pascro protect secret.txt. And here I've given it my phone number and my email address. And those are both correct, so please don't spam me. And don't call me out of business hours unless it's really exciting. We can ask the tool for a list. You can say pascro list. And then it will show you which shares have been, or which things have been put in escrow. And we're going to look inside one of these files. It's just a JSON file, bunch of parameters. There's a thing there. Line four is a secret. And that's a base64 encoded blob. And pascro doesn't care what's in there, but that's the secret information that we gave it to begin with. It says there that it has a minimum of two shares because they only gave it two identities. So it can't really do three out of four. So it approximates. It does its best. And it stores other things it needs to know to recover things. This is what recovery looks like. Pascro recover. And they tell it secrets.txt. It remembers. That's what it was protecting before. It contacts the two servers. And it asks them to verify. And then it tells me I should expect to receive an SMS or a phone call. And I should expect to receive an email. And it gives hints about where those will be sent to. And this has done server sites. The server site doesn't send the full identity back. Oh, wow. I've talked way too slow. So if someone else initiates recovery, they don't know exactly which accounts to look at. And again, this is familiar from recovery for other things. Once I receive the codes, I run PascroRecover again. I give it the codes. And it, well, it sent me an SMS. This works. It does. It goes through Twilio, an American company. I'm sure we all trust. Sent me an email. That went, there's mail pile. It totally exists. I recover. And it's hard to see because there's a bunch of their output. But it shows the contents of the file that I gave it to begin with. This is my secret. And then I can tell it to forget all about it. And then it goes and deletes the local information and asks the servers to delete the stuff they have on file as well. So that's the tool. This is all the tool does. You've seen the whole thing. And you can install it and play with it. So back to the design goals, again, secure enough. The way I'm doing that is obviously we encrypt any communication that we do. When we talk to the server, that's encrypted. The Pasco servers, they don't have your data. All they have is an encrypted blob, which they cannot read to begin with. And inside that encrypted blob is your identity and a fragment of the recovery key, not the whole thing. The reason these things are encrypted protects your privacy. So when you initiate recovery, when you say to Pasco, I want to recover my stuff, Pasco goes back to that recovery pack, which is stored locally, finds the key that was generated to encrypt the thing the server has and says, here, server, now you're allowed to decrypt your instructions. And so then it opens up the recovery envelope thing, finds the identity, and sends you a code or asks you to visit a website and log in through some other means. And this means in these little codes that we're sending around, this means that these providers, the email providers, Twilio, they never see any key material at all. All they're seeing is this temporary code that lasts 30 minutes or 20 minutes, whatever the user decides. And we're leaking very little information. Yeah, as I said, the user is in control of those things. And it's kind of important is that because usually you would have three out of four or something like that, servers can go offline. Pasco servers can be dead. And you can still probably recover. And most of the time, you're not recovering. So Pasco servers don't have to have very high uptime. They can go down for maintenance without the admins being stressed out. And of course, all of this is open source. Hopefully peer review will contribute to the security of things. User-friendly, the main key that makes this user-friendly is that this is a really familiar pattern. We already know how to do this. We don't have to teach users new stuff. We just have to add these options to our software. Developer-friendly, docs stuff, I don't know if I'm succeeding at this yet. Maybe you can tell me. And system-friendly, I'm a little more comfortable there. I've been an admin for a while. So I've made sure that the admins themselves don't feel at risk. They don't have data that has value. They don't know who their users are. Their users are anonymous. So there's limited gain in hacking a Pasco server. There's not much to find there. So this relates to that. I already mentioned that uptime isn't a major thing. And you can do things like rate limit because Pasco isn't something which you're using constantly. So you can have really strict rate limits. I can say five requests per minute. And that will suffice to recover. But it will make it very hard for people to put any load on the server. So that's most of the talk. Thanks for listening. And I'm on time. I'm up here because this has reached the point where I need help. This whole effort has no meaning if people don't use it. And if it's only me, then I'm just another guy on stage saying, hey, trust me instead of that other guy. And that's not how this stuff is supposed to work. So if you're interested in this, please find me after the talk or find me during camp. I'm here for all of camp. And I'm at the Quarantine Arms Village when I'm not wandering around looking for fun. So that's my talk. Thank you for listening. Can you hear me? Yes. Thank you, Bjarn, for a great talk. There is time for Q&A. If you want to ask a question, please go to the mic. I'm already seeing somebody running. The mic is yours. You hear me now? A little bit. OK. I think you've hit upon an important problem. And it's good idea to take power away from the cloud services, of course. We're doing similar things with authentication. So we need to talk to you. Can you speak up a tiny bit? We're doing similar things with authentication. So I definitely want to talk to you afterwards. But a big question with these things is how flexible is it? As in if your phone number changes or your email address changes, can you, without decoding and re-encoding your documents, which may be many, can you change over to a new ecosystem? OK. So the question, just repeating it for the stream, and I hope I get it right, you're asking whether people can easily change which identities they're using in the middle of things. So if they lose access to an email address, how easy is it to switch to another one? And the thing is, yes and no, if you're working with the information on a regular basis, if this is built into an app like an email client that you're using, that email client can just do that automatically. You just re-registers. You don't even have to know. It might do that automatically for you. If you set up escrow for something like an offline hard drive, you're going to have to know that you need to go and do that again. And the way you do it is you just put stuff in escrow again. You throw away the old keys, ask the servers to forget if you still have access to the recovery pack, and you just set it up again. And it's very cheap. These are tiny requests, tiny amounts of data. So doing it again isn't a burden. OK. Next question. And please talk straight into the microphone. One moment, the microphone on. Maybe now. Hi. I was just wondering if you could elaborate and maybe state more explicitly your threat model, in particular around when servers are compromised. And if you're three or four verification thing, it's a little unclear to me whether this was three or four emails and phone numbers, or three or four servers that are collaborating. And if you could just elaborate how that is intended to work. OK, so to repeat back, you'd like me to elaborate a little bit on the threat model of how many servers are involved, how many identities are involved, whether those are linked, that kind of thing. And I'm not actually prescribing anything about that. The system is quite flexible, and it ends up being up to the application. So the developer of the application that ends up using the passcrow library, I assume that they know way better than I do what kind of data they're protecting and how valuable it is. And some of this is out of my control, because until we have more servers, it's all going through the same one. But if we had 100 servers on different continents and different legal jurisdictions, a tool could make intelligent choices and say, OK, I would like law enforcement to not be able to subpoena all of the passcrow servers easily so they could spread things around. The system is completely agnostic to that. So it really depends on how much momentum we can get, what kind of guarantees we can give people, how much security we can provide. Does that answer it? Partly, but I want to let the person behind me ask another question. Maybe I'll find you afterwards. You can find me afterwards. And you can always ask again after us. Yes, next question. I have one remark and one question. Let me start with the question. If I lose the recovery pack, I can't get my data back, correct? Yes, that's correct. If you lose the recovery pack, your data is gone. Well, you can't recover your data. Hopefully, you still have access to it to other means. Yeah, so what if I use this, for example, to do a backup of my hard drive encryption secret and the recovery pack is on my fully encrypted hard drive when it's kind of useless? Yeah, of course. You need the recovery pack needs to be stored clear text, and ideally on the same physical medium as the encrypted data so that they have shared fate. So that if that drive is malfunctioned, it doesn't matter whether you can decrypt it or not. But if you put those things in two different places, if you put the recovery pack over here and you put the data over here, these things can start behaving in ways that don't match. And that's a lot harder to reason about. My remark was you were using Shamir's secret sharing, which for me almost never makes sense. The whole idea of Shamir's secret sharing is to scale K out of N recovery to avoid the K over N complexity. Now, how many authentication methods are you going to have? 100? Do you have 50 over 100? Where do you get the scalability problem that requires using of Shamir's secret sharing? If I have five different authentication methods and I say four out of five, I don't need Shamir's secret sharing to do that. And if you do Shamir's secret sharing, you limit me to K out of N. And I can't use other kinds of combinations like saying two methods for him and two methods for him or three methods for this guy. I think we're getting into the weeds a tiny bit. The thing is it does what I need. And it's very likely the algorithm can do other things as well. And when I started doing this, I did not use Shamir's secret sharing. I had my own little ad hoc thing where I was doing Xsores of things against each other. It just became unwieldy. Shamir does exactly what I want. I can say I have four email addresses, any three of them suffice, and I can ask Shamir to generate the fragments that I need. And whether that is secure or not, that depends entirely on how many identities the user's willing to go through. And that becomes a usability issue. And it becomes a matter of threat modeling. For some users, it doesn't make sense to do this at all. Okay, I see somebody else. I would say this is the last one. So, well, two comments. So one, Phillip Bragaway has some nice paper. Phillip Bragaway is a very famous symmetric cryptographer. He has some very nice papers. And I can't remember the names of the thing or anything at the moment. Maybe I can help you find it later if you need. On doing, what he wanted is he wanted a packet form, basically a format for sharing data with journalists, which was also doing this kind of like splitting the thing out and whatever. Anyway, so it's using Shamir's secret sharing and it achieves, he basically sort of outlined in a very rigorous way a bunch of the goals and non-goals and whatever. So it, probably people working in this should at least look at what he did. And try and understand it. But I haven't done that, so I can't give you concrete comments. The other one is that there's a very, when you are using Shamir, there's a very nice thing that you can do, which is you can construct new shares to give out to new service, services that are like holding the thing, the recovery services or whatever. So you can do that all asynchronous. Thank you. I'd be interested if you could find me later and tell me all of that again. So I'm sorry for that. We have to cut it short at some point. I think this was a great session, so can I have a warm applause for our speaker? Thank you. And he will be available for talking afterwards, so please, I just lost out. Please go and find him and talk to him about any more topics you want to discuss. Thank you and see you in the next session.