Is there a reason why Keybase does not by default publish all of its public keys to the keyserver network?

[ghost]

I just tried to check some random peoples' keys on Keybase against a well-known keybase server (http://pgp.mit.edu) and almost none of them came up. Is there a reason why Keybase isn't publishing these keys, other than locking people in to using Keybase for encryption?

[zQueal]

other than locking people into using Keybase for encryption?

Sorry. That just made me laugh. You make it sound like Keybase is attempting to become Apple, or something; forcing its users to lock into its technologies.

Keybase seeks to become a platform to make PGP encryption much simpler for the average layman. Not to author keys to online key directories like everyone else. If you want your key propagated, why can't you simply submit it?

[malgorithms]

@jlb1234 - it's not about locking people into Keybase. The simple answer is it's just pretty far down on the feature list. We'd like to implement this...and we specifically chose PGP not because we like it (PGP is miserable in many ways), but because we want to be interoperable with other software, including key servers.

There's much to attract people into Keybase, most notably that (1) our identity proof protocol for places with limited space (e.g. Twitter) leads to proofs that we host, which act as a promotion of the service,(2) we have a convenient namespace, and (3) our client is getting very useful and a compelling addition to GPG. This is enough for us -- a Keybase user can go elsewhere, but we think we offer enough that people will come back, and we're less worried about owning people's data or preventing them from leaving.

The syncing with other key servers thing seems simple at the service: we could just push to them. But this whole key server syncing is fundamentally broken, and implementing and managing key syncing across key servers is actually quite complicated and inconvenient. Different servers can have diffferent subkeys, revocations, etc.? We'd want to do everything right, including reading from others. But...when keybase was talked about a lot on Hacker News, one commenter spoke up that he/she ran a key server and reacted passionately that this was not an easy thing for us to do.

[ghost]

other than locking people into using Keybase for encryption?

Sorry. That just made me laugh. You make it sound like Keybase is attempting to become Apple, or something; forcing its users to lock into its technologies.

Don't misunderstand me - I don't think that Keybase has nefarious purposes. But it seems to me very important that Keybase benefit not only keybase users but also those who use PGP in general. Keybase doesn't have to be a keyserver itself, as Chris pointed out, but all of the public keys listed on Keybase should also be added to the distributed/decentralized network of keyservers by default. That's to say, when I take a keybase user's public key and plug it into a keyserver it should probably be there too. That doesn't mean that Keybase should automatically import changes from other keyservers - just that it should push changes.

It's true that individuals can do this themselves - but it seems to me that one of the advantages of Keybase is that it is building a more user-friendly interface onto public key encryption, doing some things "automagically" for you and adding to the existing PGP infrastructure. E.g. the system of "proofs" adds to knowledge from the web of trust to show that a key actually belongs to someone; similarly the service should cover up some of the rough edges of encryption. I would argue that this means (in addition to perhaps other things) that (a) encrypted messages should be openable by the encrypting user by default, and (b) public keys should be pushed to keyservers by default, so that more people have access to the keys.

[ghost]

Also, @malgorithms, you wrote that the keyserver syncing is "fundamentally broken." How do you see this exactly and do you have any ideas on how to fix it other than scrapping the whole system?

[malgorithms]

Before I add anything else, let me say that I wholeheartedly agree with this:

public keys should be pushed to keyservers by default, so that more people have access to the keys.

If I could magically push a button right now and have two things happen: (1) Keybase pushes all known keys to other key servers, and (2) it doesn't push us into a corner or produce bad behavior for our users, I would. This would benefit Keybase users and make crypto easier. If anything, it would just make Keybase more popular.

What bothers me about existing keyservers? I used the phrase "fundamentally broken" not to be all trashy, but because I think there's something broken in the fundamentals. The fundamentals involve PGP itself, and are perpetuated by the keyservers:

1. The web of trust is really dangerous. I love the idea in theory, but I've been to a key signing party with a whole bunch of smart programmers and it was a mess. It was confusing enough that I don't think I feel comfortable generally trusting most edges in the graph.
2. Anyone can claim to be any email address and push it to a keyserver. This produces pretty dangerous behavior, if you just choose to look up someone by email address (or get contacted by the impostor and look up by fingerprint.) A counterargument to this is of course that the web of trust will isolate this fake account, but I have sub-problems with this: (a) people may ignore the WoT, and (b) it's very easy for an impostor to get into the web of trust. As an example, it's easy for someone to show up at a key signing party with a fake ID. Not all keysigning parties are among people who know each other, and in fact, many happen at meetup type events.

