The a16z Show - a16z Podcast: Establishing Online Identity is Hard -- It Shouldn't Be

Episode Date: August 17, 2015

As more and more of what we do for fun and work- happens online, establishing identity becomes ever more critical. Whether it’s for dating or sending money, you want to trust that not only are you interacting with the person you think you are, but that your messages (or money) are in fact reaching the right person -- and only them. Sounds simple, but with an internet and computers in between, a lot can go wrong -- whether by accident or malicious design. A16z’s Chris Dixon, and Max Krohn, co-founder of the encryption startup Keybase, examine the problem in this segment of the pod. What makes cryptography so hard to use, what approach Krohn and the Keybase team are taking, and why crypto “key parties” are not what you might think. The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments and certain publicly traded cryptocurrencies/ digital assets for which the issuer has not provided permission for a16z to disclose publicly) is available at https://a16z.com/investments/. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information. Stay Updated:Find a16z on YouTube: YouTubeFind a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

The content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Welcome to the A16Z podcast. I'm Michael Copeland. As more and more of what we do for fun and work happens online, establishing identity becomes ever more critical. Whether it's for dating or sending money, you want to trust that not only are you interacting with the person you think you are, but that your messages or money are, in fact, reaching the right person and only them. Sounds simple, but with an internet and computers in between, a lot can go wrong, whether

by accident or malicious design. A16Z's Christyxson and Max Crone, co-founder of the encryption startup Keybase, examine the problem in this segment of the pod. What makes cryptography be so hard to use, what approach Crone and the Keybase team are taking, and why crypto key parties are not what you might think. Chris Dixon starts us off. So you and Chris co-founded Keybase, and prior to that, you guys were the co-founders of OKCupid and Spark Notes. Can you just tell us a little bit about your background and how you started Keybase? We started a little bit over a year ago, just because we were convinced that in the future, people would really see a need for mapping, what they considered notions of identity that computers could understand. Chris and I got

together and we thought we had a pretty good background between the two of us for tackling this problem. It's a problem that on the one hand has some cryptographic and security components to it, as you can imagine. But on the other hand, it also has a lot of social networking and social engineering aspects to it as well. And obviously, as co-founders and long-time engineers and product designers at OKCupid, we thought we got a lot of exposure in the past running that side of the business and that side of what we thought would be important in making PKI or a public key usable for more people. And at OKCupid, though, it seems so obvious now at the time, there was a lot of coercing people and more or less asking them to use their product because they didn't think it was right

for them. That could have been because attitudes were different back then, or it could have been because the site when we started it was too small. So we basically spent about nine years in OkCupid getting the site so it would be big enough and work as a dating website, more or less fighting with people the whole way because it was hard to attract users for a lot of OkCup's history. If you look at crypto apps, a lot of the same things are at play. I mean, obviously, people should be using the stuff and it will definitely make their lives better. The question is, you know, they understand that and can be motivated to use the products? So in that respect, we think that our experience at OCP is very helpful for moving

into something like getting crypto to be popular for more people. There's a lot of common elements of user recruitment and user onboarding and making people like the product, even though, you know, maybe they thought it wasn't for them when they first heard about it. So you said it's about, you know, obviously, encryption and social identities. Can you describe for people that don't know just what that means exactly, like, in specific terms? Yeah, sure things.

There are two things you really can do with this technology that's really fundamental and so deep in terms of what people might do online. But let's just do with one of them first. So one of them is this idea of encryption. So, you know, Chris, imagine I want to send you a message. over the internet, and I didn't want anyone to be able to read it in between your computer and my computer. So it doesn't matter what application I'm using.

It doesn't matter if we're video conferencing or sending email. What really has to be done before we get off the ground is I need to convince my computer that it's talking to you and that's someone who's pretending to be you. And this is a big problem. It's a social problem and that, you know, you could have a lot of people pretending to be you online. And it's also a technological problem. And that is if someone had hacked any of the social media accounts you own or any of the things that you use to prove who you are.

I mean, that would be a way that that person could receive messages for you, even though they're intended for you. So the first thing that any crypto really needs for me to have a person in my head who I want to talk to, and then tell my program, whatever computer program I'm using to talk to that person and not to someone else out there. So that's what Keybase is trying to solve. And before there were social networks, people would do this with these so-called key signing parties. Can you talk about this really? It sounds very primitive now, but it's funny because it was the best practice until we had Twitter and Reddit and Facebook. Yeah, absolutely.

