What I think that they get very right is tying keys to social identity, as these networks function much better as a web of trust than the original PGP version. But I don't know why I can't shake the feeling that this is not a trustworthy service.
One really nice aspect of keybase is that it can be used at a number of different levels that suit one's own flavor of paranoia. You can use it as a key repository, just grabbing people’s keys and using your own PGP/GnuPG apparatus for signing. Or you can use their (much more pleasant) CLI and see their social identity tracking data. Or you can use their web UI just for client-side encryption/verification (also without uploading your key anywhere). Finally, the bold can upload their keys and use the web UI for the whole shebang, including decrypting/signing.
I think paranoia is warranted in this day and age, and I think one of the best outlets for paranoia is for people to try and educate themselves about privacy technology. Keybase is a great opportunity for that, since all of the most sensitive operations happen client-side via open source software.
This comment demonstrates everything that is disappointing about GPG. Went to a Defcon London meetup recently and there was only about 10 people in the room who actively used it (out of over 100)
Oh cool - thanks for linking to that. I actually think the Github discussion that followed on Express was a good example of how people can actually collaborate well on software. In this case it just led to resolving a misunderstanding on my part: https://github.com/strongloop/express/issues/2464
At the bottom you can see I tipped some BTC. I recommend everyone should have a little balance of cryptocurrency to throw out thank yous to project managers who take the time to explain usage. It's worth a lot to you, so you should give some back.
I love the idea of Keybase and wish more people were using it. While it's not a replacement for keysigning parties, it's a nice probabilistic model for casual security.
We're working pretty hard on Keybase. For the last year it was just 2 of us (me and https://keybase.io/max) , but some amazing people just joined the cause and we're building a much better service. Our Go client, for example, is almost on feature parity with the old Node reference client, and we've started working on a nice OSX GUI.
A lot has been written about PGP and its shortcomings, and we agree with pretty much all the points: client integration problems, usability, the WoT just sucking, key management, revocations. So far at Keybase we've attacking one of the most important problems with PKI in general, not just PGP: getting the right key for someone. But it's really only one piece.
I don't want to (yet!) give away too much of what we hope to launch later this year, but there's nothing about Keybase that's specific to PGP. Or chat - which people seem to get hung up on. We think we're in a very good position to release open source software that makes people's lives more secure and more convenient. Everything from financial transactions, chats, and releasing public software should be easy with a PKI. It's just not working yet.
If I may use this as a way to publicly suggest some features that I would love to see:
- Client should support looking at my existing trust.db. I already have a number of signatures I collected pre-keybase, and I have verified a bunch of identities. I'd like to use these, and in fact be able to tell keybase.io that I have more than just social web proof that these are who they say they are.
- Ability to use email addresses instead of just keybase names when referring to users.
- Autocomplete when typing handles/emails on the client's command line. Using the Node client currently without this feature.
- When I tried to encrypt a file using keybase recently, it gave me an obscure error (#100) instead of telling me that I was logged out.
- encrypt should not silently create a new file by default. It should not overwrite an existing file either. Do `keybase encrypt joe@example.com foo.txt` twice, and have foo.txt.acs overwritten the second time. Instead by default it should output to stdout, and let you specify a file as an optional argument.
- Lastly, and this is way outside the scope of what keybase currently does, I'd love a built-in tool for exchanging encrypted files. Currently, I use chunk.io + curl + gpg to do this:
I am not suggesting that you guys host any type of file sharing tool, but perhaps integration with a service like chunk.io or similar would be nice. Otherwise, the process of sharing a secret (say a file with API keys, etc.) with a co-worker is to encrypt the file, then email it, which is annoying.
I think keybase.io will be an important part of solving public key cryptography usability, given that more of my friends are on keybase.io than there were ever on the PGP keyservers.
My thoughts are that with the implementation of data retention laws in Australia the ultra paranoid arena of PGP is becoming of greater relevance to the average citizen and so a simple, easily implemented, non-centralised, publicly identifiable crypto for everyday comms may become not only viable, but sought after - http://blog.lrdesign.com/2014/03/thoughts-on-keybase-io/
I will invite people to lobste.rs. Because of their rules (you misbehave, I have to bear the consequences) I will not just invite anyone, but only people I can find on the net and can be reasonable sure are not assholes.
So write me a mail with some information about yourself (have a look at my profile for the address) and if you don't look like a total dick I'll send you an invite.
How can a web service encrypt your plaintext unless they have your private key?
Edit: ah you up an encrypted private key. I guess it gets decrypted live in your browser, without touching their network, if you trust keybase.io's JS. Whether you do indeed trust keybase IO's JS (it's OSS, yaay, is your browser running exactly what's on GitHub though?) is another matter.
It's because asymmetric cryptography is very inefficient, so most protocols just use asymmetric public/private keys to send a symmetric key (AES, etc) to the recipient, so further communications can happen over the much more efficient symmetric keys.
That's actually how PGP works too - it generates a random symmetric key, encrypts the message with it, then encrypts that key with the recipient's public key and both message and encrypted symmetric key are sent.