Btw, this brings me back to a point about Keybase and keyservers: right now if you're a Keybase user, you should do a keybase track <whoever> and review their identities, which will import them into GPG. Since this checks all their public signatures and presents them to you, this is much safer than just asking a keyserver. So this is a concern, by pushing to keyservers we might be encouraging bad behavior. Of course, I'd still like these keys on keyservers.

1. synchronization: I imagine in the 90's people had a different opinion about the relationship of the internet and key distribution. The idea of signatures sitting inside the keys themselves is nice for portability (one string to throw on a floppy) and as defense against legislation, but the net result of this system is that everyone's copy of someone's key is a little database, and all these databases are constantly out of sync. Further, there's no concept of timestamping -- something that wasn't really possible until bitcoin. I believe something should change about signed statements. This is something we think we're doing right at Keybase: if you sign an identity-related statement, revocation, tracking statement, etc., it's a function of all previous statements and it's hashed into the bitcoin blockchain. As a result, you can know you have the entire state of someone's public identity, without any missing pieces.

And anyway, if we do push to keyservers, are we going to implement a full two-way sync? This is a massive project.

1. revocations....arggg. this is rough, and something needs to change. I think this deserves another post. But often when someone wants to revoke a PGP key it is too late. They lost the private key.

Anyway, this is just scratching the surface. Again, don't take this as total opposition to keyservers. Just issues we think about a lot.

any ideas on how to fix it

thinking about it...

[malgorithms]

uhh, my numbering got messed up in that post, but you can figure it out

[malgorithms]

btw, one last thing about keyservers: I recently found myself on this page:

https://pgp.mit.edu/pks/lookup?search=gavin+andresen&op=index

[ghost]

Thanks, Chris, for your detailed explanation of your thoughts on the PGP infrastructure of keyservers & the web of trust. I don't think that Keybase can solve all of the problems with the PGP infrastructure, but I do think that you have an opening to make a real improvement - to make a 'more trustworthy' web of trust. You are already starting this with the idea of "proving" that you own a key.

With additional information on how trustworthy a key is (indeed, isn't this what Keybase proposes to do?), when someone looks up a key, if they find a bunch of keys associated with the same name/email (as you pointed to with https://pgp.mit.edu/pks/lookup?search=gavin+andresen&op=index), one can identify the "real" key for the person.

Based on the "outside proofs" of peoples' keys, one can compute with a weighted web of trust (based on the trustworthiness of the keys that have signed your key), determining the areas of the web of trust that are truly trustworthy and those which are not, based on badly-signed keys.

To return to the issue of publishing keys posted on Keybase to the keyserver network: whether or not Keybase publishes the keys - as has been explained it is a difficult task to do properly, and the keyserver network's concept of synchronization may indeed be broken - the Keybase service should participate in and build upon the web of trust, to make it more "trustworthy". That requires working with the keyserver network in some fashion, and the more automated it is the less chance there is for confusion.

[far-blue]

I'm curious about your comments on revocation and having already lost the private key. For reference, recommended practice is to generate a revocation certificate as soon as you create the private key and store it somewhere safe. If your private key is ever lost or compromised you can import the revocation into your public keychain and push it to the key servers without needing access to your private key.

[shenki]

I would like to see this implemented.

Until the feature gets implemented, perhaps following the upload of a key to keybase.io, the user could be prompted to upload their key to a key server themselves. It could suggest the gpg command for doing so.

[dashohoxha]

Keybase doesn't have to be a keyserver itself, as Chris pointed out, but all of the public keys listed on Keybase should also be added to the distributed/decentralized network of keyservers by default. That's to say, when I take a keybase user's public key and plug it into a keyserver it should probably be there too. That doesn't mean that Keybase should automatically import changes from other keyservers - just that it should push changes.

I completely agree with this.

All the cases against GPG and keyservers are mostly social problems, amplified by bad client design/implementations and missleading tutorials.

thinking about it...

You cannot claim that GPG is bad, without being able to propose something better. Until now I have seen only the tracking concept from Keybase, and fancy graphics and web interfaces. What is the design (and how does it compare with GPG), what are the plans, where are you heading to? Have I missed something?

[mitar]

I think this is a duplicate of #327.

[anapsix]

As mentioned in #327 ..

Made myself a lame proxy GitHub: https://github.com/anapsix/keybase-keyserver-proxy Docker Hub: https://hub.docker.com/r/anapsix/keybase-keyserver-proxy/

docker run -d --name kkp -p 11371:11371 anapsix/keybase-keyserver-proxy
sleep 3
gpg --keyserver 127.0.0.1 --recv-keys B416D3911B1D1AA0D47D5F4E5E93F7F309CAC1B2
docker rm -f kkp

Alternatively, you can use my instance

gpg --keyserver do.random.io --recv-keys B416D3911B1D1AA0D47D5F4E5E93F7F309CAC1B2