Hacker News Reader

1. You can set up multiple Keybase accounts if this is an issue for you. It doesn't seem like that much of a problem.

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.

Note that recent .gov data breaches now show in public what we already knew, that once someone has your private data (like private key) then everyone has it eventually, except perhaps for the general public, for a limited time.

This insight factors into another criticism of ops list of problems. IF we lived in a world where all data wasn't shared and merged, then this could be used as a tool to help FB and twitter and .gov do a merge. But we can assume the merge has already happened and the data is near perfect. Therefore the sole remaining benefit of not putting PII into social media etc is the general public / private citizens have no idea who I am so they can't send me secure email. This sounds fairly useless, if every .gov and .com and criminal with a copy of breached data know exactly who I am and who my accounts are.

You see there's been an inversion in security, that some people can see and some people cannot yet see, future being unevenly distributed and all that. If we didn't live in a total surveillance Orwell society, then a tool to make it microscopically easier to connect the dots would be bad despite its good parts, but given Big Brother's infallibility, eliminating the tool because it might help (infallible) Big Brother in a very small way that BB doesn't need anyway, only eliminates the small amount of known positive that the tool does provide.

I have a keybase account and its pretty awesome and well implemented. Cool! I never use it because the use case of randomly sending encrypted stuff to people I don't already know doesn't come up very often. But if I had to, it is pretty slick...

Interesting points. The below is a friendly disagreement from someone passingly interested in this field.

> 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?

First, Keybase is not just a website or app. It's an API, which happens to have them. Look at my keybase proof at https://news.ycombinator.com/user?id=mirimir The key is at https://keybase.io/mirimir, but it could just as easily be at http://mirimir...onion or wherever.

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.

> Multiple identities are trivial. ... linked to an entirely non-overlapping set of social accounts, with different friends etc.

That's not trivial, and it's certainly won't be the default, normal thing everyone does. Instead Keybase will encourage a single identity linking multiple accounts. This is fundamentally bad.

Having an identity and associated public keys that are fully validated is essential in many contexts. Let's say that I'm using a GitHub project, supposedly from a well-known Debian developer. Or let's say that I'm adding the Tor Project repository to Debian, in order to build the latest alpha release. Without well-known and readily validated public keys, how would I know what I was actually getting?

I agree that it's unusual to have multiple independent personas. It's quite common among my cohort, in order to provide deniability. Given the surveillance clusterfuck that's developing, deniability is becoming essential for everyone, even if they don't yet realize it. That will be especially important for young people, who are being profiled virtually from conception.

It does take some technical skill to establish multiple independent personas. One typically uses Linux and/or *BSD, virtualization, VPN services, Tor, Bitcoin, and so on. But getting up to speed only takes a few weeks.

You laid out a number of points there, and I think some of them are indicative of what's really holding back security for the masses.

"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.

To use your example, your brother posts a message on Twitter and you don't know your brothers Twitter username. If you're confident that it's your brother posting, then there's no problem. If you're uncertain that it's your brother, Keybase will let you verify it's him -- but that's a problem. Imagine a political dissident living in a dictatorship and it's the government who uses Keybase to match a Twitter username to a Facebook account.

We don't want accounts tied together. People need multiple identities online.

How do you get a persons key, and how do you know it's the right key? I think the answer will work like email addresses do now: someone will tell you a little info (name + hash@org) and you'll lookup their key.[0] Then you'll verify it as appropriate to the situation. That kind of system would allow and encourage multiple identities, and doesn't encourage posting PII.

To "bring public key crypto to everyone" you don't need to build this kind of directory (where you verify accounts.) You can instead get companies to participate in a PKI that they control (like they control email, DNS, http, etc..) and then they'll integrate it into existing software, provide it to users, experiment with UX and client designs, etc... Making an open source, server-side solution lets you turn 'Sign in with Facebook' into an ally that not only gets Facebook to provide keys and integrate crypto, but invest in servers and software.

Last, many people share a sentiment that a private key shouldn't leave our computers or phones (or fobs) to be managed by others. It's a reasonable attitude, but I think getting "crypto to everyone" and widely implemented is more important, and a managed system today doesn't preclude unmanaged keys in the future.

[0] To expand on this example: I'm irq-1 ff38a9@keys.news.ycombinator.com, and at work I'm Alice 23ff45@work. If you lookup hash@org and find a string that looks right (a username or real name) then you get their public key. You have some confidence it's the right person, and are free to verify it further with any other means.

I am with you 110% that people need to be able to have multiple identities online that are not linkable. That does not mean they should not be able to link multiple accounts to a single identity.

That is to say, "one identity per person" is wrong; "one identity per account" is also wrong. Both of these in the sense that they should be permitted if that is what the person desires but should not be expected or (especially) enforced.

> Second, matching a name with social media is the wrong way to lookup others.

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.

I think each identity is going to need multiple keys too. The key in the secure element on my smartphone may well be different to the key on my Yubikey. There will also need to be a robust mechanism for revoking keys, if/when they are compromised/lost.

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.

you've essentially described what google is trying to do with gnubby/u2f, now hamstrung by FIDO and converging UAF standards. If you are interested a high level explanation is here: https://docs.google.com/presentation/d/16mB3Nptab1i4-IlFbn6v...

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.

Great response. Do you think there's a way to monetize this proposed solution?

I like the idea but I also think it can be fully distributed - something like bitcoin/block chain