[niftich]

A good article that covers what Keybase is, where they came from, what they try to do, and where they're trying to go -- although you couldn't tell from the headline. As in the article body, Slack is namedropped just for effect; Keybase Teams being a decent proof-of-concept of a popular kind of application to show that the ideas behind Keybase can be used to build real products.

That being said, Keybase has been moving more and more towards building these higher-level services on top of (and app-wise, deeply integrated into) their core offering: Chat, File locker, etc; presumably other than delivering value these offerings make the company easier to position in the grand graph of services, and more palatable for raising capital or as a future acquisition target.

[malgorithms]

When we started Keybase, it was a hobby project to address shortcomings of PGP. Max and I both had just downloaded software packages and wanted to verify them, and it took us hours. At least one of them was bitcoin; I recall staring in awe as Max showed me the countless Gavin Andresen impostors on the popular PGP key servers.

We really thought we'd stick up the Keybase directory, make some basic scripts, and move on.

Upon further review and growing popularity, we realized we'd hit a nerve but only solved one of 3 problems related to public key infrastructure.

(1) the identity problem; this means think of a PERSON, and end up with a key. This really is what started Keybase. It was made possible because of how identity has changed in recent years. Whether you're following a famous developer or you're looking up your own sibling, odds are in 2017 you know a public definition of them: a Twitter account, Reddit account, Facebook, etc.

When attacking point 1, we made it a lot more than just posting a fingerprint. We needed these proofs to be bidirectional. It's not just that you should be able to start with a Twitter account and get a key; you should be able to start with a signed statement and end up on the Twitter account. We also attacked revocation and other issues.

But really, there were 2 big missing pieces:

(2) multi-device key management; the OLD shitty story was having one private key that you moved around from device to device. This was never an acceptable solution for most people. What the heck is a private key? How do I move it around? What if just one of my devices is compromised? And so on.

In 2015 when we decided to commit to Keybase, smartphones were poised to solve this. They solved this by guaranteeing that whatever 2 devices you have, you can always bring them together. So you should never have to move a private key around again. In the mobile era, you can bring 2 devices together and declare they're both you. Technically, underneath the surface, device #2 generates its own key pair, and device 1 signs the new public key, and device 2 countersigns this, and all this goes into an immutable chain (by signing the hash of the last identity change).

This means you don't need to understand what a key pair even is. It feels roughly the same as when your bank tells you to grab your phone in order to log in.

And if you have a compromised device, your identity isn't destroyed.

This was the 2nd thing we wanted to tackle.

Finally, to address your point, number 3.

(3) all the GUIs around PKI really kind of sucked. There were some standalone chat apps that were good, but nothing that got people building a real graph of keys and identities, so they can do whatever else they wanted. For a PKI to work, people needed usable software on every platform. And it couldn't be constrained to people in your phone book, where you needed to securely exchange a phone number first.

We think the basics of a usable PKI are:

   (1) to know who you're talking to (and to trust teams)
   (2) to be able to share data, securely, on any platform

If Keybase offered that, whether or not it felt like a "Slack-killer," you could secure all the other aspects of your life. Everyone uses different crypto powered apps now: SSH, IPFS, Signal, bitcoin, ethereum, etc., and it's so annoying to get started. Keybase actually makes all of them easier, because you can think of a person and talk to them about it. Then you can move on to transferring that cryptocurrency, accepting that server fingerprint, establishing that OTR chat (and checking security codes without meeting in person), etc.

We really felt that only by solving all 3 problems would a general PKI ever take off.

[vvanders]

I have nothing to add other than that I really like how KeyBase decided to do identity. Letting the user decide how much they trust different services and using them to verify is a fantastic solution.

[hdhzy]

Excellent summary of your vision.

> (1) (...) Whether you're following a famous developer or you're looking up your own sibling, odds are in 2017 you know a public definition of them: a Twitter account, Reddit account, Facebook, etc.

What do you think about OpenPGP Linked Identities proposal [0] that does exactly what you described but in a decentralized way?

[0]: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01

[maxtaco]

