Hacker News Reader

Comment by malgorithms | Hacker News Reader

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 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.

View on HN

There were multiple questions/comments below about this, so I felt I should clarify one detail about the keybase client's trust of the server. When the keybase client requests maria's key from the keybase server, it does not simply trust the public key because it trusts the server (or uses https - huh?).

Rather, the server replies with links to tweets, gists, etc. -- maria's public identity proofs. The keybase client does not trust that these are honest, so it scrapes them directly and makes sure they were signed by the same public key that the server provided. In other words, the server could reply with a different maria, and simply lie, but not with the real maria's github or twitter account.

The server could also lie by omission, leaving out an identity. But it cannot invent ones that do not exist, without the client knowing.

Again, the premise here is that maria is the sum of her online identities.

The website itself is of course a different story. When you look up maria on keybase's website, you are trusting that keybase.io did not lie about her github account. Fortunately you can confirm by following the link to her gist, where she announced her keybase username and posted her key fingerprint.

I don't see why you don't just get the key once, allow you to verify it, and store it locally. It seems pointless to make all these extra requests to you.

There's a reason that gpg does this..... Maria's twitter being hacked, Maria's github being hacked, Maria's Keystore being hacked....a lot can go wrong.

There are still weaknesses like, you lie about a github and link to your own github, and lie about the public key. And...many others.

yes, it does do this; once you're satisfied with maria's identity, that she's the person you want, you sign a statement to that effect, which you can store just locally or post back to the server. (or of course you can just sign her key in GPG!) The latter - posting back to the server - is for portability reasons. A keybase user will likely use keybase on multiple machines.

The point of SKS is signing keys each other's keys and being distributed. This just fragments into a SPoF service without making the existing ones better.

Perhaps I don't understand the whole keyserver concept... But how is a keyserver not a centralised "IdP" like construct?

PGP keyservers talk to each other, if you send your key to GnuPG keyserver it'll end up on MIT's keyserver pretty soon.

Thanks. The WoT depends on not trusting the keyservers, but trusting that humans on the other end know whom to trust and get them to countersign each other's keys.

SSL CAs:GnuPG (GPG/PGP) -> Subversion:Git

I don't see how this is any better than a keyserver and just asking confirming their GPG fingerprint by some other means. Not knowing someone and guessing that their fingerprint is right from some third party is very sketchy because it doesn't use a trustworthy, authoritative source (the other person).

Also, WoT works best when people meet other people they trust in person and sign each other's keys as the GNU/Linux community encourages. https://www.kernel.org/signature.html Then it's possible to get other people's keys elsewhere on the planet and know they're probably good given they're signed by someone you trust.

What the GNU/Linux community encourages is clearly not being useful for making lots of people use PGP.

Then let's make apps that explain i) how it works with pictures and ii) exchange keys more easily: say share key ids with barcodes.

GPG mail plugins that popup a barcode that someone else can scan with their laptop's webcam or some mobile app.

GPG mail plugins should also have a search toolbar that can quickly get a key so it can be verified.

Mobile platforms must support GPG natively, many only support S/MIME.

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.

I wrote "man in the middle" attack, but that's wrong, since the connection is over https. The point is still valid if the server is compromised (or managed by evil people).

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.

These are good news. Thank you and good work!

