WEBVTT 00:01.180 --> 00:03.560 All right, welcome back, everybody. 00:03.720 --> 00:08.160 Next talk up is File Encryption for Actual Humans by David Kane-Perry. 00:08.240 --> 00:09.500 Take it away. 00:09.900 --> 00:10.900 Thank you. 00:11.260 --> 00:14.460 All right, so welcome to File Encryption for Actual Humans. 00:14.460 --> 00:20.000 This is going to be a proof of concept of modern cryptography and human-centered design in about 100 lines of Python. 00:20.020 --> 00:28.240 My name is David Kane-Perry, and while I currently work at Spotify, wrestling with all things cryptography and then some, this talk has nothing to do with my day job. 00:28.240 --> 00:32.200 This project, however, has a bit to do with the previous job. 00:32.300 --> 00:33.360 I was onboarding with the U.S. 00:33.360 --> 00:44.040 federal government, and background checks for public trust positions are based on the same criteria used to grant or deny security clearances, but are submitted by emailing forms rather than by web app. 00:44.160 --> 00:47.380 This here is just the first of 58 pages. 00:47.580 --> 00:56.780 The problem I faced then, and that a lot of people continue to face in similar situations, is that I had to share all that rather confidential data, and it had to be in an email. 00:57.520 --> 01:00.480 But email is fantastically insecure. 01:00.840 --> 01:04.600 I mean, the principal problem is that email is a store-and-forward protocol. 01:04.600 --> 01:10.280 That's just a fancy way of saying that there's an intermediary between the sender and the receiver who's responsible for message delivery. 01:10.280 --> 01:13.400 But it requires trust in the operator of the intermediary. 01:13.400 --> 01:18.480 If green and blue can't accept the risk of trusting red, they probably shouldn't be using email. 01:18.880 --> 01:21.060 But wait, it gets worse. 01:21.060 --> 01:26.720 Even if green and blue can accept the risk of trusting red, can they also do that for purple and for gray? 01:26.780 --> 01:29.500 Because even no purple and gray are in the loop. 01:29.520 --> 01:40.240 Because email may hop across multiple systems before it reaches its destination, the operator of each system needs to be trusted so to neither read nor modify green's email to blue. 01:40.480 --> 01:43.760 Oh, but the list of intermediaries can't be known in advance. 01:44.460 --> 01:51.360 So even if you have transport security between green and blue, each hop decrypts green's email and then re-encrypts it when forwarding it on. 01:51.660 --> 02:00.920 None of the trust issues with red, purple, and gray are addressed, only potentially the risk of already unauthorized access by an attacker in a privileged network position. 02:01.140 --> 02:06.120 Aha, you might be thinking to yourself, I can solve this problem by sharing the file through a hosting service. 02:06.780 --> 02:07.920 Well, bad news. 02:07.920 --> 02:10.200 That model still collapses to sending an email. 02:10.200 --> 02:16.760 The email that green sends to blue with the link to the file is as insecure as if green had included the file in the email itself. 02:16.980 --> 02:20.560 There are no shortcuts to turning an insecure channel into a secure one. 02:21.500 --> 02:26.260 Speaking of trying to turn an insecure channel into a secure one, a quick digression on GPG. 02:26.940 --> 02:28.740 It's worse than email. 02:28.740 --> 02:31.820 Unlike GPG, email is something that people want to use. 02:31.820 --> 02:37.700 For both the US federal government and the less technically sophisticated members of your family, perhaps, it's what they're comfortable with. 02:37.700 --> 02:41.820 And for different reasons, they're both highly averse to installing any third-party software. 02:41.960 --> 02:48.640 Even if you could help them out of their comfort zone, tools like GPG have proven over and over to be unworthy of our trust. 02:49.040 --> 02:54.600 So here's the threat model me and many others are dealing with, but it's okay if it doesn't match yours. 02:55.020 --> 02:56.680 First, it's got to be an email. 02:56.680 --> 03:00.480 No signal or whatever other tool we would prefer to use. 03:00.740 --> 03:02.740 Second, no file hosting URLs. 03:02.740 --> 03:04.000 It's just as insecure. 03:04.000 --> 03:10.380 And besides, with what I assume are the best of intentions, folks have been trying to train others to simply not click on links in email. 03:10.560 --> 03:13.320 To borrow the southern US phrase, bless their hearts. 03:14.000 --> 03:15.820 Also, no third-party software. 03:15.940 --> 03:21.200 The US federal government has many barriers in place to prevent this, and they're not about to lower them just for me. 03:21.460 --> 03:27.520 For your less sophisticated family members, even if they wanted to, could even manage it without your in-person assistance. 03:27.740 --> 03:30.500 And at that point, you no longer need to send them an email. 03:31.500 --> 03:37.780 As highlighted in the file hosting proposition, it would be pointless to send both the encrypted file and the key via email. 03:37.780 --> 03:44.080 While the plural of insecure channels is not synonymous with a secure channel, it may acceptably lower the risk. 03:44.120 --> 03:45.960 Unknown entities snooping my email? 03:45.960 --> 03:46.940 Unacceptable. 03:46.980 --> 03:50.080 Unknown entities snooping both my email and my phone? 03:50.080 --> 03:55.140 That could be highly probable for some, but my self-assessment leans towards low risk for me. 03:55.140 --> 03:57.760 So what tools are available by default? 03:58.480 --> 04:01.560 Well, PKZip is just everywhere. 04:01.560 --> 04:04.680 Windows, Mac OS, Linux, choose your BSD. 04:04.680 --> 04:08.200 You name it, they probably ship a zip tool with the installation media. 04:08.260 --> 04:12.580 But because of licensing issues, they won't be shipping the zip format that uses the AES cipher. 04:12.580 --> 04:15.460 Oh no, they'll be using the homegrown PKZip cipher. 04:16.120 --> 04:19.940 And oh boy, PKZip is so broken. 04:19.940 --> 04:21.800 Hashtag, never roll your own crypto. 04:22.040 --> 04:23.620 Shocking, right? 04:23.620 --> 04:32.240 From an attacker's perspective, having foreknowledge of 13 consecutive plain text bytes may not be any burden at all, and they'll have that file cracked in a couple hours. 04:32.320 --> 04:41.880 Or as was demonstrated just the other day, under other circumstances, the attacker doesn't even need to have foreknowledge of any plain text bytes, and they'll still be able to crack it in a couple hours. 04:42.420 --> 04:55.940 Even against less sophisticated attackers who won't try and break the cipher, but instead will just try and crack the password, it's lack of resistance combined with human imperfection of password choices means that odds are they'll win in a reasonable amount of time with a modest amount of resources. 04:56.180 --> 05:03.840 Fun fact, a potential employer once sent me a zip encrypted file the day before they would interview me about the code inside. 05:03.840 --> 05:11.960 With nothing better to do at the time, I ran a cracker on it, and was frankly disappointed to quickly discover the password was the name of the company's product. 05:12.600 --> 05:17.020 And it's those kind of human-computer interaction challenges that really undermine password-based security. 05:17.160 --> 05:21.860 Here's a quote by Dave Kearns paraphrasing something Winston Churchill said about democracy. 05:22.040 --> 05:27.280 Passwords are the worst form of authentication except for all those other methods that have been tried from time to time. 05:28.220 --> 05:29.500 500 years. 05:29.500 --> 05:35.940 That's how long it would take to get at least 50% probability of successfully guessing a cryptographically random 10-character U.S. 05:35.940 --> 05:41.120 keyboard-based password, assuming a guess rate of 47 quadrillion passwords a year. 05:41.300 --> 05:44.840 But it means humans having to deal with credentials that look like this. 05:44.840 --> 05:48.960 This isn't something I could read over the phone to someone or even put in a text message. 05:48.960 --> 05:54.380 That character next to the Q, is that a capital I or an L or the pipe character? 05:54.400 --> 05:57.000 These are good for computers, but they're bad for people. 05:57.480 --> 05:58.540 700 years. 05:58.540 --> 06:06.020 That's how long it would take to get at least 50% probability of successfully guessing a cryptographically random six-word English-based passphrase. 06:06.020 --> 06:09.860 Again, assuming a guess rate of 47 quadrillion passphrases a year. 06:10.600 --> 06:13.380 And instead, we're dealing with strings that look like this. 06:13.380 --> 06:23.800 This is something I could read over the phone or put in a text message and have very little risk of misinterpretation by the other party, necessitating rather frustrating error correction protocols, just open my file. 06:24.440 --> 06:30.980 But all those confidence-inspiring numbers are only true when it's the computer that generates the credential instead of the human. 06:31.020 --> 06:36.640 Humans are really bad at pretending to be computers and consistently fail the reverse Turing tests that are thrown at them. 06:36.900 --> 06:39.040 Like generating random strings. 06:39.040 --> 06:44.620 Computers are great at this, but we keep asking people to do this, despite overwhelming evidence that they simply can't. 06:44.620 --> 06:51.700 If they could, we wouldn't be able to compile the top 100 common passwords, but we can, because they can't. 06:51.820 --> 06:56.360 Even if they could, password policies ensure that cryptographically random strings won't be accepted. 06:56.360 --> 07:08.180 If there's a policy that says, must include one each of uppercase, lowercase, numeric, and special characters, all that's been accomplished in this attacker, all that's been accomplished is the attacker search space has been reduced. 07:08.200 --> 07:13.800 Another fun fact, at a previous job, we tried to crack the employee passwords that had a similar policy in place. 07:13.900 --> 07:19.320 The most popular cracked password, the company name, followed by the current year, followed by an exclamation point. 07:19.440 --> 07:22.780 It was easy, then, for us to predict what we'd find the following year. 07:23.580 --> 07:26.740 Of course, generating one is just half the challenge. 07:26.980 --> 07:30.180 Do you remember the six-character password I showed a few slides back? 07:30.180 --> 07:35.820 This might be good news or bad news, depending on which side you wanted to take in the robot apocalypse, but you might be an Android. 07:35.940 --> 07:42.580 The rest of us meatbags have a really hard time remembering stuff all the time, especially when there's no pattern for us to match on. 07:43.440 --> 07:48.060 So one of the tricks we've learned is that we use those little trouble tokens everywhere we possibly can. 07:48.060 --> 07:53.300 Folks will figure out their quote-unquote one good password and reuse that bugger everywhere. 07:53.340 --> 08:03.520 But inevitably, someone will store that password insecurely, and now all their accounts are compromised across all the services, and they have to come up with a new good one good password, until the next compromise. 08:04.480 --> 08:10.400 So let's stop asking humans to be computers and embrace what computers are better at than them. 08:10.400 --> 08:17.920 To that end, I wrote a proof-of-concept tool to demonstrate what a file encryption tool that leverages modern cryptography and human-centered design could look like. 08:18.840 --> 08:22.420 First, replace the PKZIP cipher with AES-SIV. 08:22.520 --> 08:29.440 AES-SIV could take an entire talk on its own, but what's most important is its resistance to nonce, reuse, misuse. 08:29.800 --> 08:34.180 Even with AES-GCM, if nonces are reused, failure can be catastrophic. 08:34.180 --> 08:41.660 With AES-SIV, if nonces are reused, the impact is limited to an attacker observing that the same unknown message was encrypted more than once. 08:42.540 --> 08:46.180 Also, replace the CRC-based key derivation function with Argon2. 08:46.180 --> 08:53.360 Again, Argon2 is deserving of a talk all to itself, but what's important here is the resistance Argon2 provides against GPU-based cracking. 08:53.420 --> 09:01.920 The parameters of Argon2 can be tuned as one sees fit to force the attacker to make difficult trade-off decisions when it comes to rate of guessing and the cost of each guess. 09:03.000 --> 09:14.430 And finally, replace asking the human to choose a password and just choose one for them at random. 09:14.590 --> 09:24.230 You may be familiar with the popular XKCD comic strip that demonstrates the superiority of a password like correct horse battery staple to troubadour with leet speak characters. 09:24.290 --> 09:29.270 What seems to be often misunderstood about that demonstration, though, is the necessity of the words to be random. 09:29.530 --> 09:38.250 And so, consequently, some services have started to reject correct horse battery staple as a password because so many people have decided it would be their new one good password. 09:38.950 --> 09:46.090 And here, I've chosen four words rather than six because Argon2 enables us to reduce the total number of guesses per year an attacker could make. 09:46.090 --> 09:50.690 And so, I can shrink the search space for greater human usability. 09:51.750 --> 09:52.430 Okay. 09:52.430 --> 09:53.370 So, demo time. 09:53.370 --> 09:56.110 But keep in mind, this is supposed to be boring. 09:56.250 --> 10:00.950 We're trying to solve real problems for the average person, so complexity is the enemy of adoption. 10:01.770 --> 10:08.470 And given the technical difficulties that have and could arise, I decided the most reliable way to demonstrate this was just take a screenshot of my terminal. 10:08.530 --> 10:13.470 On the first line, I'm encrypting a file because it doesn't end in the magic.xc suffix it's looking for. 10:13.470 --> 10:17.430 There's no need to pass in any other command line arguments because there aren't any. 10:17.530 --> 10:21.130 I see the path phrase that was generated for me and the name of the encrypted file. 10:21.130 --> 10:25.710 And now I could email that file to someone and call them with the pass phrase and they would follow the other lines. 10:26.090 --> 10:32.950 The file is open for decryption because it ends in the magic.xc suffix and the user's prompted for the pass phrase. 10:32.950 --> 10:36.810 Having supplied it, the file is decrypted and the name of the decrypted file is displayed for the user. 10:36.950 --> 10:41.130 The lines after that demonstrate this proof of concept also works for directory trees as well. 10:41.750 --> 10:46.710 But this is just a proof of concept and should not really be used anywhere ever. 10:47.070 --> 10:49.830 So why did I do this then? 10:50.470 --> 11:05.150 Well, we need the Microsoft's and the Apple's of the world to accept responsibility for the broken cryptography and the human hostile design they ship by default to all their customers who are not security experts and trust that the tools that they provide are up to the task at hand. 11:05.210 --> 11:11.090 Remember that folks generally don't want third party software when the first party one seems good enough. 11:11.250 --> 11:14.530 That was after all the basis for antitrust suit against Microsoft. 11:15.370 --> 11:18.450 So governments may be in a position to drive change here. 11:18.450 --> 11:29.190 At least in the U.S., the National Institute of Standards and Technology has been tasked by Senator Ron Wyden to look into the insufficiencies of the tools that are being provided by default and perhaps to find a new sufficient standard. 11:29.270 --> 11:31.950 I eagerly await any progress they make here. 11:32.250 --> 11:35.870 But if this is a problem space that interests you, you don't need to wait. 11:35.870 --> 11:41.570 There are a couple of other projects that are not just proof of concepts but are actually stable and interested in real-world users. 11:41.710 --> 11:47.290 Magic Wormhole is an interesting human-centered approach to sharing files directly over network instead of email. 11:47.730 --> 11:54.910 And Augie implements modern cryptography for file encryption even if the user experience is not really intended for technical novices. 11:55.790 --> 12:00.570 So thank you for your time and if you have any questions or comments for me, I've provided a few links here. 12:00.570 --> 12:05.970 The first one is a post I wrote that explores some of the issues here and perhaps a bit more depth with links for all of my references. 12:06.290 --> 12:10.170 If you don't want to play, if you just want to play around with the code, you can find it there on GitHub. 12:10.290 --> 12:12.990 And if you'd still like to reach out, my DMs are always open on Twitter. 12:12.990 --> 12:14.090 And thanks again. 12:16.640 --> 12:19.360 Thank you so much for joining us today, David. 12:19.460 --> 12:21.360 That was very interesting. 12:24.620 --> 12:35.180 See, I don't see too many comments in the chat, but viewers, if you have any questions, put them in the Discord Q&A chat. 12:46.300 --> 12:47.040 Let's see. 12:47.040 --> 12:49.920 And this is the last talk of the day. 12:49.920 --> 12:51.100 Yay! 12:56.310 --> 12:59.330 Do you have any thoughts on password expiration? 13:00.130 --> 13:02.370 Do I have any thoughts on password expiration? 13:03.270 --> 13:11.510 I think that a lot of organizations have got themselves into trouble by making them time-based rather than event-based. 13:11.530 --> 13:22.750 Certainly when there's evidence of compromise, that would be a good driver for doing a rotation across one or more of the potentially at-risk users in scope. 13:23.050 --> 13:39.690 But when there's policies in place that force people to, as I was forced to in my time during the US federal government to change my password every 90 days, like every 90 days, everyone was complaining about how they had to pick a new password, even though there was no evidence that anyone had been compromised in any way whatsoever. 13:39.690 --> 13:41.690 Mm-hmm. 13:43.230 --> 13:46.930 Thoughts on minimum password length requirements? 13:48.590 --> 13:50.250 That's an interesting question. 13:50.250 --> 14:04.130 I mean, that kind of gets to one of the things I talk about in the posts that I link to, that past a certain point, you're expecting users to adopt and be comfortable using a password manager, right? 14:04.950 --> 14:11.090 We're still more or less comfortable to like, okay, 10 characters is something that someone can remember without software to help them. 14:11.150 --> 14:20.070 But once we start talking about 12 and 14 and beyond that, you're stretching the limits of what humans were capable of in the first place. 14:20.070 --> 14:37.090 And so I think the sooner organizations can migrate towards supporting their users to get comfortable password managers, or alternatively adopting security keys, then questions about minimum password length become less important in terms of human-computer interaction questions. 14:37.910 --> 14:38.810 Yeah, that's great. 14:38.810 --> 14:44.250 And there was another question on password managers, but it sounds like you just touched it right there. 14:44.250 --> 14:44.990 Cool. 14:45.290 --> 14:51.310 And then do you feel like Microsoft is already solving the password issue with passwordless logins? 14:51.310 --> 14:56.610 And do you see that gaining widespread adoption in other applications such as cryptography? 14:57.390 --> 15:01.210 I think they're certainly solving one part of the problem. 15:01.210 --> 15:04.290 They're solving kind of the online service problem. 15:04.370 --> 15:17.470 One of the things that I touch on on my post is that this kind of approach to generating the password for the user one time and just showing it to the screen, that's not going to work for a service that you need to interact with multiple times. 15:17.850 --> 15:24.990 And so that's, again, where password managers and security keys come back into the scope of things. 15:25.050 --> 15:47.110 In this limited case, passwordless authentication isn't going to help out the problem where I have a file I need to email to someone because then without any sort of mechanism for doing key exchange between them, there's no way for me to do any encryption on the file that could be decrypted by the other user. 15:48.090 --> 15:48.830 Yeah. 15:50.790 --> 15:52.010 All right. 15:52.170 --> 15:53.170 Thanks for the talk. 15:53.170 --> 15:54.090 Very cool stuff. 15:54.090 --> 16:03.690 Do you think it would be better to pursue making the implementations of existing technologies like PGP more user-friendly than trying to build something new? 16:03.690 --> 16:08.350 Or do you feel like things are too difficult to make user-friendly as it stands now? 16:09.550 --> 16:11.310 That's a hard question. 16:11.370 --> 16:18.910 In general, my preference is always to help improve existing tools rather than to start from scratch. 16:19.270 --> 16:30.450 But as someone who has not waded in as deeply as, say, folks who have built Magic Worm and Aage, I trust that they have tried to do their best. 16:30.550 --> 16:37.730 And that in their final judgment, in order for them to do what they felt was necessary, they needed to build something from scratch. 16:39.470 --> 16:47.850 And I think there's nothing preventing projects from cross-pollination of ideas, the possibility to reuse code. 16:48.190 --> 16:51.240 So yeah, there's no one-size-fits-all. 16:53.650 --> 16:56.550 All right, well thank you for joining us today. 16:56.550 --> 17:00.450 I know there's a few more questions that I might have missed in the chat. 17:00.530 --> 17:05.470 Hopefully we can get David in there in Discord to answer any more that you have. 17:05.650 --> 17:06.850 Yep, I'll be there. 17:06.990 --> 17:08.710 Thank you for joining us. 17:08.710 --> 17:09.530 Thank you.