start	end	text
1180	7380	All right, welcome back, everybody. Next talk up is File Encryption for Actual Humans by David
7380	14460	Kane-Perry. Take it away. Thank you. All right, so welcome to File Encryption for Actual Humans.
14460	18720	This is going to be a proof of concept of modern cryptography and human-centered design in about
18720	23560	100 lines of Python. My name is David Kane-Perry, and while I currently work at Spotify, wrestling
23560	28240	with all things cryptography and then some, this talk has nothing to do with my day job.
28240	33360	This project, however, has a bit to do with the previous job. I was onboarding with the U.S.
33360	37660	federal government, and background checks for public trust positions are based on the same
37660	42980	criteria used to grant or deny security clearances, but are submitted by emailing forms rather than
42980	49440	by web app. This here is just the first of 58 pages. The problem I faced then, and that a lot
49440	53940	of people continue to face in similar situations, is that I had to share all that rather confidential
53940	61380	data, and it had to be in an email. But email is fantastically insecure. I mean, the principal
61380	65680	problem is that email is a store-and-forward protocol. That's just a fancy way of saying
65680	69540	that there's an intermediary between the sender and the receiver who's responsible for message
69540	74960	delivery. But it requires trust in the operator of the intermediary. If green and blue can't
74960	81060	accept the risk of trusting red, they probably shouldn't be using email. But wait, it gets worse.
81060	85340	Even if green and blue can accept the risk of trusting red, can they also do that for purple
85340	90900	and for gray? Because even no purple and gray are in the loop. Because email may hop across
90900	95360	multiple systems before it reaches its destination, the operator of each system needs to be trusted
96000	102600	so to neither read nor modify green's email to blue. Oh, but the list of intermediaries can't be
102600	108540	known in advance. So even if you have transport security between green and blue, each hop decrypts
108540	112880	green's email and then re-encrypts it when forwarding it on. None of the trust issues with
112880	118880	red, purple, and gray are addressed, only potentially the risk of already unauthorized access by an
118880	123600	attacker in a privileged network position. Aha, you might be thinking to yourself, I can solve this
123600	129020	problem by sharing the file through a hosting service. Well, bad news. That model still collapses
129020	133800	to sending an email. The email that green sends to blue with the link to the file is as insecure
133800	138500	as if green had included the file in the email itself. There are no shortcuts to turning an
138500	144140	insecure channel into a secure one. Speaking of trying to turn an insecure channel into a secure
144140	150580	one, a quick digression on GPG. It's worse than email. Unlike GPG, email is something that people
150580	155200	want to use. For both the US federal government and the less technically sophisticated members
155200	158800	of your family, perhaps, it's what they're comfortable with. And for different reasons,
158800	162760	they're both highly averse to installing any third-party software. Even if you could help
162760	167900	them out of their comfort zone, tools like GPG have proven over and over to be unworthy of our
167900	173720	trust. So here's the threat model me and many others are dealing with, but it's okay if it
173720	179180	doesn't match yours. First, it's got to be an email. No signal or whatever other tool we would
179180	185580	prefer to use. Second, no file hosting URLs. It's just as insecure. And besides, with what I assume
185580	189760	are the best of intentions, folks have been trying to train others to simply not click on links in
189760	196000	email. To borrow the southern US phrase, bless their hearts. Also, no third-party software. The
196000	200060	US federal government has many barriers in place to prevent this, and they're not about to lower
200060	205040	them just for me. For your less sophisticated family members, even if they wanted to, could
205040	209760	even manage it without your in-person assistance. And at that point, you no longer need to send them
209760	215340	an email. As highlighted in the file hosting proposition, it would be pointless to send both
215340	220460	the encrypted file and the key via email. While the plural of insecure channels is not synonymous
220460	225960	with a secure channel, it may acceptably lower the risk. Unknown entities snooping my email?
225960	231520	Unacceptable. Unknown entities snooping both my email and my phone? That could be highly probable
231520	237760	for some, but my self-assessment leans towards low risk for me. So what tools are available by default?
238480	245620	Well, PKZip is just everywhere. Windows, Mac OS, Linux, choose your BSD. You name it, they probably
245620	250080	ship a zip tool with the installation media. But because of licensing issues, they won't be
250080	255460	shipping the zip format that uses the AES cipher. Oh no, they'll be using the homegrown PKZip cipher.
256120	264580	And oh boy, PKZip is so broken. Hashtag, never roll your own crypto. Shocking, right? From an attacker's
264580	269860	perspective, having foreknowledge of 13 consecutive plain text bytes may not be any burden at all,
269860	275040	and they'll have that file cracked in a couple hours. Or as was demonstrated just the other day,
275040	278700	under other circumstances, the attacker doesn't even need to have foreknowledge of any plain text
278700	284020	bytes, and they'll still be able to crack it in a couple hours. Even against less sophisticated
284020	287940	attackers who won't try and break the cipher, but instead will just try and crack the password,
287940	291680	it's lack of resistance combined with human imperfection of password choices means that
291680	295940	odds are they'll win in a reasonable amount of time with a modest amount of resources.
296180	302060	Fun fact, a potential employer once sent me a zip encrypted file the day before they would
302060	306560	interview me about the code inside. With nothing better to do at the time, I ran a cracker on it,
306560	311960	and was frankly disappointed to quickly discover the password was the name of the company's product.
312600	316180	And it's those kind of human-computer interaction challenges that really undermine password-based
316180	320260	security. Here's a quote by Dave Kearns paraphrasing something Winston Churchill said
320260	325060	about democracy. Passwords are the worst form of authentication except for all those other
325060	330740	methods that have been tried from time to time. 500 years. That's how long it would take to get
330740	335940	at least 50% probability of successfully guessing a cryptographically random 10-character U.S.
335940	341120	keyboard-based password, assuming a guess rate of 47 quadrillion passwords a year.
341300	344840	But it means humans having to deal with credentials that look like this.
344840	348960	This isn't something I could read over the phone to someone or even put in a text message.
348960	354380	That character next to the Q, is that a capital I or an L or the pipe character?
354400	359100	These are good for computers, but they're bad for people. 700 years. That's how long it would
359100	363520	take to get at least 50% probability of successfully guessing a cryptographically random
363520	368580	six-word English-based passphrase. Again, assuming a guess rate of 47 quadrillion
368580	373380	passphrases a year. And instead, we're dealing with strings that look like this.
373380	377380	This is something I could read over the phone or put in a text message and have very little
377380	381660	risk of misinterpretation by the other party, necessitating rather frustrating error correction
381660	387680	protocols, just open my file. But all those confidence-inspiring numbers are only true
387680	391440	when it's the computer that generates the credential instead of the human. Humans are
391440	395580	really bad at pretending to be computers and consistently fail the reverse Turing tests
395580	400120	that are thrown at them. Like generating random strings. Computers are great at this,
400120	404620	but we keep asking people to do this, despite overwhelming evidence that they simply can't.
404620	410220	If they could, we wouldn't be able to compile the top 100 common passwords, but we can,
410220	415100	because they can't. Even if they could, password policies ensure that cryptographically random
415100	420380	strings won't be accepted. If there's a policy that says, must include one each of uppercase,
420380	424580	lowercase, numeric, and special characters, all that's been accomplished in this attacker,
424580	428180	all that's been accomplished is the attacker search space has been reduced.
428200	432500	Another fun fact, at a previous job, we tried to crack the employee passwords that had a similar
432500	437100	policy in place. The most popular cracked password, the company name, followed by the
437100	441200	current year, followed by an exclamation point. It was easy, then, for us to predict what we'd
441200	447600	find the following year. Of course, generating one is just half the challenge. Do you remember
447600	451760	the six-character password I showed a few slides back? This might be good news or bad news,
451760	455820	depending on which side you wanted to take in the robot apocalypse, but you might be an Android.
455940	460660	The rest of us meatbags have a really hard time remembering stuff all the time, especially when
460660	465520	there's no pattern for us to match on. So one of the tricks we've learned is that we use those
465520	469520	little trouble tokens everywhere we possibly can. Folks will figure out their quote-unquote
469520	474940	one good password and reuse that bugger everywhere. But inevitably, someone will store that
474940	479160	password insecurely, and now all their accounts are compromised across all the services,
479160	483520	and they have to come up with a new good one good password, until the next compromise.
484480	489180	So let's stop asking humans to be computers and embrace what computers are better at
489180	494060	than them. To that end, I wrote a proof-of-concept tool to demonstrate what a file encryption tool
494060	497920	that leverages modern cryptography and human-centered design could look like.
498840	505140	First, replace the PKZIP cipher with AES-SIV. AES-SIV could take an entire talk on its own,
505140	511320	but what's most important is its resistance to nonce, reuse, misuse. Even with AES-GCM,
511320	516900	if nonces are reused, failure can be catastrophic. With AES-SIV, if nonces are reused,
516900	520740	the impact is limited to an attacker observing that the same unknown message was encrypted more
520740	526680	than once. Also, replace the CRC-based key derivation function with Argon2. Again,
526680	530680	Argon2 is deserving of a talk all to itself, but what's important here is the resistance
530680	536020	Argon2 provides against GPU-based cracking. The parameters of Argon2 can be tuned as one sees fit
536020	539880	to force the attacker to make difficult trade-off decisions when it comes to rate of guessing
539880	552230	and the cost of each guess. And finally, replace asking the human to choose a password and just
552230	558270	choose one for them at random. You may be familiar with the popular XKCD comic strip that demonstrates
558270	563070	the superiority of a password like correct horse battery staple to troubadour with leet speak
563070	567630	characters. What seems to be often misunderstood about that demonstration, though, is the necessity
567630	573190	of the words to be random. And so, consequently, some services have started to reject correct horse
573190	577190	battery staple as a password because so many people have decided it would be their new one
577190	582730	good password. And here, I've chosen four words rather than six because Argon2 enables us to
582730	587410	reduce the total number of guesses per year an attacker could make. And so, I can shrink the
587410	594770	search space for greater human usability. Okay. So, demo time. But keep in mind, this is supposed
594770	600030	to be boring. We're trying to solve real problems for the average person, so complexity is the enemy
600030	605130	of adoption. And given the technical difficulties that have and could arise, I decided the most
605130	609510	reliable way to demonstrate this was just take a screenshot of my terminal. On the first line,
609510	613910	I'm encrypting a file because it doesn't end in the magic.xc suffix it's looking for. There's no
613910	618510	need to pass in any other command line arguments because there aren't any. I see the path phrase
618510	622290	that was generated for me and the name of the encrypted file. And now I could email that file
622290	626570	to someone and call them with the pass phrase and they would follow the other lines. The file
626570	632210	is open for decryption because it ends in the magic.xc suffix and the user's prompted for the
632210	635510	pass phrase. Having supplied it, the file is decrypted and the name of the decrypted file
635510	639390	is displayed for the user. The lines after that demonstrate this proof of concept also works for
639390	646110	directory trees as well. But this is just a proof of concept and should not really be used anywhere
646110	653770	ever. So why did I do this then? Well, we need the Microsoft's and the Apple's of the world
653770	657890	to accept responsibility for the broken cryptography and the human hostile design
657890	663010	they ship by default to all their customers who are not security experts and trust that the tools
663010	667370	that they provide are up to the task at hand. Remember that folks generally don't want third
667370	672730	party software when the first party one seems good enough. That was after all the basis for
672730	678650	antitrust suit against Microsoft. So governments may be in a position to drive change here. At
678650	682150	least in the U.S., the National Institute of Standards and Technology has been tasked by
682150	687050	Senator Ron Wyden to look into the insufficiencies of the tools that are being provided by default
687050	692630	and perhaps to find a new sufficient standard. I eagerly await any progress they make here.
692630	696310	But if this is a problem space that interests you, you don't need to wait. There are a couple
696310	700030	of other projects that are not just proof of concepts but are actually stable and interested
700030	704810	in real-world users. Magic Wormhole is an interesting human-centered approach to sharing
704810	710250	files directly over network instead of email. And Augie implements modern cryptography for
710250	714910	file encryption even if the user experience is not really intended for technical novices.
715790	719850	So thank you for your time and if you have any questions or comments for me, I've provided a few
719850	723630	links here. The first one is a post I wrote that explores some of the issues here and perhaps a
723630	727950	bit more depth with links for all of my references. If you don't want to play, if you just want to
727950	731530	play around with the code, you can find it there on GitHub. And if you'd still like to reach out,
731530	738860	my DMs are always open on Twitter. And thanks again. Thank you so much for joining us today,
738860	749560	David. That was very interesting. See, I don't see too many comments in the chat, but viewers,
749560	767700	if you have any questions, put them in the Discord Q&A chat. Let's see. And this is
767700	779330	the last talk of the day. Yay! Do you have any thoughts on password expiration?
780130	786490	Do I have any thoughts on password expiration? I think that a lot of organizations have got
786490	792690	themselves into trouble by making them time-based rather than event-based. Certainly when there's
792690	799070	evidence of compromise, that would be a good driver for doing a rotation across one or more
799070	805770	of the potentially at-risk users in scope. But when there's policies in place that force people
805770	811630	to, as I was forced to in my time during the US federal government to change my password every 90
811630	815590	days, like every 90 days, everyone was complaining about how they had to pick a new password,
815590	819690	even though there was no evidence that anyone had been compromised in any way whatsoever.
819690	826930	Mm-hmm. Thoughts on minimum password length requirements?
828590	834070	That's an interesting question. I mean, that kind of gets to one of the things I talk about
834070	841390	in the posts that I link to, that past a certain point, you're expecting users to
841390	846190	adopt and be comfortable using a password manager, right? We're still more or less
846190	849570	comfortable to like, okay, 10 characters is something that someone can remember without
849570	855390	software to help them. But once we start talking about 12 and 14 and beyond that,
855390	860710	you're stretching the limits of what humans were capable of in the first place. And so I think
860710	866630	the sooner organizations can migrate towards supporting their users to get comfortable
866630	871970	password managers, or alternatively adopting security keys, then questions about minimum
871970	877090	password length become less important in terms of human-computer interaction questions.
877910	882770	Yeah, that's great. And there was another question on password managers, but it sounds like you just
882770	889210	touched it right there. Cool. And then do you feel like Microsoft is already solving the password
889210	894870	issue with passwordless logins? And do you see that gaining widespread adoption in other applications
894870	901210	such as cryptography? I think they're certainly solving one part of the problem.
901210	906230	They're solving kind of the online service problem. One of the things that I touch on
906230	911810	on my post is that this kind of approach to generating the password for the user one time
911810	915750	and just showing it to the screen, that's not going to work for a service that you need to
915750	920870	interact with multiple times. And so that's, again, where password managers and security
920870	929970	keys come back into the scope of things. In this limited case, passwordless authentication
931350	934990	isn't going to help out the problem where I have a file I need to email to someone
935790	940490	because then without any sort of mechanism for doing key exchange between them,
940970	947110	there's no way for me to do any encryption on the file that could be decrypted by the other user.
948090	956470	Yeah. All right. Thanks for the talk. Very cool stuff. Do you think it would be better to pursue
956470	961990	making the implementations of existing technologies like PGP more user-friendly than
961990	966930	trying to build something new? Or do you feel like things are too difficult to make user-friendly as
966930	975590	it stands now? That's a hard question. In general, my preference is always to help improve existing
975590	983050	tools rather than to start from scratch. But as someone who has not waded in as deeply as, say,
983050	990450	folks who have built Magic Worm and Aage, I trust that they have tried to do their best.
990550	995010	And that in their final judgment, in order for them to do what they felt was necessary,
995010	1003150	they needed to build something from scratch. And I think there's nothing preventing projects from
1003150	1011240	cross-pollination of ideas, the possibility to reuse code. So yeah, there's no one-size-fits-all.
1013650	1017650	All right, well thank you for joining us today. I know there's a few more
1017650	1021950	questions that I might have missed in the chat. Hopefully we can get David in there
1021950	1029530	in Discord to answer any more that you have. Yep, I'll be there. Thank you for joining us. Thank you.