1
00:00:01,180 --> 00:00:03,560
All right, welcome back, everybody.

2
00:00:03,720 --> 00:00:08,160
Next talk up is File Encryption for Actual Humans by David Kane-Perry.

3
00:00:08,240 --> 00:00:09,500
Take it away.

4
00:00:09,900 --> 00:00:10,900
Thank you.

5
00:00:11,260 --> 00:00:14,460
All right, so welcome to File Encryption for Actual Humans.

6
00:00:14,460 --> 00: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.

7
00:00:20,020 --> 00: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.

8
00:00:28,240 --> 00:00:32,200
This project, however, has a bit to do with the previous job.

9
00:00:32,300 --> 00:00:33,360
I was onboarding with the U.S.

10
00:00:33,360 --> 00: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.

11
00:00:44,160 --> 00:00:47,380
This here is just the first of 58 pages.

12
00:00:47,580 --> 00: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.

13
00:00:57,520 --> 00:01:00,480
But email is fantastically insecure.

14
00:01:00,840 --> 00:01:04,600
I mean, the principal problem is that email is a store-and-forward protocol.

15
00:01:04,600 --> 00: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.

16
00:01:10,280 --> 00:01:13,400
But it requires trust in the operator of the intermediary.

17
00:01:13,400 --> 00:01:18,480
If green and blue can't accept the risk of trusting red, they probably shouldn't be using email.

18
00:01:18,880 --> 00:01:21,060
But wait, it gets worse.

19
00:01:21,060 --> 00: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?

20
00:01:26,780 --> 00:01:29,500
Because even no purple and gray are in the loop.

21
00:01:29,520 --> 00: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.

22
00:01:40,480 --> 00:01:43,760
Oh, but the list of intermediaries can't be known in advance.

23
00:01:44,460 --> 00: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.

24
00:01:51,660 --> 00: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.

25
00:02:01,140 --> 00:02:06,120
Aha, you might be thinking to yourself, I can solve this problem by sharing the file through a hosting service.

26
00:02:06,780 --> 00:02:07,920
Well, bad news.

27
00:02:07,920 --> 00:02:10,200
That model still collapses to sending an email.

28
00:02:10,200 --> 00: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.

29
00:02:16,980 --> 00:02:20,560
There are no shortcuts to turning an insecure channel into a secure one.

30
00:02:21,500 --> 00:02:26,260
Speaking of trying to turn an insecure channel into a secure one, a quick digression on GPG.

31
00:02:26,940 --> 00:02:28,740
It's worse than email.

32
00:02:28,740 --> 00:02:31,820
Unlike GPG, email is something that people want to use.

33
00:02:31,820 --> 00: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.

34
00:02:37,700 --> 00:02:41,820
And for different reasons, they're both highly averse to installing any third-party software.

35
00:02:41,960 --> 00: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.

36
00:02:49,040 --> 00: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.

37
00:02:55,020 --> 00:02:56,680
First, it's got to be an email.

38
00:02:56,680 --> 00:03:00,480
No signal or whatever other tool we would prefer to use.

39
00:03:00,740 --> 00:03:02,740
Second, no file hosting URLs.

40
00:03:02,740 --> 00:03:04,000
It's just as insecure.

41
00:03:04,000 --> 00: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.

42
00:03:10,560 --> 00:03:13,320
To borrow the southern US phrase, bless their hearts.

43
00:03:14,000 --> 00:03:15,820
Also, no third-party software.

44
00:03:15,940 --> 00: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.

45
00:03:21,460 --> 00:03:27,520
For your less sophisticated family members, even if they wanted to, could even manage it without your in-person assistance.

46
00:03:27,740 --> 00:03:30,500
And at that point, you no longer need to send them an email.

47
00:03:31,500 --> 00: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.

48
00:03:37,780 --> 00:03:44,080
While the plural of insecure channels is not synonymous with a secure channel, it may acceptably lower the risk.

49
00:03:44,120 --> 00:03:45,960
Unknown entities snooping my email?