So I think the first attempts that public key crypto got off the ground in the 90s when there was the first iteration of the so-called crypto wars. And I think back then there was a lot of distrust of any sort of infrastructure that wasn't just a complete. computer you ran in your own home. And so what this means is that if people wanted to exchange identities, they would show up in person with a bunch of random strangers and check each other's driver's licenses. And also, it all comes to the conclusion that the 20 people in the room with with them were the 20 people at the driver's license. So you see the driver's license and then you get the and then that person shows the driver's license gives you their public key and then you take the public key with you and then you know from then on whenever you want to send a message to the person

that you met in person with the driver's license, if you encode it with that message with that key, only that person can read it. Yeah, that's exactly right. Because the whole basis of all of this is you have to pair a person to a public key, right? And so in the old days, or, you know, being the 90s, there was no way to do it or to people trust it except for physical, in-person, driver's license kind of parties. Sounds like great parties. Yeah, you can look at pictures of them online.

But, yeah, and, you know, that was like the first kind of level of the graph. And if you go up a couple of levels, you'd say that, well, you know, Chris and I, you weren't at the key signing party, but, you know, we know someone in common who was. And so in a way, it's a little bit of a friend of a friend type of graph. And that's so obvious now in terms of Facebook, but trying to recreate that offline through these key signing parties. I think in retrospect, it was a really cool idea that just never hit critical mass. It's probably one of the reasons why it failed. Yeah. And so going back to you were describing Keybase, the idea then, is that now, you know,

Now I know you as, you know, as Max Taco on Twitter. Is that your Twitter handle? That's exactly right, yeah. Or let's say I want to communicate with a journalist who I follow on Twitter. And I know his or her Twitter handle or I want to share a file with someone I met on Reddit or I want to, or Facebook is an obvious one, et cetera. You know, in some ways now the Twitter handle is almost more verification than their driver's license. And so a lot of these people I interact with, at least on Twitter and other places. all the time, and I might read their articles in New York Times, I've never met them in person.

Yeah. I'm not sure how much meeting in person would really add to the verification, right? Yeah, you're totally right. And as these online communities get bigger and more important to just the way we communicate, the notion of identity is changing. And so it's almost more important now what your online identity is more so than what your wallet says, but your driver's license says. Absolutely.

And so we're seeing more and more in the press, it seems like almost on a daily basis, there's a massive security issue. Yeah. You know, everything from the Sony hack, which was Sony Pictures, had all of their email stolen and published online. Apple, ICloud hack with a bunch of celebrities had their private photos stolen and put online. Yeah. The target breach, it just goes on and on. Can you talk more so broadly about what you think is happening and, like, why is that happening and what do we need to do to fix it?

Yeah, I think for the last 10 years or last 15 years since the Internet has really caught on, we can just building systems in the most obvious way possible. And the most obvious way possible is to just put a bunch of servers somewhere in a closet somewhere and to do your best to make sure no one breaks into those servers and just put all the important data in those servers and then trust you'll make the right decisions of who to send the data back out to on the other end. And that's the way all of the major social networks are built. That's the way almost everything online that we use today is built.

And if you were to tell people 40 years ago that's the way we're building systems, they would have probably not been able to believe it. They would have said, that is madness. That is not the way you should build any system if you care about what's actually being put onto the server and being judicially released to people who are authorized to see it. So the way we should be building systems is that if the server doesn't need to see the data or access the data that you're putting onto it, then it just shouldn't.

There's no reason why it has to see it, then the data should be not available to the server in plain text. Yeah, basically the assumption has been that, It's so-called perimeter defense, right? Which is, as you say, you put it in the closet. It's a big mess. And once you get in the closet, it's, you know, you get everything. But we hopefully will have the perimeter defended enough, meaning, you know, just sort of like the building, you got these giant piles of gold sitting there. But we have some security guards around the building.

And as long as they can do their job, we're great. That was the model up until now. And it turns out that there's people inside the building that are stealing the gold, that there's a whole bunch more ways inside than you think. You know, one of the big things changes now is that a lot of the perimeter defenses were built under the assumption that people would be using kind of replicated attacks like viruses as opposed to customized attacks, which is what we're seeing now, where people are, you know, a gang of hackers are mapping out an organization and doing spearfishing and all these very customized attacks to get through the perimeter. And then once they get in there, boom, you know, it's game over. Yeah, exactly right. It's a perimeter with about a thousand different gates on it where maybe there are, you know, 30 people manning all. thousand of those gates. And it's a tough problem. I mean, the more data you have, the more systemans you probably need to run the service, and the more likely one of those systemans

