
Keybase's mission is to make encryption mainstream - BradyDale
http://observer.com/2017/09/keybase-max-krohn-chris-coyne-okcupid/
======
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.

~~~
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](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/](https://github.com/google/keytransparency/)

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

------
paxy
They don't really address the fact that every single Slack "leak" is from
someone already part of the team taking screenshots of the conversation. How
does any kind of encryption help that?

Also doesn't mention everything you lose out on with this approach - like
searching through message history.

It's a neat product I guess, but mentioning Slack in every single line seems
more to get eyeballs than a valid comparison.

~~~
eridius
Search could be done locally if the client downloads the whole message
history. I don't know enough about how Teams works to know if that's actually
something a client can do right now, but it should at least be technically
possible.

Another alternative is simply running a bot that indexes everything and
provides search. You can run the bot in-house so you keep control over your
data.

~~~
x0x0
I think I'm more uncomfortable with the idea of entire message histories
walking around on disks of laptops and phones (not to mention that's a giant
problem on phones because of storage/horsepower) than I am with the idea of
slack being able to read everything...

~~~
eridius
Well, the clients could just keep indexes rather than the actual history, and
then fetch the specific messages as needed when the search is performed.

------
notheguyouthink
> Two veteran entrepreneurs are running a little startup built around making
> it easy to build web and mobile applications from day one that make data
> impossible for a digital trespasser to read. In fact, it encrypts data in
> such a way that even if you use some company’s service, that company can’t
> see what you’re doing with it.

Is it? Not that I'm questioning Keybase, I just had no idea they were offering
some type of encryption-as-a-service thing. I thought key base offered
encrypted identity management, along with some encryption focused tools (kbfs,
and now chat). Of course, I don't know/use key base - hence why I'm asking.

Can anyone go into more detail on how key base is offering this service:

> In fact, it encrypts data in such a way that even if you use some company’s
> service, that company can’t see what you’re doing with it.

 _(Assuming "some company's service" is a 3rd party service)_

~~~
gglitch
I'm new with it myself, but I think part of what's being described is the
option you have, when you have a Keybase account and the Keybase browser
plugin and you're logged into a third party system (such as Fbook), of
clicking on a Keybase icon for a given user and sending an e2e encrypted
message from your Keybase account to theirs (even where they don't have one
yet--if they make one later and associate it with their account on the third-
party service, they will then unlock access to the message).

~~~
notheguyouthink
Ah hah, this seems to be the answer then. Thanks!

I like that idea of encoding before it hits FB/etc. Though, the level of
security provided by a browser plugin makes me a bit nervous. Not an educated
nervousness mind you.. I just tend to not trust them, and how well sandboxed
they are, etc. It's the reason I also don't use browser plugins for password
management.

------
dangero
Tangent, but the article mentions using Google Authenticator -- I was going to
start using that recently, but the reviews indicated it had some really big
problems with restoring when you get a new phone etc and Google isn't really
maintaining it. [https://itunes.apple.com/us/app/google-
authenticator/id38849...](https://itunes.apple.com/us/app/google-
authenticator/id388497605?mt=8)

Can anyone comment on their 2fa approach to google?

~~~
_mcdougle
Always save the keys (or the scanner code) whenever you add them to
Authenticator. Then, when you get a new phone (or whatever) you can just re-
import the keys.

~~~
koolba
It's pretty stupid that Google doesn't allow for _any_ way of getting the keys
out of it's 2FA app. Your only transition path is backup/restoring an entire
device to a newer one of the same OS.

There's no direct path to migrate from say an iPhone to an Android based phone
without manually adding each 2FA entry to the new device.

~~~
jamesgeck0
> Your only transition path is backup/restoring an entire device to a newer
> one of the same OS.

This isn't an option on iOS! When I bought an iPhone a year and a half ago,
the 2FA keys were not included in my iTunes device backup, even through backup
encryption was turned on. I had to manually create new keys for all seven
sites I use Google Authenticator with.

~~~
koolba
They're definitely included as I've done it a number of times. I'm going to
wager you don't have your iTunes set up to backup apps from your phone. I
think there's a separate check box you have to click once to enable it.

~~~
dunham
The secrets are in the keychain, which is backed up.

Google Authenticator used to store its secrets in the devices keychain as
available "while unlocked". This allows them to be stored in the backup in a
way that can be transferred to a new device - if you use an encrypted backup.
It also makes it possible to extract the keys if you know the backup password.
(I have code that does this, inspired by the old "iphone-dataprotection"
codebase on google code.)

Google Authenticator now (last I checked) marks its keychain entries as "This
device only" \- this still allows backup/restore, but only to the same device.
They are wrapped by a key only available on that specific device (the 0x835
key - you used to be able to extract it on a jailbroken device, but I'm not
sure that's possible anymore).

It's possible you have grandfathered entries or even an old version of
Authenticator. But I no longer see entries for
"CLNPY5GLN9.com.google.Authenticator" in my decrypted keychain, so it must
have migrated my old entries. Before my phone dies, I need to go through all
of mine and make sure I've got a backup or regenerate the ones I'm missing. (I
have old snapshots of decrypted keychains.)

------
valj
Nice work team. I've been on Keybase for a while but I've only recently
installed and started using Teams on iPhone and Mac and both the apps are very
polished and easy to use. Definitely a lot easier than posting up my key and
waiting for someone to email me encrypted text ;)!

I think the strategy of decentralising the data is a good one for enterprise
apps like this, where there's typically little value from the perspective of
the business user, employee user, or service provider from holding the data.
Lots of data is great for driving personalisation and other features in a
million+ person network but not really in cases like this one.

Hopefully this is a pattern that will keep working its way into enterprise
apps.

------
Angostura
> In order to give everyone confidence that the people shown in the Keybase
> are who they say they are, Keybase encourages users to attest to their
> identity cryptographically on social media. Keybase is its own social
> network, but it’s not one for sharing pictures of food or sad status
> updates. It’s a place for Mary to say “This really is Bill” and for Bill to
> say “this really is Mary.” With enough attestations like that, it becomes
> really hard for people to pose as someone they are not.

Doesn’t this sound like a nightmare in terms of social engineering attacks?

~~~
captn3m0
If your social account (twitter/..) gets taken over, you'll have to publish a
new proof on it, which will then need to be attested by multiple people,
before it becomes trustworthy anywhere.

~~~
egwynn
Right. Plus your KB identity will still have all of your other online
identities vouching for it. So an attacker would need to commandeer a large
fraction of your accounts in order to get people to trust the fraud.

------
lysium
How does keybase make money? I am afraid they are in the business of selling
my online identity.

~~~
Jedd
> How does keybase make money? I am afraid they are in the business of selling
> my online identity.

This comes up semi-regularly. Within the recent announcement of Teams [1] it
was noted that:

"Put most simply, we eventually want to find a way for actual enterprises to
pay, while keeping personal and community use free. And any use now is
grandfathered in."

I've seen similar sentiments in earlier announcements.

They also have a clear privacy policy [2].

[1] [https://keybase.io/blog/introducing-keybase-
teams](https://keybase.io/blog/introducing-keybase-teams)

[2]
[https://keybase.io/docs/privacypolicy](https://keybase.io/docs/privacypolicy)

~~~
lysium
Thank you very much for your answer! I'm wondering how key base can find an
investor with such a weak hope. Anyways, the privacy policy gave me the
answer: everybody can can check my online identities, it is public and not
deletable. Or, if the block chain is encrypted, they can sell it in a merger.
Too bad!

------
asymmetric
> It’s mission: to make encryption mainstream.

Not to be pedantic, but is this normal in a major(?) publication?

~~~
jasonmp85
From what I've seen of writers, they're barely literate before an editing
pass.

------
Kinnard
Was the title on this story changed mods? If so, it'd be cool if there was
some sort of annotation for when that's done.

------
MBlume
I don't really get it. I have a Keybase account. It's attested on my social
media accounts (including on HN). It includes a private key on my personal
laptop and one on my phone. I haven't extended it to my work laptop because I
don't want my company IT having access to a key that I've gone and told all my
friends they can trust. So I'm confused about how this is supposed to work.

------
misterbowfinger
This is going to sound like a dumb question, but.... how much would encryption
help? Even if we encrypted all of our data at rest and on the wire, I feel
like a lot of security vulnerabilities wouldn't have been prevented with
encryption. If you have any way of interacting with the application or the
database, it's basically game over, no? Is there any data on this?

~~~
egwynn
I’m not sure what threat model you’re proposing. If an attacker has control of
your computer or the keybase app, then yes, it’s game over. But encryption
removes the hosting entity as what would otherwise be a single point of
failure. If you hack keybase the organization, you don’t immediately get
access to everyone’s everything (in contrast with Equifax). An attacker would
need to infiltrate the codebase and then release a malicious version to
everyone that makes their apps decrypt/reroute/whatever the data.

~~~
misterbowfinger
I suppose I'd like to see what threat models actually apply to companies, and
what vectors are most often used to get pwned (outside of social engineering).
I understand what encryption prevents, but I don't understand how helpful it
is in practice.

------
alexasmyths
I've come to the belief that crypto and security are a 'feature' and never a
product.

As important as these issues are - I find that businesses and consumers don't
often opt for these things as a primary choice except in specific
circumstances, or for specific consumers with specific needs.

The fact is - I think - most people don't care. Even most startups don't care
that much. If their conversations are 'reasonably secure' then they're good
with it.

I think HN readers are way to one side on this issue - we care a lot about it.
I think our views are different from that of most people.

This could change but I think we're still in this mode.

------
fairpx
If there's anyone working on an Open Source Slack (or Keybase) alternative,
hit me up. I run a UI design agency and we'd love to help design a better
interface for an open solution that we and others can use. Find my details in
my profile, or go to [http://fairpixels.pro](http://fairpixels.pro)

~~~
brunoqc
I think I heard that the matrix people are looking for ux/ui people to improve
Riot. [https://matrix.org](https://matrix.org)

~~~
ThatGeoGuy
Do note that matrix.org is the homepage for Matrix, which is more about the
protocol itself. [https://riot.im](https://riot.im) is probably more relevant
for design / UI / UX work.

Note that they will need UI/UX experience more and more as time goes on,
especially if Purism's Librem 5 is fully funded.

------
dogruck
Ok, I'll bite. Is this actually a thing??

> You texted that dude about the weird thing you like to do with silicone ice
> trays and that admission will remain in the bowels of the Match Group
> forever.

