All right, welcome back, everybody. Next talk up is File Encryption for Actual Humans by David
Kane-Perry. Take it away. Thank you. All right, so welcome to File Encryption for Actual Humans.
This is going to be a proof of concept of modern cryptography and human-centered design in about
100 lines of Python. 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.
This project, however, has a bit to do with the previous job. I was onboarding with the U.S.
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. This here is just the first of 58 pages. 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. But email is fantastically insecure. I mean, the principal
problem is that email is a store-and-forward protocol. 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. But it requires trust in the operator of the intermediary. If green and blue can't
accept the risk of trusting red, they probably shouldn't be using email. But wait, it gets worse.
Even if green and blue can accept the risk of trusting red, can they also do that for purple
and for gray? Because even no purple and gray are in the loop. 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. Oh, but the list of intermediaries can't be
known in advance. 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. 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. Aha, you might be thinking to yourself, I can solve this
problem by sharing the file through a hosting service. Well, bad news. That model still collapses
to sending an email. 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. There are no shortcuts to turning an
insecure channel into a secure one. Speaking of trying to turn an insecure channel into a secure
one, a quick digression on GPG. It's worse than email. Unlike GPG, email is something that people
want to use. For both the US federal government and the less technically sophisticated members
of your family, perhaps, it's what they're comfortable with. And for different reasons,
they're both highly averse to installing any third-party software. 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. So here's the threat model me and many others are dealing with, but it's okay if it
doesn't match yours. First, it's got to be an email. No signal or whatever other tool we would
prefer to use. Second, no file hosting URLs. It's just as insecure. 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. To borrow the southern US phrase, bless their hearts. Also, no third-party software. The
US federal government has many barriers in place to prevent this, and they're not about to lower
them just for me. For your less sophisticated family members, even if they wanted to, could
even manage it without your in-person assistance. And at that point, you no longer need to send them
an email. As highlighted in the file hosting proposition, it would be pointless to send both
the encrypted file and the key via email. While the plural of insecure channels is not synonymous
with a secure channel, it may acceptably lower the risk. Unknown entities snooping my email?
Unacceptable. Unknown entities snooping both my email and my phone? That could be highly probable
for some, but my self-assessment leans towards low risk for me. So what tools are available by default?
Well, PKZip is just everywhere. Windows, Mac OS, Linux, choose your BSD. You name it, they probably
ship a zip tool with the installation media. But because of licensing issues, they won't be
shipping the zip format that uses the AES cipher. Oh no, they'll be using the homegrown PKZip cipher.
And oh boy, PKZip is so broken. Hashtag, never roll your own crypto. Shocking, right? 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. 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. 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.
Fun fact, a potential employer once sent me a zip encrypted file the day before they would
interview me about the code inside. 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.
And it's those kind of human-computer interaction challenges that really undermine password-based
security. Here's a quote by Dave Kearns paraphrasing something Winston Churchill said
about democracy. Passwords are the worst form of authentication except for all those other
methods that have been tried from time to time. 500 years. That's how long it would take to get
at least 50% probability of successfully guessing a cryptographically random 10-character U.S.
keyboard-based password, assuming a guess rate of 47 quadrillion passwords a year.
But it means humans having to deal with credentials that look like this.
This isn't something I could read over the phone to someone or even put in a text message.
That character next to the Q, is that a capital I or an L or the pipe character?
These are good for computers, but they're bad for people. 700 years. That's how long it would
take to get at least 50% probability of successfully guessing a cryptographically random
six-word English-based passphrase. Again, assuming a guess rate of 47 quadrillion
passphrases a year. And instead, we're dealing with strings that look like this.
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. But all those confidence-inspiring numbers are only true
when it's the computer that generates the credential instead of the human. Humans are
really bad at pretending to be computers and consistently fail the reverse Turing tests
that are thrown at them. Like generating random strings. Computers are great at this,
but we keep asking people to do this, despite overwhelming evidence that they simply can't.
If they could, we wouldn't be able to compile the top 100 common passwords, but we can,
because they can't. Even if they could, password policies ensure that cryptographically random
strings won't be accepted. 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.
Another fun fact, at a previous job, we tried to crack the employee passwords that had a similar
policy in place. The most popular cracked password, the company name, followed by the
current year, followed by an exclamation point. It was easy, then, for us to predict what we'd
find the following year. Of course, generating one is just half the challenge. Do you remember
the six-character password I showed a few slides back? 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.
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. So one of the tricks we've learned is that we use those
little trouble tokens everywhere we possibly can. Folks will figure out their quote-unquote
one good password and reuse that bugger everywhere. 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.
So let's stop asking humans to be computers and embrace what computers are better at
than them. 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.
First, replace the PKZIP cipher with AES-SIV. AES-SIV could take an entire talk on its own,
but what's most important is its resistance to nonce, reuse, misuse. Even with AES-GCM,
if nonces are reused, failure can be catastrophic. 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. Also, replace the CRC-based key derivation function with Argon2. Again,
Argon2 is deserving of a talk all to itself, but what's important here is the resistance
Argon2 provides against GPU-based cracking. 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. And finally, replace asking the human to choose a password and just
choose one for them at random. 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. What seems to be often misunderstood about that demonstration, though, is the necessity
of the words to be random. 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. 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. And so, I can shrink the
search space for greater human usability. Okay. So, demo time. But keep in mind, this is supposed
to be boring. We're trying to solve real problems for the average person, so complexity is the enemy
of adoption. 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. On the first line,
I'm encrypting a file because it doesn't end in the magic.xc suffix it's looking for. There's no
need to pass in any other command line arguments because there aren't any. I see the path phrase
that was generated for me and the name of the encrypted file. And now I could email that file
to someone and call them with the pass phrase and they would follow the other lines. The file
is open for decryption because it ends in the magic.xc suffix and the user's prompted for the
pass phrase. Having supplied it, the file is decrypted and the name of the decrypted file
is displayed for the user. The lines after that demonstrate this proof of concept also works for
directory trees as well. But this is just a proof of concept and should not really be used anywhere
ever. So why did I do this then? 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. Remember that folks generally don't want third
party software when the first party one seems good enough. That was after all the basis for
antitrust suit against Microsoft. So governments may be in a position to drive change here. 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. I eagerly await any progress they make here.
But if this is a problem space that interests you, you don't need to wait. There are a couple
of other projects that are not just proof of concepts but are actually stable and interested
in real-world users. Magic Wormhole is an interesting human-centered approach to sharing
files directly over network instead of email. And Augie implements modern cryptography for
file encryption even if the user experience is not really intended for technical novices.
So thank you for your time and if you have any questions or comments for me, I've provided a few
links here. 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. If you don't want to play, if you just want to
play around with the code, you can find it there on GitHub. And if you'd still like to reach out,
my DMs are always open on Twitter. And thanks again. Thank you so much for joining us today,
David. That was very interesting. 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. Let's see. And this is
the last talk of the day. Yay! Do you have any thoughts on password expiration?
Do I have any thoughts on password expiration? I think that a lot of organizations have got
themselves into trouble by making them time-based rather than event-based. 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. 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.
Mm-hmm. Thoughts on minimum password length requirements?
That's an interesting question. 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? We're still more or less
comfortable to like, okay, 10 characters is something that someone can remember without
software to help them. 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. 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.
Yeah, that's great. And there was another question on password managers, but it sounds like you just
touched it right there. Cool. And then do you feel like Microsoft is already solving the password
issue with passwordless logins? And do you see that gaining widespread adoption in other applications
such as cryptography? I think they're certainly solving one part of the problem.
They're solving kind of the online service problem. 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. And so that's, again, where password managers and security
keys come back into the scope of things. 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.
Yeah. All right. Thanks for the talk. Very cool stuff. 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? Or do you feel like things are too difficult to make user-friendly as
it stands now? That's a hard question. In general, my preference is always to help improve existing
tools rather than to start from scratch. 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.
And that in their final judgment, in order for them to do what they felt was necessary,
they needed to build something from scratch. And I think there's nothing preventing projects from
cross-pollination of ideas, the possibility to reuse code. So yeah, there's no one-size-fits-all.
All right, well thank you for joining us today. I know there's a few more
questions that I might have missed in the chat. Hopefully we can get David in there
in Discord to answer any more that you have. Yep, I'll be there. Thank you for joining us. Thank you.