Keybase raises $10.8M

2. Most people do put enough personally identifiable information on their social media accounts. If you don't want to, that's fine, but you'll have to find some other way to identify yourself to people who you want to use your public key.

3. You can have Keybase manage it for you, if you want. Yes, of course there are problems with this, but it provides a reasonable compromise, especially if your threat model isn't a government entity (in which case, you're likely screwed anyway).

The truth is, most people have trouble working with more than one email account. Adding multiple sets of keys on top of it isn't going to make anything easier. At least with Keybase, I could get someone who isn't all that aware of security measures set up with public key encryption in a way they have a chance at using.

There's ideal, and there's better. Unfortunately, ideal has proven to be too onerous for people to use, but we can work on better.

> First, people should have multiple keys/identities by default

I feel like you can do this already, no? Just create different Keybase accounts for each identity. I don't understand how having a single keypair prevents you from managing your contact groups however you like. They seem like orthogonal problems to me.

> Second, matching a name with social media is the wrong way to lookup others. It only works if people put enough personally identifiable information (PII) on their social media accounts

Key verification is the problem in crypto. Like it or not, many people already put tons of PII online. It's a perfectly valid way to verify lots and lots of people. Perhaps it doesn't work for everybody, but it's clear that keychains don't work. This is a different strategy to solve the verification problem, and I think it's got legs.

> Third, leaving people to manage their own private keys is worse for security than having them managed by others.

I understand your point here, but I disagree. Given all the server hacking going on these days, I'd much rather not have a single point of failure. Or several large points of failure, in the case of your distributed system. The odds of someone hacking keybase.io or keyexchange.google.com seem much higher than the odds of someone attacking my phone or my desktop.

I think it's a mistake that keybase allows uploading and storing private keys.

> I think the winning solution will be: a distributed

Your idea doesn't seem to solve the verification problem. Keybase's strength is that in order to subsume someone's identify, you have to hack several of their accounts. That's much more difficult than hacking a single keyserver. How do you verify that the key I get when I search your crypto-DNS system for irq-1 actually belongs to you?

Multiple identities are trivial. Mirimir is just my primary persona for advocating privacy, anonymity, etc. Keybase links Mirimir's public GnuPG key to a few social accounts, and to an email address. Anyone who cares can validate all of those linkages.

I have another Keybase account under my true name, But it's linked to an entirely non-overlapping set of social accounts, with different friends etc. And there are other personas, similarly compartmentalized. Some of them never use English, for example, and display zero interest in privacy, anonymity, etc. Some hang out only on Tor hidden services. And so on.

While most of my personas are fully compartmentalized, a few are related. Mirimir, for example, looks like a simple pseudonym. And there's no reason why those "with nothing to hide" couldn't just use weakly compartmentalized pseudonyms. Facebook, Twitter, Hacker News, Reddit, etc could host the relevant keys, and all rely on the keybase API and proof structure. Facebook is already using GnuPG keys to secure system messages to users.

"Matching a name with a social media is the wrong way to lookup others" -- this is the one I take greatest issue with, because it's the way we know people now. All the people I collaborate with online now, I know them by those exact names. Coworkers, remote collaborators, friends on instagram, famous software engineers (whose work I might want to consume), even my own brothers... I know them by a set of these identities. This is how I know people.

To illustrate this point: if my own brother wrote me a message and posted it simultaneously on Twitter, Facebook, and LinkedIn, I would think "yeah, that's my brother." Moreover, and more importantly, if he left those posts up publicly, over time the strength of my conviction that he actually wrote the messages (and it wasn't a short-term compromise) would grow.

This works even for people you've maybe never met in real life. If hacker news user "jashkenas" announces on HN that he has a new version of CoffeeScript, I expect that's him. If he pairs it with a tweet, then I really expect it's him. The fact that this method works for possible strangers and loved ones is very powerful. Remember, this isn't just about secure messaging. If someone doesn't have any such identities, then there's always still the fallback: exchange an identifier in person.

The alternatives are so nasty -- in person meeting, coordinating enterprisey apps, and so on -- we'll never get anywhere with this kind of thing. The solution I think you are suggesting requires a lot of human effort to figure out if you have the person you want. This is one of the danger points of PKI. And one of the inconvenience points.

"Leaving people to manage their own private keys is worse for security than having them managed by others." Part of me wonders if you're just trolling. I don't understand this, and I've read your paragraph a few times. There is the confusion argument - that people don't understand how to manage them, which is a problem we're tackling. Our argument is that it's possible to build something usable (finally!) where people do in fact own their own keys.

But you go on to say "software glitches" and "updates" are dangerous for individuals who have device keys, and then suggest they'd be ok if their enterprises / social networks managed their private keys for them. In this case, you're talking about expanding the threats considerably, while still leaving client apps that need to be updated and do the work.

Assuming it /is/: a well known social media site called Facebook already has a space for GPG keys.

That doesn't mean keybase can't succeed and I do wish them luck though. First step: buy keybase.com, because people who don't know what encryption is don't understand .io domain names.

Key management is tough. OAuth and tokenisation are great solutions for authentication but applications like GPG and crypto-currencies will likely still require "proper" crypto. Smartcards feel like the now-old'n'clunky prototype/PoC implementation of something better. I can't help feeling like the banks and telcos could contribute to a solution if they could work more collaboratively.

I don't think the end solution is a proprietary, for-profit one. It needs to be open and accessible to everyone, instead of fragmented into competing walled gardens.

the idea being you mint a new keypair per service and the private keys are stored securely on your device (currently yubikeys but soon all devices will have a secure way to store key material (e.g., secure enclave, TEE, secure elements)), public keys get stored on the service you want to authenticate against.

This is news to me. Are there known side channel vulnerabilities for an arbitrary ubuntu desktop?

Good point - our stance was to protect from targeted code injections (by a coerced or hacked Google). But of course you're right, there's no point letting Google know at all.

I've made an issue to move font/css hosting off Google.

And intelligence agencies have been known to retain encrypted content for longer (in theory, forever): http://www.darkreading.com/risk-management/want-nsa-attentio...?

The older I get the more impressed I am with how prescient Scott McNealy was when he said: "You have zero privacy anyway. Get over it."

Still avoiding the UK like the plague right now...

http://www.businessinsider.com/uk-government-not-going-to-ba...

PGP support will continue, always, it's just that you won't need to have PGP on all your devices -- just the ones you use PGP on. Your PGP key will be part of a family of keys you're known by. If you install Keybase and have no idea what PGP is we don't make you get a PGP key.

By switching to device-specific keys via apps on every platform, we can solve security and convenience problem at the same time. As the blog post says, this can only work if you can bring pairs of devices together. Which has only been possible and convenient the last couple years.

I imagine you walk up to Marc and say, "Hey, we are building PGP for the world."

Some days later, $10,000,000 pops in to your bank account.

Edit: Would be considerate if the down-modders would provide an alternate scenario.

To be honest I haven't found their service to be useful in my day to day life. I am mainly inviting you out of sheer guilt, because I have been accruing invites and not using the service.

"Use your keybase account. There are insecure children in the US that write their passwords on post-it notes." ;)

Edit: I don't have any more!

Edit: 6 still left.