Even though there is a disclaimer, I think the "encrypt in your browser" feature (https://keybase.io/encrypt) undermines Keybase's security credibility.

This form has essentially the same level of security as Hushmail. Anybody using it should consider the content exposed to Keybase or anyone compromising Keybase.

I'm not an authority on hushmail, but it seems like they do crypto on the server, and the server is just trusted to throw away the keys and plaintext?

In the keybase Web client, all crypto happens on the browser. The server knows no keys or data in plaintext. Of course, you'd have to audit the front-end JS code to believe that claim.

But our intention is that the only way to compromise the Web-based tools would be to insert malicious JavaScript into the client's browser. A read-only compromise of the server yields only encrypted data, and the server never has access to the decryption keys.

As you just said, users must trust the JS coming from Keybase. It might be compromised at any time.

Next, people usually mumble about auditing it, downloading a copy, signing it, etc. At the end of the day, you arrive to code installed on the client - which you already have.

The web version just weakens your story.

But it's a good idea: Sign the js. Even md5 would be enough, it's just so that when the FBINSA subpoenas you, we'll know it.

Then the only difference between hushmail and your model is exactly what the FBI will get a subpoena to have you type into your server to subvert your users. The models are equivalently insecure.

Incidentally, you can't simply audit the "front-end Javascript"; you have to evaluate everything that influences the Javascript runtime (the DOM, stylesheets, cached resources, &c) every time the page loads. Browsers aren't designed to make content-controlled code "auditable"; it simply isn't a capability of the environment.

FWIW, I found your post "Javascript Cryptography Considered Harmful" very helpful in understanding problems with client side crypto in the browser. I will recommend it to anyone who thinks it is safe: http://www.matasano.com/articles/javascript-cryptography/

And don't forget all extensions which can "Access all your data on all webpages, Access all your tabs and browsing activity".

If this functionality were provided by e.g. a signed extension (so the code can't be changed without the user being told: I think browsers can do this?), then you would worry mostly about how well that extension was sandboxed away from other extensions and various websites, right?

Yes, you are correct. Unless browser extensions are used (and even then) the web is not a good platform for cryptography. The web is a platform for letting a potential attacker run untrusted code on your computer without all hell breaking loose, not for building trusted cryptography applications:

http://tonyarcieri.com/whats-wrong-with-webcrypto

Hi Chris, a few comments:

1. I like the site design, the story flow on the front page does a great job of explaining what keybase is.

2. I see (from the abovementioned story flow) that keys can be verified by reviewing signed tweets/gists. Is this functionality extendable to arbitrary links; i.e. verifying keys against personal blogs, Tumblr, WordPress or does the third-party site need to implement a recognized API?

Again, thanks so much, and it looks like a terrific site so far.

Good question! There will be no such thing as a general check, because -- for any identity -- the client software has to perform a check that a human would agree means something. For example, what does it mean that you own a certain blog? How would a person confirm it? Well, at first glance it might mean that you have the power to post a message there. But someone else could do that it in a comment, and so that wouldn't work with Keybase. So any given identity check has to match some human definition of what it means to have that identity. And it has to be publicly auditable.

With twitter, it's the ability to post a tweet under a certain username. With owning a tumblr account, it might be something similar. With your known StackExchange profile it might mean posting a statement in a specific part of your profile. And so on.

The common thread in each case is (1) that you post in a place where only your identity can, and (2) what you post is a signed statement claiming a connection among three things: (a) your keybase username, (b) your public key, and (3) the identity on that third party service. (The third one is necessary so it can't be moved elsewhere.) Note how twitter and github's are totally different, but achieving these three things.

We will build out this list of identity checks, hopefully making all kinds of them easy to do. Everything from proving you own a domain to having a tumblr or reddit accoun. The definition of those checks will all be publicly reviewable, both in the spec and in the client, which is what checks them for you.

Well, to follow up, could this be extended to ownership of a domain (via DNS txt record)? Could we use this as a means of authentication of a self-signed certificate for a domain?

Yes to DNS, though we have to be careful here since DNS can be spoofed more easily than github or twitter proofs over https. I was thinking a slightly better way to prove ownership of foo.com would be to post a proof at https://foo.com/_keybase (or something similar). To spoof this, an attacker would have to spoof DNS and also the https certificate.

Authenticating a self-signed domain certificate via keybase is a neat idea, but would probably need some browser support, unless there's a clever hack that I'm not thinking of.

Well if an attacker is successfully spoofing DNS, she can spoof MX records, thus getting emails for the domain, which is the only precondition on acquiring a certificate. You're obviously adding more complexity, butt security-wise it doesn't change much

Agreed.

Have you heared of PKA? https://grepular.com/Publishing_PGP_Keys_in_the_DNS

If you want to encrypt a message to my key, just run the following command:

  gpg --auto-key-locate pka -ea -r mike([-dot-])cardwell([-at-])grepular([-dot-])com

It will automatically look up my PGP key in the DNS, fetch it, and encrypt to it. My DNS is secured using DNSSEC so if your resolve supports DNSSEC, you can be reasonably sure that the response is trustable.

  mike@glue:~$ dig +short txt mike.cardwell._pka.grepular.com
  "v=pka1\;fpr=35BCAF1D3AA21F843DC3B0CF70A5F5120018461F\;uri=http://grepular.com/0018461F.pub.asc"
  mike@glue:~$

Not with DNSSEC, and the second part is covered by DANE.

Seems like you could get around that with a meta tag on the claimed site? Meta tags are basically never commenter-editable, and are usually owner-editable, they're basically a perfect fit for this. Alternatively there's a site/.well-known/keybase style URL (I have no idea what the best-practices are for .well-known. Personally I prefer meta tags.)

Obviously Twitter isn't likely to implement either of those, so some high-value custom implementations are still great. But if Maria owns maria.com and can assert it automatically, that's pretty strong supporting evidence.

Please remember that some blogs (and possibly other types of sites, such as Tumblrs) can be owned and managed by multiple people.

Chris, a bit OT, but who made the illustrations for the site? They are incredible.

I think https://keybase.io/chadilaksono did. Mentioned near the footer of the main site.

Her portfolio: http://www.hadilaksono.com/

confirmed, yes! Caroline is doing both the artwork and the site design. She's a wonderful artist and we're lucky to work with her. Note the site isn't done yet, so anything that looks funny or imbalanced is not her fault but mine.

Glad to see you're focused on improving, but you're being too hard on yourself. The design is good as is imho (not that there isn't room for improvement). And the idea itself is pretty genius, so I'd say you're ok even if you don't immediately achieve the level of polish you're shooting for.

Great idea and good luck!

Could you do email verification by emailing a challenge to users, and having them reply with a signature of the challenge combined with their email address?

It does demonstrate control of the email account, and you cannot fake it either.

Hi Chris - it looks like a neat idea. One question: Is this another global namespace, or do you plan to support pet names?

Reply on news.ycombinator.com