50
00:03:45,960 --> 00:03:46,940
Unacceptable.

51
00:03:46,980 --> 00:03:50,080
Unknown entities snooping both my email and my phone?

52
00:03:50,080 --> 00:03:55,140
That could be highly probable for some, but my self-assessment leans towards low risk for me.

53
00:03:55,140 --> 00:03:57,760
So what tools are available by default?

54
00:03:58,480 --> 00:04:01,560
Well, PKZip is just everywhere.

55
00:04:01,560 --> 00:04:04,680
Windows, Mac OS, Linux, choose your BSD.

56
00:04:04,680 --> 00:04:08,200
You name it, they probably ship a zip tool with the installation media.

57
00:04:08,260 --> 00:04:12,580
But because of licensing issues, they won't be shipping the zip format that uses the AES cipher.

58
00:04:12,580 --> 00:04:15,460
Oh no, they'll be using the homegrown PKZip cipher.

59
00:04:16,120 --> 00:04:19,940
And oh boy, PKZip is so broken.

60
00:04:19,940 --> 00:04:21,800
Hashtag, never roll your own crypto.

61
00:04:22,040 --> 00:04:23,620
Shocking, right?

62
00:04:23,620 --> 00: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.

63
00:04:32,320 --> 00: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.

64
00:04:42,420 --> 00: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.

65
00:04:56,180 --> 00: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.

66
00:05:03,840 --> 00: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.

67
00:05:12,600 --> 00:05:17,020
And it's those kind of human-computer interaction challenges that really undermine password-based security.

68
00:05:17,160 --> 00:05:21,860
Here's a quote by Dave Kearns paraphrasing something Winston Churchill said about democracy.

69
00:05:22,040 --> 00:05:27,280
Passwords are the worst form of authentication except for all those other methods that have been tried from time to time.

70
00:05:28,220 --> 00:05:29,500
500 years.

71
00:05:29,500 --> 00: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.

72
00:05:35,940 --> 00:05:41,120
keyboard-based password, assuming a guess rate of 47 quadrillion passwords a year.

73
00:05:41,300 --> 00:05:44,840
But it means humans having to deal with credentials that look like this.

74
00:05:44,840 --> 00:05:48,960
This isn't something I could read over the phone to someone or even put in a text message.

75
00:05:48,960 --> 00:05:54,380
That character next to the Q, is that a capital I or an L or the pipe character?

76
00:05:54,400 --> 00:05:57,000
These are good for computers, but they're bad for people.

77
00:05:57,480 --> 00:05:58,540
700 years.

78
00:05:58,540 --> 00: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.

79
00:06:06,020 --> 00:06:09,860
Again, assuming a guess rate of 47 quadrillion passphrases a year.

80
00:06:10,600 --> 00:06:13,380
And instead, we're dealing with strings that look like this.

81
00:06:13,380 --> 00: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.

82
00:06:24,440 --> 00: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.

83
00:06:31,020 --> 00:06:36,640
Humans are really bad at pretending to be computers and consistently fail the reverse Turing tests that are thrown at them.

84
00:06:36,900 --> 00:06:39,040
Like generating random strings.

85
00:06:39,040 --> 00:06:44,620
Computers are great at this, but we keep asking people to do this, despite overwhelming evidence that they simply can't.

86
00:06:44,620 --> 00: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.

87
00:06:51,820 --> 00:06:56,360
Even if they could, password policies ensure that cryptographically random strings won't be accepted.

88
00:06:56,360 --> 00: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.

89
00:07:08,200 --> 00:07:13,800
Another fun fact, at a previous job, we tried to crack the employee passwords that had a similar policy in place.

90
00:07:13,900 --> 00:07:19,320
The most popular cracked password, the company name, followed by the current year, followed by an exclamation point.

91
00:07:19,440 --> 00:07:22,780
It was easy, then, for us to predict what we'd find the following year.