is going to fall down and not do their task well. So it's, you know, it's not that I don't think that the big service, the big cloud providers have the best intentions, because in general I think they do, it's just that they've chosen to do a job that's basically impossible, that no one can really do relative to all the threats that are lined up against them. With Keybase's architecture, so if I am a keybase user, and you're, we've talked about this publicly you're building some apps, some native client apps for mobile and for desktop. They let people do text messaging and file sharing and things like this. If I use your service and you guys get hacked, what happens?

Can you explain how that's different with Keybase versus kind of the traditional architecture? Yeah, that's exactly right. The basic idea of Keybase is that whenever I send data to other people and I want the other people to receive it and know in between, then all the infrastructure in between just is not able to see the plain text data. They just get to see the encrypted data. And so what that means if I want to send a file to you, Chris, is I first look up your public key, I encrypt the data with your public key, and then put that encryption on the server. So therefore, if anyone ever breaks into the server, all they really get is a bunch of encryption.

And unlike with other systems, the key you need to decrypted data is just not on the server. The only person who has a key is the phone in your pocket or the desktop in your office. And so, therefore, there's nothing you could do. in the server or infrastructure or anywhere in between to recover that message that I've tried to send you unless you've broken the crypto, which we believe is basically not done yet, that no one's been able to break the crypto. This is a totally other way of building the system where, in the worst case scenario, if everything about key basis and infrastructure is blown wide open, there's really limited damage, and in fact, we don't think there'd be any damage. And that's the way we're designing the system. That's one aspect of it. Now, if you have a more advanced attacker who,

broken to Keybase and started doing sophisticated things in our infrastructure, like let's say, you know, Chris, you had decided to throw away your iPad and add an out an new iPhone or something, and the server was supposed to propagate that message to other people. And a sophisticated attacker might say, well, I can't read the data that Max is trying to send Chris, but I can mess with other people so that they don't have the right idea as to what Chris's devices are right now. So that would be a slightly more sophisticated attack that someone could do if they owned our servers, but we're also designing countermeasures for those types of attacks as well.

So once we eliminate the basic attack, we have to also eliminate these more subtle attacks, but that's also part of the architecture that we're building. There's often, one of the reasons things that security online fails is that it's hard to use, right? I just think about my passwords, right? Like people should be using strong passwords, two-factor authentication. I think most people have been told that and know that. A lot of people don't do that. And that's because it's a pain, you know.

You can't remember these passwords. They're hard to type. You have to log in all the time. Do you think it's just a fundamental tension there, I guess, between usability and security? And it feels like a lot of the security community just tries to push the burden onto users and say, well, it's the user's fault for not doing all of these complicated measures when, in fact, you know, of course the users mostly aren't technical and aren't security experts. What do you think about that?

Well, I think you're totally right. Let me just add my condemnation to the password system that probably many other people have mentioned up until now. The idea that you type this string, and that's what identifies you, is really an old idea that probably isn't robust enough to do with the current level of stress that we have, and also to be very useful on your iPhone, right? When you're typing on a keyboard, you have to type a 12-letter passwords. You're probably not very happy at all when it's going on. So one solution to the feasibility problem is just, first off, to harness the power of the devices that we're using more and more. So I think the Agile does a product one password does a really good job of it. this where they maybe they unlock your your passwords for all the sites you use,

which is your thumbprint on iPhone. And that's actually a really good solution because it means that for someone to steal all your passwords, they have to steal your phone and also be able to hack your thumbprint. So I think solutions like that are really good and potentially a solution to the password problem. I think a key feature of such a solution is to take advantage of the technology that the devices are giving you and not just pretend the devices are like kind of a small version of your computer.

So I think that's one thing that's going on. I think that in a world in which Keybase has a lot of penetration, we might say the password is just the wrong idea altogether, what you ought to be doing is signing a statement saying, on Max, and I wanted to log into the service, and the service would just have your public key, you know, Max is identified with this public credential, and as long as he's able to sign a statement with the corresponding private key,

I'll let him into the service. And so that's actually a far superior way to log into a system. And, you know, programmers who use SSH have been doing this for years. They don't type passwords anymore. They just do private key signing when they sign it to servers. And this is something that everyone should have access to, not just programmers. And so that's one of the real promises of getting public key crypto in the hands of more users. That, you know, something that just as basic as passwords now become no longer important

