
Thoughts on Keybase.io - DanielRibeiro
http://blog.lrdesign.com/2014/03/thoughts-on-keybase-io/
======
abhv
The author may have some points; I have not inspected the protocols or the
source completely, but the arguments made in the post are misleading and
inaccurate descriptions of keybase. Seems like there may be some subtle yet
festering bias.

1\. They are not "rolling their own" crypto. keybase seems to be an
interesting wrapper around gpg that helps you establish links between accounts
using "proofs of knowledge of secret keys." I haven't tried the service yet;
but one can inspect the code:

npm install -g keybase-installer

keybase-installer

grep gpg ~/.npm/keybase/0.0.43/package/lib/*.js

2\. "Keybase's pitch is that rather than use a web of trust..."

It is not mutually exclusive. Since you have it installed, try

keybase -h

keybase track <id>

That seems to subsume web-of-trust

"limits on that identification are two-fold...<security of
twitter>...and...<soundness of tweeting>"

So it is actually the same argument repeated. The first 3 Mission Impossible
movies also demonstrate that when you meet someone in person, they might be
Ethan Hunt instead of the person you think they are. For the paranoid, there
are out-of-band mechanisms around this (that can also be used with keybase).
Even without those, keybase is an out-of-the-box mechanism for linking
identities that is weakly sound over the Internet.

3\. "...doing this right" One of the founders, Max Krohn, was at
RealWorldCrypto this year. He is an MIT phd and he certainly knows quite a bit
about applied crypto. He is also a systems person and comfortable making
tradeoffs between usability and security.

If keybase allows 1m more people to easily create and use keys, even if their
day-to-day workflow is not secure-against-state-adversaries, that would be
progress.

------
dewey
"A public directory of publicly auditable keys? Allow me to introduce PKS (an
example server) - a decentralized system for distributing public keys."

In my opinion that thought process is exactly what's wrong right now.

Just compare the two interfaces [1] and [2] and you'll see why why your
average person won't be happy to use the pgp.mit.edu keyserver to verify
identifies. It's cluttered, complicated and the presentation once you searched
for a name is subpar. I'm not saying that keybase is the best way to do it but
it's a good start to make the existing tools (Like the webinterface of
pgp.mit.edu) prettier and easier to use.

[1] [http://pgp.mit.edu/](http://pgp.mit.edu/) [2]
[https://keybase.io/](https://keybase.io/) (search field in the header)

~~~
ElliotH
Many clients do the PKS search for you. Using the website is always going to
be suboptimal, you have to copy keys around. Way better to let your client of
choice do it.

------
sgentle
Unfortunately I think this particular review is missing the point of Keybase.
In the same vein as attacking Twitter for not making the follow relationship
symmetric or attacking Instagram for ruining the dynamic range of pictures,
this author is (mostly) attacking Keybase for the very point of what Keybase
is.

PGP has failed to reach even a moderate userbase outside of crypto
enthusiasts, and while part of this, as the author suggests, is painful UI, a
large part is also that the web of trust model is unreasonably demanding for
most cases.

Keybase asks: who are you on the internet if not the sum of your public
identities? The fact that those identities all make a certain claim is a proof
of trust. In fact, for someone who knows me only online, it's likely the best
kind of trust possible. If you meet me in person and I say "I'm sgentle",
that's a weaker proof than if I post a comment from this account. Ratchet that
up to include my Twitter, Facebook, GitHub, personal website and so forth, and
you're looking at a pretty solid claim.

And if you're thinking "but A Scary Adversary could compromise all those
services and Keybase itself", consider that an adversary with that much power
would also probably have the resources to compromise highly-connected nodes in
the web of trust, compromise PKS servers, and falsify real-world identity
documents.

I think absolutism in security is counterproductive. Keybase is definitionally
less secure than, say, meeting in person _and_ checking that the person has
access to all the accounts you expect, which is itself less secure than all of
the above _and_ using several forms of biometric identification to rule out
what is known as the Face/Off attack.

The fight isn't "people use Keybase" vs "people go to key-signing parties",
the fight is "people use Keybase" vs "fuck it crypto is too hard". Those who
need the level of security provided by in-person key exchanges still have that
option available to them. In fact, it would be nice to see PKS as one of the
identity proof backends. But for practical purposes, anything that raises the
crypto floor is going to do a lot more good than dickering with the ceiling.

And I don't buy the "don't reinvent crypto" argument at all. Sure, it's a bad
idea to use your own password hash instead of bcrypt, but maybe you think you
can do better and you end up creating the foundation for Litecoin. A general-
case argument against any innovation is a dangerous thing.

With that said, I totally agree about uploading your private key to Keybase.
That's one very scary basket to put all your eggs in and I don't trust it at
all. Luckily, it's optional.

~~~
mike_hearn
I think the issue is not so much that a scary adversary could simultaneously
hack Twitter, GitHub, etc - that seems hard. The real problem is that all
these services will, in the default configuration (no 2-factor auth), perform
password resets via your email account. Thus if you succeed in hacking
someone's mail account you can take control of their other accounts and go
ahead and verify a new keybase profile. Unfortunately there's no way to know
externally if someone uses 2-factor, so it's hard to judge how meaningful a
Keybase profile really is.

The mitigating factors here are:

1) Most "good" services at least those used by the tech geek community do
support 2SV these days, which would raise the bar somewhat for people who use
it, although I suspect several of those services will still unlock 2SV for you
if you say you lost your second factor and know enough about the account
(Google does).

2) Someone would obviously notice that their passwords had all been reset and
could sound the alarm.

But in practice, I think this feels like not much different to just verifying
ownership of an email address, which is what CA's already do (and there are
PGP CA's if you don't want to use X.509). Comodo will do it for free, it's
integrated with the browser via the HTML5 keygen tag, and it takes just a
couple of minutes.

~~~
masnick
Also, the age of the tweet or gist would be a red flag. If the signed gist is
2 years old and hasn't even modified since, you can pretty safely assume that
if the keybase public key matches the signed message in the gist, nothing
nefarious has happened recently.

------
masnick
I agree with the OP about uploading private keys being bad, but you don't have
to do that – everything works without doing that as long as you are
comfortable in the command line. Whether or not uploading private keys should
be an option is a good question (I think they probably should not be uploaded
ever), but the site is still early beta so they should be given time to work
this out without getting thrown under the bus quite yet.

I disagree that the existing public key repositories are what people should be
using and that the twitter/github integration is pointless. In today's world,
we often want to communicate with people we have never met in person. An old
tweet or a gist that hasn't changes in a long time seems like a pretty safe
way of verifying someone's identity. Apart from the NSA[^1], it's hard to
imagine a situation where both keybase was compromised with a bad public key,
and twitter/github was compromised by invisibly changing an old tweet (not
possible to edit without a big hack) or a gist (not possible to edit without
creating a change history within a big hack). So this makes a lot of sense to
me as a way to easily verify identity.

[^1]: At this point I'm not sure I would trust any encrypted online
communication if the NSA wanted to read it.

------
__alexs
I agree that the Twitter integration doesn't seem enormously useful. However
the GitHub integration seems to be somewhat useful for code signing at the
very least.

Knowing that the binary or tarball you got was created by the account you are
trusting to have actually written it isn't perfect, but it's pretty good for a
lot of situations.

------
theboss
There are a few funny things about keybase. First, should they even make it an
option to give them your private key? I believe they should not.

The thing this doesn't solve is it opens the door for new attacks. What
happens if I make a page identical to twitter on twtr.com, that shows a
keybase user verifying a fake public key. Keybase could easily accomplish this
and this attack isn't that different than other attacks we have seen on the
web.

In my opinion...keybase doesn't buy you any new level of security...it's just
supposed to be a user friendly way to distribute keys, even though you still
have to do the work of verifying them yourself.

------
zk00006
Honest question: can somebody explain what problem Keybase addresses?

