
Keybase.io - andybons
https://keybase.io/
======
malgorithms
Hi everyone, Chris here, I've been working with Max on Keybase. I can't help
but feel this ended up scooped a bit early. (Crap!) Not a surprise, because HN
is quick.

The alpha site's changing every day, and we're working on the documentation
now. I don't use the term "alpha" loosely. There will be extensive security
details published, explaining every aspect of the identity proof system,
client sessions, etc. They will be on the site _before_ we open general access
or turn beta. Right now only a few friends are on there. All that said, Max
and I can answer questions here.

My profile on the site is [https://keybase.io/chris](https://keybase.io/chris)
if anyone wants to look. My profile demonstrates early examples of how
identity proofs will work, including both twitter and github. We'll of course
be adding other public identities in the future.

The site design is also very iffy at the moment; I was about to move into
firefox bugs tomorrow.

~~~
riquito
The first thing I thought about is a man in the middle attack with homoglyphs.
I don't know if I'm paranoid, but look at this

    
    
        > keybase id maria
        
        pgp:     C4B3 15B4 7154 5281 5100 1C58 C2A5 977B 0022
        github:  mаria_leah   ✓ https://gist.github.com/23423
        twitter: mаria_h20    ✓ https://t.co/mаria_h20/523554
        site:    mаriah20.com ✓ https://mаriah20.com/X904F...
    

I looked up for 'maria', all ascii. The answer, served by a malicious server,
contains the first 'a' of maria in Cyrillic (check yourself, you'll see that
'mаria_leah' != 'maria_leah'). This would fool the user.

Maybe the client should apply some logic as browsers do for IDN homograph
attack to show characters not in your locale in a different way, or at least
warn you.

~~~
malgorithms
Hi riquito - this is a very legitimate concern, and it has to be reviewed
individually for each type of proof keybase supports, in the client. With
twitter, keybase, and github, you can't have a username containing any
character other than an alphanumeric, dash, or underscore. Which means this
kind of attack is impossible.

But for future identity proofs (domains, for example, which we've yet to
implement), this kind of attack is real. Our approach here will be that
anything outside of normal ascii will be highlighted and addressed to the
user, as a serious warning.

~~~
riquito
These are good news. Thank you and good work!

------
sneak
I really, really want crypto, specifically, safe and secure-by-default crypto,
to become much more usable.

Despite this hope, I can't seem to help the fact that the first thing that
popped into my head when I read their webpage is "oh, they're wrapping and
abstracting important key authentication and critical key trust configuration
to make it more user-friendly, and implementing it all in javascript. WHAT
COULD POSSIBLY GO WRONG?"

Even if I got whacked on the head one day and suddenly loved javascript, I
would not use it for certain projects when I wanted to be taken seriously by,
say, cryptographers.

Then again, look at all the success cryptocat has had!

~~~
aidos
Honest question, which part of writing it in JS makes it less safe? I
understand that running in a browser is an inherently unsafe model because of
the various mechanisms that make it impossible to track code that's running
along side yours. How is it that JS is unsafe in a server environment?

~~~
sneak
The median programmers it attracts to write it.

~~~
aidos
Argh. That barely warrants a response.

The average skill of developers using a language is low, therefore it's not
possible for anything written in the language to be of high quality?

Wow. Even assuming that the initial assertion is correct, that's horrifically
illogical.

True reason: you have an anti-js bias. You're welcome to that, but for
goodness sake be rational in your hatred.

------
sneak
If this talks to keybase's API over https and any large groups come to rely on
this, we've then effectively replaced the decentralized safety of the Web of
Trust used for authenticating PGP keys with the PKI that's used in browsers,
which is completely and totally fucked.

I cannot support a project that doesn't build and strengthen the underlying
WoT. Getting https involved for authenticating unknown keys is a huge step
backwards. Madness.

~~~
maxtaco
We're not big fans of browser PKI either, but we're using it as scaffolding
that hopefully one day can be torn down.

`keybase-installer` needs an initial install over https from npm. We
unfortunately saw no way around this.

Assuming that install succeeds with integrity, then all future upgrades of the
installer and client are verified with PGP keys stored locally on the client.

Once the client is installed, it speaks HTTPS to the server, but we're not
trusting the root CA. Rather, we sign with our own CA that we ship with the
client.

The proofs themselves, on twitter and github, all can be verified in the
clear, as FiloSottile points out, but of course relying upon the HTTPS
certificates of twitter and github to make sure the proofs weren't corrupted
in transit between those services and the client.

~~~
sneak
> `keybase-installer` needs an initial install over https from npm. We
> unfortunately saw no way around this.

Write it in a language that has a packaging system not designed by amateurs.

------
read
Is it really impossible to make browser crypto a reality?

 _Browser crypto can be scary! Do you have a malicious extension installed? We
can 't tell. Further, how can you guarantee we haven't been tortured into
serving you custom, targeted JavaScript? Hopefully you're not that important._

I realize malicious extensions can currently do as they please, but can't
browsers allow extensions to define a security policy that forbids all other
extensions from modifying a page? This policy could be specific for a single
website: Keybase.

Because if browsers could do that, they could then support proof carrying
code, which could be used to verify Keybase hasn't been tortured into serving
a custom, targeted JavaScript.

[http://en.wikipedia.org/wiki/Proof-
carrying_code](http://en.wikipedia.org/wiki/Proof-carrying_code)

~~~
IgorPartola
So even if you have a valid crypto implementation baked directly into the
browser, and you can call crypto primitives directly from JavaScript, what's
the point? I'd just grab whatever you are trying to encrypt before it gets
encrypted, or decrypt it myself. Or replace the encryption functions with my
own wrappers.

Remember, I can introduce any code I want so long as I control the server
which is serving your web page. JavaScript crypto is an attempt to not trust
the server serving the data, but if that server, or any other server can
inject any code into the web page which is handling the encrypted data, then
you have no security. You are still left trusting the server to not screw you.
Which is the same as using HTTPS which we already have today.

~~~
read
The point is to make it impossible to do what you just described.

For example, to make it impossible for code sent by a server to execute any
Javascript (or other scripting languages) at all. The server could instead
send a data structure (as opposed to code) describing what to do, without
having the power to replace any encryption functions or to execute additional
functions that can subvert encryption. I realize a first version of this might
sound too restrictive, but the point here is to show how it can be made to
work.

If it's possible to reduce what the server sent to the browser down to a
fingerprint, it will also be possible for the browser extension to verify this
fingerprint with multiple third parties. It can verify the fingerprint of the
server code matches a fingerprint published on Twitter, or GitHub or other
sources, which is something Keybase tries to do.

An attacker would need to break into all (or at least a majority) of those
services to serve you bad code. Which is harder than breaking only into your
server.

Forbidding other malicious browser extensions from interfering with a Keybase
browser extension would allow the Keybase extension to perform all this
fingerprint-checking logic with the guarantee the verification hasn't been
tampered with.

~~~
IgorPartola
I don't get it. We can already do this: just have your server serve up XML,
JSON, CSV, etc. Serving raw data with no code attached to it and disabling all
extensions is something we already have. It's also not very useful.

The point of web applications is that you can quickly distribute an
application that runs on a common platform to everyone at once. It's a very
nice idea. It is also insecure to boot.

You are proposing two different changes. First, an enhanced ability of your
web server to tell my browser which code is allowed and which code is not.
This is good. This way, for example, my bank running on bank.example.com can
tell my browser to not load any JavaScript code, or even any external resource
from anywhere but bank.example.com. Now nobody can inject a JS file from
evil.example.com. Fine-grained control over what the browser should and should
not allow is a good thing. Controlling extensions is a bit different. I want
my extensions to work. I want my ad blocker and my privacy guard to function
even on sites like my bank's. In general, I would not want a site like Google
to disable my ad blocker, that would be evil.

Now, if you are saying that you want to sign this application and distribute
the signature to other services so that I as the user can verify that the
application blob I got from your server has not been tempered with, then how
do you go about updating your application? If you found a critical bug in your
JavaScript code and fixed it, now you have to create a new application blob, a
new signature, and distribute that signature to all these other services that
are supposed to arbitrate whether you are delivering honest code. Notice that
you and you alone still control the signatures. There is no external
verification that you are not delivering evil code to me, I still have to
trust you, personally. Adding a signature/checksum means that the code you
delivered has not been tempered by a third party, but it says nothing about
_you_. And the point of in-browser crypto is so that I don't have to trust
_you_.

That's where the whole thing breaks down. If someone forces you to change your
code, then update all the signatures and launch this code, then I still have
no idea that it happened. So at best this might protect me from a malicious
third party. But guess what? HTTPS already does that, and is a much simpler
and proven solution.

In-browser crypto does not work, and will never work. There is no way to make
it work. The web is not a platform where the client can treat the server as
untrusted. Every time I see an attempt at this I cringe since someone clearly
wasted a whole lot of effort thinking they finally cracked it. Keybase is
probably the first place where I am not completely against it as they are
using it as a demo of what your actual client would be doing. Then again, they
could probably have just scrapped it completely and done the whole thing
server-side without so much effort.

The alternative to what you are trying to achieve is this: every website is
distributed as an open source application blob and a number of trusted third
parties reviews the code before it gets published. These third parties each
sign the the code with their private keys, showing that the believe the code
to not be evil. The problem with this is that it completely undermines the
central promise of the web application: instant deployment to all your users.
This system is exactly what you have with Linux distributions' repositories.
It work, it's secure, but it's slow.

------
zobzu
[https://sks-keyservers.net/](https://sks-keyservers.net/)

Advantage: it's distributed

~~~
philfreo
Disadvantage: this site does nothing to make cryptography more accessible /
easy to use for the common person.

~~~
midas007
Accessibility should not introduce a SPoF.

What happens when Snowden uses it and the USG requests access?

Oops.

Businesses / nonprofits cannot provide privacy-as-a-service unless they're
"SWAT proof" (distributed).

Advantage: SKS is "SWAT proof."

------
IgorPartola
Cannot tell what this does on a mobile browser.

~~~
lallysingh
This, exactly. All I see are two buttons, Join and Login. But no description,
no clue, nothing on what I'm being offered to join our log into.

------
pknight
Just want to say cool art work on the landing page

~~~
apgwoz
Done by the extra talented Caroline Hadilaksono!
[http://www.hadilaksono.com/](http://www.hadilaksono.com/)

~~~
scotty79
For me it increased the perceived trustworthiness of the website 10 times.
I've seen illustrations drawn in similar style in Scientfic Amercian and
subconsciously carried over the trust I have for SA to this site.

------
electic
This is totally off-topic however I really like the graphic at the bottom of
the page. The graphic really sums up the challenges developers have in
creating secure communication channels. There are so many threats now a days
it seems overwhelming.

------
theboss
Where are the security details published? I think that's what we all want to
see...

On top of this....I think this is cool in theory but bad in practice.

The assumption that Root CA's are trustworthy is already hard enough to make,
how do I know that Maria is actually Maria? How will you verify that ``Maria''
actually owns that twitter, github, gmail. Maybe it is possible to devise some
type of scheme for those sites, but how about more obscure services?

One mistake in one single account causes the entire thing to fall apart...

~~~
caf
The idea here isn't that you use keybase to find out Maria's twitter, github
or gmail identities - it's the opposite. The idea is that you already know who
Maria is on one or more of those services, so the fact that the account you
know is Maria's at github has posted a signed message from that public key is
supposed to testify to you that that is really your Maria's public key.

You could of course manually review and verify Maria's github post that
contains her public key - all that keybase is really doing here is providing
an easy way of discovering that github post (or tweet, or whatever).

~~~
andrewaylett
s/could/should/?

~~~
caf
Only if you don't trust your copy of the keybase client (as opposed to the
server, which you should not need to trust).

------
addisonj
Looks very cool, but one piece of feedback: Let the user know it is in invite-
only beta on the homepage.

I downloaded the command line util and tried to login, only to be let down :(

Excited to try it out!

~~~
malgorithms
Hi addisonj - sorry about this. The site is clearer about this limitation. If
you request access via the site now (just click join on there) and remind me
this happened to you in the comment field, I'll move you forward in the queue.
Sound good?

------
IgorPartola
OK, finally looking at it on a desktop...

So my first question is this: if I know "maria" and I want to look her up to
get her GPG key, how does keybase handle that? Does it just do an email
address lookup, as in goes to, say, GitHub, grabs her email address,
maria@example.com, then goes to a public key server and grabs the key that
corresponds to maria@example.com?

If that's the case, there is a security issue: what if Maria never published a
GPG key, but Chloe did using Maria's email address? Moreover, what if Chloe
has access to Maria's inbox and can read these messages I believe to be only
readable by Maria?

Edit: I see from responses below that various online presences of an identity
tied to "maria" are checked. Is this not then susceptible to its own attack?
For example, if Maria does not have a Twitter account and I create one, or
compromise hers and post a different key, will I be able to at least introduce
doubt into her identity, if not take it over outright?

~~~
maxtaco
No, there are no proofs based on e-mail addresses, because such proofs are not
publicly-auditable. We could ask that maria prove to the server that she
controls a given gmail account, but there's no way for the server to prove
that to you.

We want the server to be untrusted, ideally just a dumb message router.

If Chloe wants to impersonate maria, she'll need to get control of maria's
twitter and github accounts. Just claiming maria's email address won't get her
anywhere. (Note that GPG keyservers are susceptible to exactly the attack you
describe).

~~~
IgorPartola
Hold on. First, GPG servers are susceptible to the same type of attack, except
they would never be used that way. You _never_ look up a person by email, the
send them an encrypted message using the key you get. Instead, you verify
their key and email address out of band: you meet them, check their
credentials, then sign the key. Keybase is trying to get rid of the in-person
verification, an effort I applaud, but in favor of a much weaker check:
whether a few centralized accounts had been compromised.

The other part, where you check Maria's Twitter and GitHub accounts, means
that a few things like Twitter, and GitHub are impervious to Chloe: a tall
order and a centralized one at that.

Once again, is the point here for me to get a tuple of (email address, public
GPG key) so I can email Maria securely? If so, then someone somewhere has to
prove that this tuple fetched from the public key servers is valid.

If the point is to only communicate via keybase.io, then the service is
centralized, and useless once actual sensitive info is exchanged, the US
government takes notice and shuts it down at the DNS level.

~~~
maxtaco
Cool, I agree no one should use PGP servers the way I described, but you never
know what people are doing out there. To do things the proper way, as you
described, is difficult in practice for lots of people.

To answer the question, the point isn't to get an (email address, GPG-key)
mapping. It's to get a (public-internet-identity, GPG-key) mapping. People
sometimes do this today in an adhoc manner (e.g. tweeting your GPG
fingerprint). We want it to be checkable by user-friendly software.

~~~
IgorPartola
I see. That MO makes a bit more sense then, though is it not then limited to
just Keybase.io and will no longer work if something happens to this service?
Or more importantly, is there a way to make this distributed?

~~~
maxtaco
If the site went away tomorrow, you'd still have keys in your GPG keychain.
You'd also have a local cache of the server-side data relevant to you.

All public server-side data is available as a dump
([https://keybase.io/__/api-docs/1.0#call-dump-all](https://keybase.io/__/api-
docs/1.0#call-dump-all)). Private data like encrypted public keys and password
hashes we of course will keep under wraps.

We don't have immediate plans to make the system distributed, but if someone
did it, we'd find it very cool. It's just too much for us to do right now.

------
Stealth-
This is great. Proper cryptography is the solution to so many of the problems
the modern internet is facing right now, but the key problem with cryptography
is that it is never user friendly enough and never distributed enough.

This looks like a great step in the right direction.

~~~
fsiefken
What do you think of
[http://invictus.io/keyhotee.php](http://invictus.io/keyhotee.php) user
friendly and distributed identity

------
jszmajda
Awesome! Unix `finger` is back! I loved that tool!

------
yeukhon
This is effectively the same idea to provide your ownership of a domain. For
example, if you want to use webmaster tool from Google you'd either insert a
text in some file or modify the DNS A record to contain the expected text.

One thought is vouch and level of credibility by the person's profile. If a
lot of people vocuhed for Maria or if Maria has a lot of active tweet and/or a
lot of Github activity there is a good chance this is a real Maria. However,
the activity-based credibility is easily forged and defeated so probably not a
good idea to add, bur worth thinking about :)

------
mbreese
What does this do? The mobile site has zero information, just a form to sign
up.

------
Sir_Cmpwn
Styles are broken on Firefox, text is flowing off the right side of the
screen. Why do lots of sites seem to have forgotten about testing on Firefox
recently?

~~~
rch
The whole thing seems to be very early alpha. I'm sure that will be taken care
of a little further down the road.

As a former Opera user, I certainly sympathize though.

------
rinon
Very cool idea. The idea of automatically verifying public keys over publicly
accessible and known channels is great. This is more or less the manual
process I follow when I want to verify a key remotely. Looking forward to
seeing where this goes!

Also, being able to use this with arbitrary crypto software (eg GPG) would be
even better!

------
geerlingguy
On iPhone, I only see a graphic and login/registration links; can someone
describe/summarize the service?

------
carbocation
Am I correct in thinking that this would not prevent a targeted MITM where an
attacker generates a "valid" cert that allows them to serve up a modified
response for the Twitter and Github public key verification requests (say,
providing you with an alternative public key)?

------
sfeng
I've got to say this site does 'responsive design' the exact wrong way. On
small screens all the words are hidden explaining what it actually is, instead
you just get a giant meaningless image and buttons with no context.

------
diasp
Interesting. Another approach is [https://encrypt.to/](https://encrypt.to/)
which loads the public key from key servers and encrypts client-side via JS.

~~~
malgorithms
To clarify the difference, it seems encrypt.to is a service which does PGP
crypto in the browser, based on keys pulled from keyservers. In contrast,
Keybase is an identity-proving service, which proves key X belongs to person
with twitter account Y, github account Z, etc. As a convenience, it also does
encryption and other crypto actions for its users.

------
jlafon
This looks pretty cool! I like the story flow.

You might want to include some links that explain what the keys are, what PGP
is, etc - because not everyone who lands on your site will know.

------
dmix
There should be a big sign-up call-to-action button. You're missing out on
tons of potential users.

------
fiatjaf
This is awesome. We didn't anyone did this before?

------
jonesetc
Is there a way to remove an associated account?

~~~
steveklabnik
[http://pgp.mit.edu:11371/faq.html?search=foo](http://pgp.mit.edu:11371/faq.html?search=foo)

~~~
jonesetc
Right, but this isn't just a keyserver. They are allowed to break those rules
in their service if they wish.

~~~
steveklabnik
Sure, just pointing out that it's still basically useless.

------
luke-stanley
Is it FOSS?

------
jl2975
sweet site

------
g3orge
but... node? really?