and hopefully authentication becomes a lot easier. That's one of our many hopes for Keybase. You're planning to release your applications as open source and let other people build apps on top of Keybase. Can you talk about kind of how you think about that and how you think about sort of the open source community and developer use cases? The first thing that's really important for us is that because we're building software that we think people need to trust. There's no possible way that people can trust us unless they get to see what the code actually is and how the software we're writing is using crypto and is using the various things that we talked about, you know, verifying your public identities.

And unless people have the ability to look inside the software and verify that it's doing what we say is doing, there'd be no reason for anyone to trust us. So I think for that one reason alone, it's crucial that as we build Keybase or as people build security apps, that they're able to look inside the application

and see exactly how it works. So, I mean, and that's just one thing I can say for the philosophy that we have on the team in terms of building Keybase. The other thing is that, I mean, we've got in a really good response so far with just our little demo app that we've been running from open source contributors and people who use open source tools all day and obviously would

like to contribute and would like to look into how our code is working and build their apps on top of it. And if we were to just kind of do the old-fashioned thing, it'd just distribute a closed source binary that people couldn't really pry into. We'd be cutting off all that goodwill and all the willingness for people to experiment with the software and build stuff on top of it. So that's the second thing. And I guess, you know, to be a little bit more specific, what people want to build with Keybase, I think there's so much work that we're putting into getting this thing to work properly, both in terms of verifying your public identities and managing your secret keys, that this is just basic plumbing that you need nowadays to build a good application.

And so we really hope that a lot of other app developers can exploit all the work. Exploite might be the wrong word, but benefit from all the work that we've done without having to reinvent itself. And I think the status quo is now, I mean, a good analogy would be like, hey, you want to write Photoshop with photo sharing, you know, you first have to implement TCPIP before you can get that done. I mean, that's kind of the world we live in right now with regard to crypto. So if you wanted to, you know, make a Photoshop plug-in where potentially you want to share photos secretly with your friends, then you basically have this ugly level of having to

re-implement a lot of stuff that you don't care about that doesn't make any difference to you in terms of an application developer. So we want that to be available of service or a library. We spent a lot of time just dealing with what's probably being called now growth hacking. And so a lot of the ideas we had towards making OKCupid bigger had very little to do with dating. We had to do with all such other things that we could entice people to show up at OKCupid and then kind of route them into a different part of the service they were using.

That turned out to be dating. That was like the OKCupid experience. That's basically what we did for six years before people had heard about us. We have to come up a lot of different independent growth hacks. And, you know, what does it take to get a crypto or security into more people's pipelines? Well, or workflows. I think the first thing that you've got to get right is you have to have the software, you know, and work well, even if the person you're trying to communicate with hasn't signed up yet.

And I think that's where a lot of crypto software just dies. It's like basically step one. And we have to get that experience right, and we have to get that experience common enough for people to use, that they wind up bringing the people, recruiting people for us by way of the application. And I think there's just no other way to get a service like this to get good adoption. And so that's been one of the huge problems with PGP up until now that the typical experience is you try, you say, okay, this week I'm going to move all my email to PGP. And, you know, Monday at 930 to say, oh, man, the first person I want to email doesn't use PGP, what do I do now?

I need to say, well, I guess this experiment failed. And so that's something we can't have happened. We have to really allow the operation to go through as far as possible, as far as the sender is concerned, and then get the receiver onboarded also with minimum friction. And I think unless an application does that, it's doomed to fail. So that's part of the challenge. And that's kind of where the usability experience from OKCupid

is really coming in in terms of what we're building. I think we're intending for the first users of this product to be programmers and technical types. And that's not our long-term vision, just to be limited to that audience, but we think of a primary set of users, and we already have a small set of users of our current kind of trial products online now. They tend to be security professionals, crypto professionals, programmers. But we think there's tens or hundreds of millions of people who meet that description, people who know that they should be using crypto and they know that they should be encrypting,

but just don't have the first idea or don't have the first clue as to where to start. And you can ask anyone who's programmed before, like, you know, have you ever used GPG? Have you ever read the man page for GPG? And they'd look at you like, of course not. I mean, are you kidding me? And it's not because the software is like,

the software does its job really well, but it's just not for anyone but the most sophisticated computer practitioners now. And so we wanted to bring that bar are way, way, way, way, way you down. So even if you know you should be using PDP or something like it, we're going to do all the heavy lifting for you, and you're just going to basically use the tools you used to use much the same way you did before. So that's part of the vision right there to try to go after people who are, you know, technologists are slightly technically

savvy. And from there, we think there's obviously the possibility to go out a lot further, but that's definitely the group we want to try to start with. All right, Max. Thanks a lot for your time. Thank you, Chris. I enjoyed it.