Refusing to verify myself: I am liz on Keybase.io

    curl https://keybase.io/[them]/key.asc | gpg --import

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-w...

It will be the case very soon that you can push your key to Keybase and prove all your identities, without ever installing the client the OP dislikes. Technically, you can already, we just need to put together very explicit instructions and documentation that's different for each kind of proof. By ugly necessity, what it takes to prove yourself on twitter is different from github is different from DNS, etc. Documenting the API was our priority coming into this week.

Later this week the site will have very specific instructions on how to prove your identities (even the complicated ones) simply from your shell plus GPG.

Then those who care can verify all those proofs with a script, in a language of their choice. No Node or NPM needed for any of it.

There was some discussion below about "trusting" the Keybase server's definition of the public key that comes back. The goal here is to remove that trust. Software of your choice can download a Keybase user's keys, the links to their proofs.

Your OS's package manager is simply wrapping up whoever else's software in a nice pretty bow and releasing it. The only veracity it has is that the person who put the bow on it signed it. It's highly unlikely they did any kind of "independent auditing" or managing beyond writing some script to build the software.

Or worse: if Debian is an example, they'll say "I don't understand this code, therefore it's not useful", comment it out, and ship horribly broken software to you.

At the end of the day, you have to trust someone. Whether you trust keybase.io or not is entirely up to you - liz setup an incredibly tedious blog post to basically say just this.

Or, if paranoid enough, you can store the key on a stick (like a cryptostick) - in this case, it doesn't matter what you type in since the key never escapes.

Note that this is all while assuming that you do not trust what runs on your computer.

On the website, all crypto is performed in JavaScript, in your browser. Some people have strong feelings about this, for good reason."

There will be 2 ways to "prove" yourself as a programmer on Keybase:

1. running `keybase prove github` (or whatever service) which is interactive; the keybase client can generate the nice statement for you and pass it off to GPG for signing. This is already working.

2. running something in your shell which requires nothing but gpg and standard shell commands. The key elements here are that you need to generate a signed statement connecting your two accounts, and you need to post it on github. This is pretty simple and won't require Node at all.

Oh, and 3. using some other software of your choice that implements 2.

The reason #2 isn't documented yet is that it's a bit more complicated in certain cases. Consider what it takes to perform a twitter proof (click the "show the proof")

https://keybase.io/chris/sigs/DZ9rccBD8u-Att6kQzhHHtw-924s7i...

The signed statement itself isn't hosted on twitter (it won't fit) but needs to be boiled down into an agreeable tweet-sized hash. In order to prove twitter manually, you need to generate this statement, boil it down, make the tweet, and push the statement to Keybase.

All this will come, and our goal with Keybase isn't to require Node or npm for anyone.

EDIT: also wanted to add that node exposes your standard POSIX-style interfaces to the OS, so there's really no reason it can't be a general purpose replacement for other languages for writing system tools.

Anyway, in our case we (1) like the async programming model, and actively use it -- on the server side, our services tend to be modular and actually speak over RPC layers to each other, not just one big ugly web process. Node is great at this.

And (2) in this case, because we wanted to have a lot of shared code among our first implementation of a client, our browser front end, and our server. It worked very well to work on all three with one language. It's worked out.

I personally miss compiling C++. :-)

There's a very good chance we'll end up writing a Go client for Keybase. We might switch the official reference client once the functionality is more locked down.

Lastly: it's really CoffeeScript, not JavaScript. Which is a different can of worms to open on here.

However, this does not protect against a malicious service provider from modifying the message to replace it with a different user.

Assuming you actually do this level of verification yourself (rather than allowing keybase to do it for you), the only thing you have to trust is that Keybase/Twitter/Github/Facebook/etc aren't all simultaneously colluding to give you a bad key. That seems to me like a reasonable assumption in pretty much all plausible circumstances.

To put it shortly: it's not Keybase that verifies that `liz` is a certain Facebook account. `liz` generates cryptographic proofs and publish them on Facebook, you get them and verify them. Keybase.io can't switch anything, unless also `liz`'s FB (and Twitter, and GH...) is compromised and the proofs switched.

This is a common and understandable misconception with Keybase threat-model, they should probably try even harder to put it up front.

What OP says is that she does not trust the way the tool to generate these proofs is distributed.

You say that people should start with authentication. That's exactly what keybase is trying to do. Realize that it's a hard problem. How would you implement it?