
Could keybase.io do for crypto what GitHub did for Git? - matthewsinclair
http://www.matthew-sinclair.com/post/80668116295/could-keybase-io-do-for-crypto-what-github-did-for-git
======
RyanZAG
GitHub is good because it doesn't re-invent the wheel - it uses Git. If Github
had rolled their own system it probably wouldn't have taken off.

Keybase.io is very much rolling their own system. I think that answers the
question.

~~~
FiloSottile
GitHub took a good, hard tool, git, and created a new way for its users to
communicate: Pull Requests, GitHub.com repos.

Keybase is taking a good, hard tool, pgp, and creating a new way for its users
to communicate: usernames, social account proofs and Keybase.io hosted pubkeys
instead of keyparties and keyservers.

~~~
Pxtl
... wait, there's an actual pgp thing called a "key party"? Really?

~~~
alcari
Yeah, key signing parties aren't that uncommon in some circles. Everybody gets
together and signs pgp keys in person.

~~~
Pxtl
[http://en.wikipedia.org/wiki/Group_sex#Key_party](http://en.wikipedia.org/wiki/Group_sex#Key_party)

------
notacoward
Do for crypto what GitHub did for git? You mean take something that's already
well-distributed and introduce a central SPOF for many people's workflows?
Sure, they can do that.

~~~
dasil003
I think you should look at the adoption curve of git before and after GitHub
to temper your snark.

edit: and you think your previous account got hellbanned because of
"disagreement with the herd". Open your eyes and take a look at yourself.

~~~
notacoward
Likewise, I'm sure. Did your personal attack, grounded in defense of the
conventional view, contribute to the discussion?

~~~
dasil003
You're a hilarious guy. Don't dish it out if you can't take it.

------
skrebbel
I'm a complete crypto noob, but if i do

    
    
       keybase encrypt maria -m 'Grab a pint tonight?'
    

(from their front page) and Keybase.io (or my connection) happens to be
compromised, won't it be possible for compromised-Keybase to send me the wrong
public key for username "maria", thus allowing others to read my message?

I guess the same could be said about someone posting their GPG key on an
unencrypted mail or usenet post, though, so maybe the problem is mostly
hypothetical.

~~~
sokrates
The entire idea is that, while keybase stores the pubkey, you don't have to
trust them to deliver the right key. They have basically rolled their own type
of digital certificate that's stored within a variety of social services, i.e.
Twitter -- you tweet something like "I'm <fingerprint of your key> on
keybase.io!". The keybase server says this to the keybase CLI: "Bob's pubkey
is <key>, and I'm right because
[https://twitter.com/bob/tweets/1234](https://twitter.com/bob/tweets/1234)
says so". The CLI then verifies that the tweet URL really contains the right
fingerprint. This extends the trust root to the twitter user (and your local
HTTPS CA store). Repeat for a variety of services similar to Twitter. This
extends the trust root to the union of all the social site accounts of the
keybase user. Whether you choose to trust those is (as always with trust
roots) entirely up to you.

Not the worst idea ever, in my opinion.

~~~
antocv
Kind of still sucks to use this to communicate with other people since you
loose deniability.

I prefer to talk on internet forums or exchange clear-text emails, because
deniability.

~~~
skrebbel
Is it ever possible to have both security and deniability? Aren't they kind of
intrinsically opposed?

I mean, is the same argument to keep security off your home wifi router so
that if the MPAA goes after you for seeding torrents, you can claim that it
might've been the neighbour.

~~~
malgorithms
On the IM side of things, you should check out OTR (off-the-record messaging):
[https://otr.cypherpunks.ca/](https://otr.cypherpunks.ca/) \- in particular
check out the top 4 goals mentioned on that page.

~~~
endlessvoid94
Really interesting. I've used OTR but didn't realize those goals.

However, I don't quite understand how "anyone can forge messages after the
conversation" works. Can you explain any more?

~~~
acomar
The keys are effectively public once the conversation ends -- they aren't tied
to your identity. So those messages could have been forged by anyone, there's
no proof they came from you.

------
irickt
Could Github do for crypto what Github did for Git?

[https://github.com/substack/cipherhub](https://github.com/substack/cipherhub)

~~~
defrex
From the README:

    
    
      caveat npmtor
      github's servers can be compromised by a court order, intruder, or employee. 
      You should use a secondary means of verification to check all the keys fetched 
      from github where secrecy from courts, intruders, and github employees is 
      of paramount importance.
    

This is one of the main advantages of keybase.io, though cipherhub has the
advantage of not requiring users to opt-in before you can encrypt a message
for them.

~~~
renata
If you think keybase.io cannot be compromised by a court order, intruder, or
employee, I have a bridge I'm looking to sell on the cheap.

~~~
defrex
Granted, but the idea is that they would have to compromise Github, Twitter, a
private domain, and more before performing a successful attack. That's
considerably more complex than targeting one service.

------
matthewsinclair
I've made an update to the original post to link to this article:
[http://blog.lrdesign.com/2014/03/thoughts-on-keybase-
io/](http://blog.lrdesign.com/2014/03/thoughts-on-keybase-io/) which has some
good arguments against my original optimism.

~~~
jeffbr13
As you say in your post, PKSs already associate your public key with your
email address as a unique identifier. But there are two points here:

1\. Limiting identifiers to email addresses isn't that great a solution. Email
is less popular amongst my generation (~20 y/o). It's the service backing
almost every identity now, but I already have way too many email addresses
which I have to check. What if I want to set up an anon identity? 2\. Why, as
a person on the street, would I trust pgp.mit.edu more than I trust Keybase
THEN (Twitter AND a personal webpage AND whatever other services end up being
supported) - it does ultimately depend on how much you trust Keybase, but not
obviously so.

Looking back on it in a year or two, Keybase may end up a classic example of
"worse is better", because it's easier to grasp, as you said in your post.

~~~
zAy0LfpBZLC8mAC
You shouldn't trust pgp.mit.edu, key servers are only there for easy
distribution of keys (because that's easier than typing in multiple pages of
base64), not for providing trust, trust is provided by the web of trust, that
is to say, by the signatures of other people who have verified your identity
(who in turn have signatures on their keys from yet other people who have
verified their identity, and so on). Those signatures are part of the keys
that get distributed through key servers, but it doesn't matter whether the
key server is hostile, as the key server can not forge other people's
signatures.

Also, as an aside: What went wrong there that people have a problem with "too
many email addresses to check"? The great thing about email is that it is an
interoperable system and you can do forwarding and stuff, so that you can
easily have all your emails delivered to one common user interface, no matter
how many addresses you have!? I also have quite a few addresses - but I don't
"check" addresses, all my email automatically shows up in my one mutt inbox,
which is the only thing I have to "check". That's very much in contrast to all
those new, proprietary platforms that actively try to lock you in, among other
things by forcing you to "check" every one of the platforms independently.

------
huslage
Storing private keys in a place that you do not control is ridiculous. You are
putting your trust in a service, thus making your own keys untrustworthy to
yourself.

Put your public keys wherever you want. They are public. The SKS keyservers
work well for this already, however.

The idea of getting crypto to the masses is laudable, but this is reinventing
existing infrastructure and introducing new dangers to the system at the same
time.

Please DO NOT USE keybase.io ... at least until the source is opened and we
can see what they are doing.

~~~
corford
You don't have to store your private key with keybase.

~~~
orblivion
Encouraging it is still bad news. I think we should be discouraging use of
keybase until they fold on this feature and think of a better way.

That said I am new to this whole thing myself. Is there a difference between
what goes on in this process, and backing up your private key as you normally
do backups? It is encrypted here (granted using a JavaScript CLI which is in
itself bad news)

~~~
corford
Keybase never has to know what your private key is or store it. So, yes, you
are completely free to continue managing your private and public keys however
you are used to.

Of course, managing and creating your own keys outside of keybase and then
importing your public key in to it does mean you lose out on some of the
convenience of the service but, like you say, it's too early to trust them
with everything. This doesn't invalidate their novel approach to trust
anchoring though (which you can fully partake in without having to hand over
your private key).

~~~
orblivion
> Keybase never has to know what your private key is or store it. So, yes, you
> are completely free to continue managing your private and public keys
> however you are used to.

And if they did require my private key I could always just not use the service
at all. This is sortof besides the point. I'm not concerned about being
coerced into anything. I'm concerned that they're sending the wrong message.
Do you remember when Facebook used to ask for your Gmail password before we
had OAuth? Do you think that was cool too?

> like you say, it's too early to trust them with everything

I'm not saying it's too early to trust them with everything. I'm saying you
should never trust anybody with your private key. I don't care if it's my best
friend, giving my private key to somebody is one more place it can get
discovered. PGP offers something unique in that it can give you a network
without any trust. You can weather the storm of broken https and MITMs and get
to the person you're talking to. The only thing it doesn't fix is somebody
owning your desktop. This is a beautiful thing if you think about it, and this
sort of thing would dilute it.

~~~
corford
I pretty much agree with everything you've said but I think most of the
worries are rendered harmless if keybase are clear and up front about the
trade offs. If you have a need for cast iron privacy and security, don't use
them. If, on the other hand, you just want a semi-secure solution that
prevents run of the mill third parties from intercepting reasonably benign day
to day communication then maybe the risk is worth the convenience. You could
also maintain a second keypair unconnected to keybase for things that need to
be really secure and private.

For me, the interest is solely with their approach to trust anchoring. I like
that it simultaneously provides a place to post a brief bio, a public key and
a way to tie the key holder to github and/or twitter accounts. I'm using that
part of their offering now but I have no intention of ever giving them my
private key.

------
rsync
I don't get this just like I don't get the bitcoin "hubs" or "wallets" or
whatever they are.

Your crypto keys, like your bitcoins, are just small text files. They are
nothing special at all and can be completely managed, and secured, on your own
local systems.

There is nothing but fragility and loss down this road and people that
_really_ need security in their comms will not expose themselves to that
fragility (just like smart folks probably weren't putting their bitcoins in
third party "wallets").

~~~
endlessvoid94
It's about making these things easy to use for more people. For people who
don't have the time / energy / desire to learn about the systems they use, in
order to use them.

~~~
rsync
Yes, I hear that part of the pitch, but in my mind the people that have a need
for the security that encrypted messaging provides will need to grasp it
deeply enough to not need the handholding.

And conversely, the "consumers" that aren't compelled by strict requirements
to understand how text files work don't need the security anyway.

So then who needs the keybase ?

~~~
endlessvoid94
> the people that have a need for the security that encrypted messaging
> provides will need to grasp it deeply enough to not need the handholding.

I'd say this is a pretty big assumption. Wouldn't it be great to live in a
world where you didn't need to understand it to be protected by it?

~~~
rsync
Yes, it would be great.

I don't think that world exists. I think this is true in all realms - not just
cryptography or infosec...

------
dewey
If you want to see for yourself, shoot me a mail. I have 2 invite codes to
share.

Edit1: All gone

Edit2: Coinbase just sent me some more, I sent invites to everyone who mailed
me. I got 1 left now.

Edit3: They are all gone now. Thanks for playing!

~~~
bitcrusher
Following dewey's lead, I've got 6 invites to share. Shoot me an email or
reply here. First come and all of that.

~~~
kstrauser
May I have one? I'd email you directly but can't find your address here.

~~~
bitcrusher
Sure, my email address is in my profile.

------
stonogo
If by "what GitHub did for Git" you mean "turn into a social network for
programmers and nobody else," then the answer is "maybe."

------
rk17
Maybe. But just consider that GitHub popularized git among professional
developers. I don't think it's the audience this initiative has to reach.
Though it will certainly make crypto more accessible, I doubt that doing the
analogous thing to github will give keybase the userbase that would most
benefit from their services (less tech savvy people).

~~~
edraferi
Maybe not in this incarnation, but when they roll out an API it could be baked
into all kinds of things.

For example, consider a multi-service contact managers like the Windows Phone
People Hub or Contacts + on Android. They let you establish a database that
represents people as collections of identities across various services. These
services could add a feature that discovers public keys hosted with keybase.io
for your contacts based on proofs offered by the identities you've already
mapped to each contact. This could be presented as a simple "have key yes/no"
indicator, and symbols showing which service-identity pairs have vouched for
that key, as well as warnings if any of the identities have vouched for a
DIFFERENT key.

Obviously client-to-client is always best, but you could extend this model to
cloud services, even email. It could provide an organic authentication layer.

Now, you can argue that it's only as secure as your twitter / github / domain.
Fine. But your twitter / github / domain ARE you on the internet. For most
purposes, you're just "User X on Service Y". It can be useful to be able to
prove that outside of Service Y. In addition, it's really valuable to be able
to have multiple "proofs". An attacker would need to compromise four separate
services to successfully spoof your identity (keybase, twitter, github,
domain). That's not impossible, but it is hard and probably slow, especially
if you're using two-factor authentication.

Finally, you can add additional out-of-band proofs. Hand-deliver a print out
of your key to your associates, then they can pin that proof in the client and
use keybase of on-the-fly verification, comparing everything to the key you
provided them at your cypherpunk birthday party.

~~~
rk17
Nice counter-argument, with the concession that this is more like git than it
is github. It might really put crypto on the radars of, and make it accessible
to, the developers involved in these cloud services - which would be the
equivalent of github. A jquery plugin that simply allows developers to include
a verify-identity-feature, would actually go a lot further in bringing the
rewards of crypto services to the larger audience, imho.

------
davexunit
Proprietary software and security do not mix.

~~~
oijaf888
Why not? I haven't checked the license that Keybase publishes things under but
even if it wasn't an approved open source license, how would that impact the
security so long as everything was published?

~~~
davexunit
Their server software is proprietary and they have a feature which will allow
users to store their private key with them. If you can't see it, it has NSA
inside.

------
davidw
The problem is that my mom does not need to use git or github or even know
what they are. I would not mind it if my mom encrypted her emails though, or
at least knew how. Offhand, keybase.io looks nice but still a far ways away
from a "mom friendly" system.

~~~
ndeine
I think the target userbase for Keybase is nerds who found GPG too horribly
unintuitive to figure out how to use it for themselves. I know I was like that
for a while.

The other target userbase is people who want to verify GPG keys that don't
have a web of trust. This is useful for, say, me - I'm not part of the Debian
dev team or anything, so I don't have many people around who can sign my GPG
key. It's nice to be able to publish a link to Keybase on my website and have
people be able to be pretty sure it's me.

~~~
edraferi
I actually really like the trust model that keybase.io uses. You control a lot
of a distinct spaces on the web: github, twitter, email, personal domain, etc.
It makes a lot of sense to have those reinforce a single public cryptologic
identity.

------
oznathan
If I were them I would market more the online identity verification aspect and
not mention one word about crypto or GPG.

Also, I don't like the choice of a centralized solution for privacy problem.
It could have been decentralized.

~~~
edraferi
Isn't that the point though? Trust is decentralized over multiple accounts
that you already control. Keybase just provides an easy way to access that
decentralized trust.

~~~
oznathan
If they hold your key, your privacy can be violated. By them, by someone who
buys the company or by a secret government court order.

~~~
icebraining
Then download the client and store the key yourself.

~~~
oznathan
I can't store the key myself and I wouldn't want to. I can create it myself
but it's stored in a central key server.

------
joshdance
Github is widely used and adopted by programmers. Did it help more devs start
to use git? Probably. I honestly don't know. Will keybase.io help more devs
start using crypto? Maybe. We won't know for a while.

------
brianbarker
After reading the site my impression is this just a (somewhat) fancier PGP key
server. They're tackling the issue of making PGP easier for people, which I
commend. Time will tell if it gets traction.

------
vgrichina
But Github is already doing same thing for crypto as it is doing for Git ;)
[https://github.com/substack/cipherhub](https://github.com/substack/cipherhub)

------
JulianMorrison
Where's the money stream, will they disappear or be aqui-hired?

~~~
atonse
Doesn't matter - same with github. If you don't want to use their service, you
stop.

It's just like saying, I don't want to list my phone number in this phone
book. Doesn't make your phone number any less valid.

~~~
JulianMorrison
Github sells private repos.

~~~
atonse
Sure, but my point is that if key base folded, there's nothing inherently "key
base" about any of the underlying data. You still have your key pairs and can
put them up somewhere else.

There's almost zero impact to you if they shut down.