92
00:07:23,580 --> 00:07:26,740
Of course, generating one is just half the challenge.

93
00:07:26,980 --> 00:07:30,180
Do you remember the six-character password I showed a few slides back?

94
00:07:30,180 --> 00: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.

95
00:07:35,940 --> 00: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.

96
00:07:43,440 --> 00:07:48,060
So one of the tricks we've learned is that we use those little trouble tokens everywhere we possibly can.

97
00:07:48,060 --> 00:07:53,300
Folks will figure out their quote-unquote one good password and reuse that bugger everywhere.

98
00:07:53,340 --> 00: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.

99
00:08:04,480 --> 00:08:10,400
So let's stop asking humans to be computers and embrace what computers are better at than them.

100
00:08:10,400 --> 00: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.

101
00:08:18,840 --> 00:08:22,420
First, replace the PKZIP cipher with AES-SIV.

102
00:08:22,520 --> 00: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.

103
00:08:29,800 --> 00:08:34,180
Even with AES-GCM, if nonces are reused, failure can be catastrophic.

104
00:08:34,180 --> 00: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.

105
00:08:42,540 --> 00:08:46,180
Also, replace the CRC-based key derivation function with Argon2.

106
00:08:46,180 --> 00: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.

107
00:08:53,420 --> 00: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.

108
00:09:03,000 --> 00:09:14,430
And finally, replace asking the human to choose a password and just choose one for them at random.

109
00:09:14,590 --> 00: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.

110
00:09:24,290 --> 00:09:29,270
What seems to be often misunderstood about that demonstration, though, is the necessity of the words to be random.

111
00:09:29,530 --> 00: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.

112
00:09:38,950 --> 00: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.

113
00:09:46,090 --> 00:09:50,690
And so, I can shrink the search space for greater human usability.

114
00:09:51,750 --> 00:09:52,430
Okay.

115
00:09:52,430 --> 00:09:53,370
So, demo time.

116
00:09:53,370 --> 00:09:56,110
But keep in mind, this is supposed to be boring.

117
00:09:56,250 --> 00:10:00,950
We're trying to solve real problems for the average person, so complexity is the enemy of adoption.

118
00:10:01,770 --> 00: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.

119
00:10:08,530 --> 00: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.

120
00:10:13,470 --> 00:10:17,430
There's no need to pass in any other command line arguments because there aren't any.

121
00:10:17,530 --> 00:10:21,130
I see the path phrase that was generated for me and the name of the encrypted file.

122
00:10:21,130 --> 00: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.

123
00:10:26,090 --> 00: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.

124
00:10:32,950 --> 00:10:36,810
Having supplied it, the file is decrypted and the name of the decrypted file is displayed for the user.

125
00:10:36,950 --> 00:10:41,130
The lines after that demonstrate this proof of concept also works for directory trees as well.

126
00:10:41,750 --> 00:10:46,710
But this is just a proof of concept and should not really be used anywhere ever.

127
00:10:47,070 --> 00:10:49,830
So why did I do this then?

128
00:10:50,470 --> 00: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.

129
00:11:05,210 --> 00:11:11,090
Remember that folks generally don't want third party software when the first party one seems good enough.

130
00:11:11,250 --> 00:11:14,530
That was after all the basis for antitrust suit against Microsoft.

131
00:11:15,370 --> 00:11:18,450
So governments may be in a position to drive change here.

132
00:11:18,450 --> 00: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.

133
00:11:29,270 --> 00:11:31,950
I eagerly await any progress they make here.

134
00:11:32,250 --> 00:11:35,870
But if this is a problem space that interests you, you don't need to wait.

135
00:11:35,870 --> 00: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.

136
00:11:41,710 --> 00:11:47,290
Magic Wormhole is an interesting human-centered approach to sharing files directly over network instead of email.

137
00:11:47,730 --> 00:11:54,910
And Augie implements modern cryptography for file encryption even if the user experience is not really intended for technical novices.

138
00:11:55,790 --> 00: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.