It would be great to see it deployed, but it solves only (1), and even so, not completely. I couldn't find it in the doc, is there a story for revocations? Part of our concern about the PGP story is that malicious servers can suppress revocations. In Keybase's architecture, we've committed to an append-only data structure, which makes it impossible to withhold revocations without being detected. In a decentralized setting, you could do something similar with a blockchain like Bitcoin or Ethereum, but for usability, it would be important to do so without requiring mobile clients to download the entire blockchain. (BTW, that draft cites Keybase as a motivation for their approach :) )

[hdhzy]

> BTW, that draft cites Keybase as a motivation for their approach

Yes, I know. Without Keybase this draft would probably never exist in the first place :)

> I couldn't find it in the doc, is there a story for revocations?

Yes, it supports revocation as links are stored as User Attributes (similar to UIDs).

> In a decentralized setting, you could do something similar with a blockchain like Bitcoin or Ethereum, but for usability, it would be important to do so without requiring mobile clients to download the entire blockchain.

Yes, I've been thinking about using Blockchain for that purpose but I'm waiting for something more concrete to materialize out of Key Transparency [0]. As far as I like Keybase for something so fundamental as identity I think a distributed solution would eventually be necessary.

As far as I remember you write sigchain Merkle root to Bitcoin [1], that's a good security measure. (although you may consider using OP_RETURN outputs rather than fake output addresses, that optimizes unspent transactions database on each Bitcoin node).

[0]: https://github.com/google/keytransparency/

[1]: https://keybase.io/docs/server_security/merkle_root_in_bitco...

[craftyguy]

I see the client source is on github (yay!), but what about the server source? Is this service federated? If not, then this is yet another silo'd solution (with a proprietary backend) dependent upon a single company to maintain..

[cowpig]

Why did you choose to tie identity to devices? That idea has always seemed fundamentally flawed to me, and if it wasn't for this flawed core idea, I would be a big fan of what you are doing.

I am not my cell phone, my laptop, or any other possession. I am a collection of memories and experiences, so it makes perfect sense for my identity to be tied to that--like a passphrase.

This isn't just a philosophical idea. I travel a lot and change cell phones all the time. My laptops break and get stolen. I lose things. But I (almost) always have my mind with me.

[joegosse]

They also support paper keys, which you could think of as equivalent to your mind (i.e. memorize the key)

[giancarlostoro]

Honestly hoping to see email support, or an email sub-project that makes using encryption (existing mostly) in email easier. At work we have to use PKI or S/MIME from Microsoft, which only works on Outlook or on Apple's Mail client, why not on some open source client? Why can't I have easy email encryption in 2017 that anyone can use? Aside from just using Protonmail (centralized issues). Glad you guys are doing this project, hoping to buy more space whenever you guys decide to sell more disk space to users.

[KGIII]

I have found Enigmail and Thunderbird to be easy and intuitive. Both are open source. Thunderbird is the email client and Enigmail is the plug-in.

[snorremd]

If your work does not require you to use the proprietary exchange stuff in Outlook I would say that Thunderbird with Enigmail is a really convenient solution for encrypted and signed email. Once set up there is very little overhead involved, and if a recipient's email address is in your local gpg database Enigmail will happily encrypt content by default.

[giancarlostoro]

Kinda does require the proprietary solution. We do have in the office a paid for Thunderbird plugin (we use Ubuntu unless working on .NET) but for personal use (at home reading work mail) I am limited to using mail on my Macbook Air. Also explaining the process to someone else I know vs just telling them to install an all inclusive mail client that is more seamless would be a different story. Short of telling the whole world to sign up for ProtonMail I would love to see a client that handles email encryption cleanly.

[sliken]

Now try getting your compute newb friend/family going so they can sign, verify signatures, encrypt, decrypt, add keys, etc.

Now try web of trust, key servers, revoking certs.

Then the finer points of what to when you find tons of different keys for people with the same name.

Then subkeys, short term keys, and keeping long term keys offline.

See.. easy!

[fish_fan]

I wonder if, in the mid term future, you could see e2e encryption over slack and other offerings if you added slack as a team member—granted, they’d be storing the messages plain text on the slack side, but it’d ease and encourage transition onto keybase teams rather than eg SAML.

[zapu]

Sometimes, when Slack e-mails me that someone has mentioned me in a channel, and in the e-mail there is content of the message, I have a brief thought of "how do they know-... oh". I'm slowly getting used to e2e provided by various IMs, as well as encrypted at rest e-mail providers (personally I user Protonmail) - it's not something extraordinary anymore.