5 ms·

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 hea

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 9y ago
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 9y ago
  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 9y ago
  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 https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
  - maxtaco 9y ago
    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 9y ago
      > 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/ https://github.com/google/keytransparency/ [1]: https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain https://keybase.io/docs/server_security/merkle_root_in_bitco...
fish_fan 9y ago
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 9y ago
  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.

malgorithms 9y ago

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 9y ago
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 9y ago
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 https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
- maxtaco 9y ago
  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 9y ago
    > 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/ https://github.com/google/keytransparency/ [1]: https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain https://keybase.io/docs/server_security/merkle_root_in_bitco...

fish_fan 9y ago

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 9y ago
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.