139
00:12:00,570 --> 00: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.

140
00:12:06,290 --> 00: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.

141
00:12:10,290 --> 00:12:12,990
And if you'd still like to reach out, my DMs are always open on Twitter.

142
00:12:12,990 --> 00:12:14,090
And thanks again.

143
00:12:16,640 --> 00:12:19,360
Thank you so much for joining us today, David.

144
00:12:19,460 --> 00:12:21,360
That was very interesting.

145
00:12:24,620 --> 00: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.

146
00:12:46,300 --> 00:12:47,040
Let's see.

147
00:12:47,040 --> 00:12:49,920
And this is the last talk of the day.

148
00:12:49,920 --> 00:12:51,100
Yay!

149
00:12:56,310 --> 00:12:59,330
Do you have any thoughts on password expiration?

150
00:13:00,130 --> 00:13:02,370
Do I have any thoughts on password expiration?

151
00:13:03,270 --> 00:13:11,510
I think that a lot of organizations have got themselves into trouble by making them time-based rather than event-based.

152
00:13:11,530 --> 00: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.

153
00:13:23,050 --> 00: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.

154
00:13:39,690 --> 00:13:41,690
Mm-hmm.

155
00:13:43,230 --> 00:13:46,930
Thoughts on minimum password length requirements?

156
00:13:48,590 --> 00:13:50,250
That's an interesting question.

157
00:13:50,250 --> 00: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?

158
00:14:04,950 --> 00: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.

159
00:14:11,150 --> 00: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.

160
00:14:20,070 --> 00: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.

161
00:14:37,910 --> 00:14:38,810
Yeah, that's great.

162
00:14:38,810 --> 00:14:44,250
And there was another question on password managers, but it sounds like you just touched it right there.

163
00:14:44,250 --> 00:14:44,990
Cool.

164
00:14:45,290 --> 00:14:51,310
And then do you feel like Microsoft is already solving the password issue with passwordless logins?

165
00:14:51,310 --> 00:14:56,610
And do you see that gaining widespread adoption in other applications such as cryptography?

166
00:14:57,390 --> 00:15:01,210
I think they're certainly solving one part of the problem.

167
00:15:01,210 --> 00:15:04,290
They're solving kind of the online service problem.

168
00:15:04,370 --> 00: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.

169
00:15:17,850 --> 00:15:24,990
And so that's, again, where password managers and security keys come back into the scope of things.

170
00:15:25,050 --> 00: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.

171
00:15:48,090 --> 00:15:48,830
Yeah.

172
00:15:50,790 --> 00:15:52,010
All right.

173
00:15:52,170 --> 00:15:53,170
Thanks for the talk.

174
00:15:53,170 --> 00:15:54,090
Very cool stuff.

175
00:15:54,090 --> 00: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?

176
00:16:03,690 --> 00:16:08,350
Or do you feel like things are too difficult to make user-friendly as it stands now?

177
00:16:09,550 --> 00:16:11,310
That's a hard question.

178
00:16:11,370 --> 00:16:18,910
In general, my preference is always to help improve existing tools rather than to start from scratch.

179
00:16:19,270 --> 00: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.

180
00:16:30,550 --> 00: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.

181
00:16:39,470 --> 00:16:47,850
And I think there's nothing preventing projects from cross-pollination of ideas, the possibility to reuse code.

182
00:16:48,190 --> 00:16:51,240
So yeah, there's no one-size-fits-all.

183
00:16:53,650 --> 00:16:56,550
All right, well thank you for joining us today.

184
00:16:56,550 --> 00:17:00,450
I know there's a few more questions that I might have missed in the chat.

185
00:17:00,530 --> 00:17:05,470
Hopefully we can get David in there in Discord to answer any more that you have.

186
00:17:05,650 --> 00:17:06,850
Yep, I'll be there.

187
00:17:06,990 --> 00:17:08,710
Thank you for joining us.

188
00:17:08,710 --> 00:17:09,530
Thank you.