maxtaco

A lot of the same techniques. No need for proof-of-work since there's no contention for a scarce resource.

We might, in the future, periodically write our root block to the Bitcoin blockchain as a further protection against forking attacks.

This feature is now live on keybase.io. You can prove Twitter, GitHub or Web site identities without posting a secret key or installing our installer. We give you a (rather long) pipeline to run at your shell.

Install-less, hosted-private-key-less Github, Twitter and Web site verifications are now live on keybase.io. Enjoy!

We hope to roll out 2FA shortly. If enabled, you'll need to present a token before retrieving your encrypted private key from the server. Though of course it won't help if our server is hacked or subpoenaed.

We haven't tried cracking uploaded keys. It's a good idea, but expensive, we could be using those cycles to mine litecoins instead!

Thanks for your feedback, we appreciate it.

Many Random Oracle crypto proofs assume a value is random and then substitute in something that's not quite so good, so I think it's a valid thought experiment. And some passwords do have 256 bits of randomness (i.e., ~15 random words from the dictionary). I think we disagree on what margin of password security we feel comfortable with.

Hopefully the pace of changes will slow down once we arrive on the correct core feature set and we sort out the bugs. An earnest thanks to HNers and others for being such great alpha testers BTW.

A browser extension is in our (ever-expanding) todo list. We had one a few months ago, but we have to do a fair amount of work to get it back up to snuff.

Yes, it is, and it's 100% open source.

Hmm, interesting idea. In general, there is only one sensitive operation per keybase invocation (though many signature verifications that use only public keys), so this is doable but cumbersome.

It was a thought experiment to encourage people to think about the issue at hand and not dismiss it with a knee-jerk. Your concern is now key stretching and password selection.

We're definitely worried about the hushmail attack, and we disclaim browser-based crypto on the site for those who want to protect against powerful adversaries. Some users might not have those concerns.

You've obviously indicated valid concerns, but note, they're not indictments of storing an encrypted private key on the server so much as they are of browser crypto.

k is derived from a password in this case, so capture of the password implies capture of k.

We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.

Agreed. We wish there was a practical solution to this problem, but at some point, it's turtles all the way down.

We agree this is a problem, all of those who try to access their private key during the compromise would be in trouble. Those who stayed offline would be safe.

BTW, this argument does not extend to the CLI or other uncompromised clients. People who sync their private keys across devices with the CLI are unaffected.

There's one instance in which we prompt for your PGP password directly, since gpg doesn't give us command line access to the needed feature: that's adding the username <you@keybase.io> to your public key if it's not already there. Aside from that, we never need your PGP password and just rely on gpg to prompt for it when needed. If you're seeing other prompts, it could be bug, please let us know!

We seem to have hit a real nerve here. I ask everyone to question their assumptions just for a moment. If you post a public key, you are letting the world see p*q. Is it insane to let some people see AES_k(p,q) if k is 256 random bytes? If you think yes, then you are making a strong judgment about the relative difficulty of two very different problems in Crypto that are thought to be quite hard. I realize there are issues surrounding coming up with good k's and keeping those k's secret; are these issues at the core of people's objections?

Indeed, the chicken paper inspired the work of Mazieres and Kohler. They should have cited it, maybe that's why SCI rejected them.

At the time, there was an arms race within the systems community to see who could flip a bigger bird to the organizers of the SCI spamference. David Mazieres and Eddie Kohler started it off when they submitted "Get Me Off Your Fucking Mailing List" [1] for publication. We wanted to one-up them and figured we could do so by submitting a random paper that might be accepted into the conference, allowing us to give an in-person talk. The plan worked up to a point, but when we asked the internet for $3k to send us to Orlando, the press and then the organizers of SCI caught wind and revoked the random paper they had previously accepted.

Everything since has been gravy. We're pumped that SCIgen is still a useful weapon against charlatans the world over (this now includes you, IEEE and Springer).

[1] http://www.scs.stanford.edu/~dm/home/papers/remove.pdf

The papers in question were generated by the SCIGen paper generator. Jeremy Stribling, Dan Aguayo and I are the authors of that system, with Jeremy doing the lionshare of the work. The inspiration for SCIgen was TheSpark.com's high school paper generator, which ran from about 1999 to 2001. To call these autogenerated works gibberish is an affront to those of us who hand-assembled their context-free grammars!

Agreed.

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

As Chris said, we would like to publish everything, just haven't found the time yet. We have bits and pieces in wikis in our various github repositories (almost all of which are open source and public).

The high bits are: all crypto is with GPG/RSA as per RFC4880. There are of course problems here, but we wanted backwards-compatibility and well-tested, well-used clients.

We encrypt server-stored GPG private keys (if you choose to use that option) with TripleSec (see https://keybase.io/triplesec).

Users use GPG to sign a series of JSON objects, of the form "I'm maxtaco on twitter", or "I checked Chris's proofs as of 2014/2/14 and they look good to me." All JSON objects that a user signs are chained together with SHA-2 hashes. So a user can sign the whole group of JSON statements by just signing the most recent one.

Here's an example (click on "Show the Proof") https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1Wu...

There's a fair amount of engineering that went into the software distribution system. We rely first on npm to get the initial client out there, but after that, exclusively GPG for code-signing. That's documented here:

https://github.com/keybase/node-installer/wiki/Update-Archit...

We hope to have better documentation soon, and we value feedback, we just haven't had the time to put it together yet.

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.

Yes, though it might be broken right now. Our plan is to allow this, for sure.

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.

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

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.

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.

Sorry, that was a little joke. I don't think anyone should hold more than a small portion of their total assets in cryptocurrencies.

Seriously, the centrifuges connected to your 2008-era Lenovo netbook might be totally rooted after this transfer.