Isn't gpg already a convenient cli for basic gpg tasks? We have had public keystores (much like github) for decades. There are probably already links to some on your system.
Well, it isn't a PITA for me, and I couldn't imagine pointing my grandmother at keybase.io yet (but I could imagine installing a cert in her mail client for her). Maybe they have a sweet spot there and I am willing to accept I just don't yet understand who fits. But I don't think I'm that special, and I use gpg happily (and efficiently) every day.
If you came late in this thread or somehow still believe keybase.io equals rolling your own system, sokrates wrote a good description of what keybase.io does lower in this thread: https://news.ycombinator.com/item?id=7465349
The big assumption keybase.io seems to challenge here is that your online identity doesn't consist only of your public key.
I assume that he means they are reinventing keyservers (e.g. http://pgp.mit.edu:11371/, and the web of trust for verifying authenticity of public keys), not the crypto itself.
GitHub took a good, hard tool, git, and created a new way for its users to communicate: Pull Requests, GitHub.com repos.
Keybase is taking a good, hard tool, pgp, and creating a new way for its users to communicate: usernames, social account proofs and Keybase.io hosted pubkeys instead of keyparties and keyservers.
Github didn't invent pull requests, and that it seems to be perceived by some as if that was the case is IMO one of the big problems with github, as it serves to create a lock-in like effect (I have encountered projects that didn't have any non-proprietary contact info, so I couldn't contribute my patches).
Email is a perfectly sensible way for sending pull requests, and it has the huge advantage that it's not a centralized service that you need a special account for, any email provider will do. Hell, you even can send pull requests via snail mail if you want to.
First, I explicitly was not talking about sending patches, but about pull requests. You can actually write an email that says "please pull from git://foo.example/project topic-bar" or whatever, that is something quite different from sending mails with patches inside.
Second, this is not in any way about github necessarily doing something wrong, but about its users doing something wrong in making it into a central quasi-monopoly. If you do offer non-proprietary ways for submitting patches, that probably goes a long way - but the way github is used by its userbase (that is, people just assume you have a github account, and don't invest in non-centralized solutions anymore because github is so easy, ...) leads to there being projects that don't have that option anymore, so I actually can not contribute, and in that way, github does get in the way.
The problem is not so much the individual who happens to be hosting some project on github, the problem is the centralization and monopolization that happens when too many people do that.
Also, yes, I do understand the individual motivation for using github, because it has some short-term advantages, but you maybe should not ignore the long-term consequences. The problem is that github's UI being more convenient does not technically depend on github's centralization (technically, github is completely unnecessary for solving the problem), but it is what github uses to build its monopoly. Let me sketch out a technically different solution that would be equally convenient with no risk of monopoly abuse: How about we define a machine-readable open format for pull requests, assign it a MIME type, and then just have git itself or some local git UI (of which there obviously could be multiple different ones, open ones as well as closed ones) registered for handling that MIME type on your system. Suddenly, you could simply use your existing mail account in order to send such a machine readable pull request via email to anyone at any other mail provider (probably with a single git command or UI mouse click?), and they could with a single keypress/click in the mail client start processing/reviewing the pull request. People could host their repos whereever they want, including on their own server, and among the providers possibly could be github, but there would be no risk of monopolization, everyone could use their preferred UI, their preferred git hoster, their preferred mail provider, ..., without that being a hurdle in any way whatsoever. Now, one reason why that does not get developed, I would suggest, is because "github is so convenient".
My point is: There is nothing wrong with making things more convenient, but it would be a good idea to think about ways to make things more convenient _without_ building monopolies, if only because those tend to be highly inconvenient in the long run.
Git is hard because there are a thousand workflows to accomplish similar tasks. Github picked a few flows and rounded the edges and corners. This provided great value.
With gpg, there are already fewer workflows, and there aren't as many sharp edges as git, existing keyservers simply don't have rounded corners ;].
Keybase seems to rely on existing systems for trust anchoring (Twitter, Github...) as well as using existing cryptosystems for doing the heaving lifting (OpenPGP). If Github didn't reinvent the wheel because it's all Git, how did keybase.io reinvent the wheel by being all OpenPGP?
Its not all OpenPGP: it reinvents the web of trust part of OpenPGP instead of integrating with it.
A more 'OpenPGP way' would've been to add a new uid to your OpenPGP key for each service (github/twitter/etc.), and have the 'service' (i.e. github/twitter/etc.) sign that uid on your key.
Except that a lot of people's first experience with Git was through Github. I would say that Git might not have been as popular without Github rather than the other way around.
Do for crypto what GitHub did for git? You mean take something that's already well-distributed and introduce a central SPOF for many people's workflows? Sure, they can do that.
And by making it more accessible bring it to a number of users that before simply went (without VCS or sharing|unencrypted)? Sure, I hope they do that.
Yep, that's a good thing too, but there seemed to be plenty of people (including the OP) already looking at it from that perspective. There are benefits, and drawbacks. Both need to be considered.
I'm not sure I follow where THEY introduced the SPOF. Having a central repo is convenient for many people's workflow so there would probably be a SPOF (In that sense) for the people using github anyway. The difference becomes would you have a team dedicated to maintaining your git repos if you didn't use github?
Is your qualm with the fact that many people share the same SPOF?
Sure Github has their outages from time to time, but it doesn't prevent me from sharing code. Git is still distributed. It might be inconvenient when it is down, but its not a full-out failure of the system.
Escalator temporarily stairs. Sorry for the convenience.
The problem is that a lot of people who use GitHub because it's convenient stop using git as a distributed VCS. They don't have a backup when it goes down, and their productivity is significantly impacted during those service interruptions. In a way you're right that it's not GitHub's fault, except to the extent that such interruptions seem more common than one might expect. This is often what happens when we use web services to make something more convenient.
What's important is that people should consider this downside along with the upside of greater convenience and operational simplicity. Often they'll choose to forward anyway. More power to them and their providers. OTOH, some would be better served by sticking with a truly distributed alternative.
What about the one or (more often) many local versions of the repository on peoples' computers? You can't stop using git as a distributed VCS. Everyone always has a full copy.
Yes, you can do local/personal work, but if GitHub was your only way to share that work with others, or the only place you had your reviews and bug reports, then all of that comes to a halt during the outage. IMX many GitHub users have forgotten (or never knew) how to email or apply a patch so work can go on. They just get totally blocked. As I said in another sub-thread, that's not really GitHub's fault but it's something adopters should consider and (probably) seek to ameliorate.
Yeah, you're right of course, but what's nice is that it's easy to figure the sharing stuff out on demand. That is, using GitHub doesn't do anything to lock you in from a sharing standpoint - it is just as easy to go figure out how to share your code after GitHub goes down as it is to go figure it out beforehand. Certainly from a code review and bug report standpoint it locks you in, but so does pretty much every other code review and bug report tool. I'd love to see a distributed competitor to those offerings take off. Last time I said that somebody pointed me to fossil, and it looks pretty cool for that, but it also comes with an SCM of its own.
Thanks for this. People seem to forget that most people were using a shared upstream anyway, and github made it easier and more reliable to do so while providing a good code-browsing UI and repository directory to boot.
(from their front page) and Keybase.io (or my connection) happens to be compromised, won't it be possible for compromised-Keybase to send me the wrong public key for username "maria", thus allowing others to read my message?
I guess the same could be said about someone posting their GPG key on an unencrypted mail or usenet post, though, so maybe the problem is mostly hypothetical.
The entire idea is that, while keybase stores the pubkey, you don't have to trust them to deliver the right key. They have basically rolled their own type of digital certificate that's stored within a variety of social services, i.e. Twitter -- you tweet something like "I'm <fingerprint of your key> on keybase.io!". The keybase server says this to the keybase CLI: "Bob's pubkey is <key>, and I'm right because https://twitter.com/bob/tweets/1234 says so". The CLI then verifies that the tweet URL really contains the right fingerprint. This extends the trust root to the twitter user (and your local HTTPS CA store). Repeat for a variety of services similar to Twitter. This extends the trust root to the union of all the social site accounts of the keybase user. Whether you choose to trust those is (as always with trust roots) entirely up to you.
That's pretty cool. I was under the impression that it was validating that the twitter/github/etc are owned by the same person, but using twitter/github/etc to validate that the keybase key is correct is much cooler.
However, it's not foolproof. If your attacker (e.g. the NSA) can compromise some of the proof sources, they can return only the compromised proof sources to the client so the client doesn't see anything that contradicts their malicious key. And if the user doesn't know offhand what twitter/github belong to the person their contacting, the attacker could even simply substitute their own sources that claim to be the same person without actually requiring any compromise of the proof site at all.
For example, if I don't know already that maria's Twitter is maria_h20, then the attacker who has compromised keybase can instead return maria_g20, a Twitter account under their control that has posted a proof of the malicious key.
I get that tracking a user will mitigate this, but that only helps if I've already interacted with the user before and chosen to track them.
What if you don't use Twitter, Facebook, GitHub, etc.? Do they have a way of establishing trust that does not involve signing up for various identity-harvesting social networking services? Maybe a certificate that you can host on your own web server or something?
but more types are in the works. Though proving your identity on more than just your personal website has its advantages. For one, I don't know anything about your hosting situation or your security practices.
This seems very sensible. For example, at a key-signing party, as I understand it, ideally everyone knows someone there, or can authenticate via two separate government ID. The benefit here is that keybase.io has removed "government" from the equation.
After what happened to Mat Honan almost two years ago, having insecure systems like Twitter "confirming" my pubkey seems more like a nightmare than a good idea, doesn't it?
And the fact that Keybase.io even suggests uploading your private key puts a big fat "AVOID" sign on the service for me.
Great explanation, thanks. Could you explain how this set up would resist a hostile actor (like say, the NSA) from compelling the site to serve to wrong certificate?
The client verifies the key by checking that the signed tweet, gists, etc., all exist and were signed by the private key that matches that public key. So to get the server to successfully lie, one would need to coordinate lies from twitter, github, etc., all at the same time.
And it would be really hard to get all those services to lie without the recipient being able to tell. They could see that their tweet contains a different fingerprint than they expected, unless you got all those services to lie only to the sender, not the recipient. Which is very hard to do without getting caught.
Is it ever possible to have both security and deniability? Aren't they kind of intrinsically opposed?
I mean, is the same argument to keep security off your home wifi router so that if the MPAA goes after you for seeding torrents, you can claim that it might've been the neighbour.
There's something in-between, though it doesn't actually break the paradox, just makes some different tradeoffs:
In cryptography, a ring signature is a type of digital signature that can be performed by any member of a group of users that each have keys. Therefore, a message signed with a ring signature is endorsed by someone in a particular group of people. One of the security properties of a ring signature is that it should be difficult to determine which of the group members' keys was used to produce the signature
On the IM side of things, you should check out OTR (off-the-record messaging): https://otr.cypherpunks.ca/ - in particular check out the top 4 goals mentioned on that page.
The keys are effectively public once the conversation ends -- they aren't tied to your identity. So those messages could have been forged by anyone, there's no proof they came from you.
What they do is have proofs hosted by the user on different sites (e.g. Github, Twitter) that your client can use to verify that the key is valid. The Keybase server can't fake those without compromising those sites.
In one command, Keybase has acquired maria's public key, her keybase username, and her public identities, and confirmed they're all her, using GnuPG to review a signed tweet and gist she posted. (...) If you trust the client (our reference client is open source), then the server can't give you the wrong key for maria without getting caught or also compromising her twitter and github accounts.
If the keybase tool uses certificate pinning and if keybase.io is using SSL (likely), then a compromise of your connection would also need to be a compromise of the keybase tool on your machine (to defeat the certificate pinning, though if they can compromise the tool installed locally, you have other things to worry about).
You are right however that keybase.io themselves might be compelled by the government (or criminals if you make a distinction there) to serve up modified public keys.
If keybase.io provides a modified public key, doesn't the client detect that by comparing a hash of the provided key to the "proof" hash posted elsewhere?
e.g. In the situation commented above [1], your client would download the altered key from keybase.io, compute a hash, then download https://twitter.com/bob/tweets/1234 and extract THAT hash, then compare the two. The comparison would fail, and you would know that the key you received from keybase.io is not the same as the key that the tweet vouched for.
And certificate pinning means that they store whatever public key was reported for maria the last time, and complain if they're different? I see that that would help.
I would even go farther and include the expected public key directly in the client. That would even defeat attacks where the connection is already compromised the first time you run the client.
maria will publish proofs in a Tweet and a Gist (and hopefully more in the future) and your client will check them, and tell you "maria is @Mmmaria on TW and @mariaz on GH, is this the person you know?"
The server has no say in this, it can only perform a DoS.
caveat npmtor
github's servers can be compromised by a court order, intruder, or employee.
You should use a secondary means of verification to check all the keys fetched
from github where secrecy from courts, intruders, and github employees is
of paramount importance.
This is one of the main advantages of keybase.io, though cipherhub has the advantage of not requiring users to opt-in before you can encrypt a message for them.
You can have SSH keys on your OpenPGP keyring (with the next version of GnuPG at least it should be supported), so then the 'public gist' shouldn't be required by 'keybase prove github' at all:
* you put your public SSH key on your OpenPGP keyring (which is signed by your main identity), you publish your updated key - this proves the relationship between the SSH key and the OpenPGP key
* you use the 'github.com/username.key' to check the association between the github username and the SSH key
This leaves the problem that the assocation between your username and SSH key is weak(er) as its not cryptographically signed, and that you do this validation outside PGP's web of trust model.
Granted, but the idea is that they would have to compromise Github, Twitter, a private domain, and more before performing a successful attack. That's considerably more complex than targeting one service.
As you say in your post, PKSs already associate your public key with your email address as a unique identifier. But there are two points here:
1. Limiting identifiers to email addresses isn't that great a solution. Email is less popular amongst my generation (~20 y/o). It's the service backing almost every identity now, but I already have way too many email addresses which I have to check. What if I want to set up an anon identity?
2. Why, as a person on the street, would I trust pgp.mit.edu more than I trust Keybase THEN (Twitter AND a personal webpage AND whatever other services end up being supported) - it does ultimately depend on how much you trust Keybase, but not obviously so.
Looking back on it in a year or two, Keybase may end up a classic example of "worse is better", because it's easier to grasp, as you said in your post.
You shouldn't trust pgp.mit.edu, key servers are only there for easy distribution of keys (because that's easier than typing in multiple pages of base64), not for providing trust, trust is provided by the web of trust, that is to say, by the signatures of other people who have verified your identity (who in turn have signatures on their keys from yet other people who have verified their identity, and so on). Those signatures are part of the keys that get distributed through key servers, but it doesn't matter whether the key server is hostile, as the key server can not forge other people's signatures.
Also, as an aside: What went wrong there that people have a problem with "too many email addresses to check"? The great thing about email is that it is an interoperable system and you can do forwarding and stuff, so that you can easily have all your emails delivered to one common user interface, no matter how many addresses you have!? I also have quite a few addresses - but I don't "check" addresses, all my email automatically shows up in my one mutt inbox, which is the only thing I have to "check". That's very much in contrast to all those new, proprietary platforms that actively try to lock you in, among other things by forcing you to "check" every one of the platforms independently.
I'm mostly interested in the implications of not using PGP's annotations and rolling their own instead. Still looking for a technical explanation from them about it though, as this will likely be the key point for many tech-savvy when deciding to whether use it or not (I assume).
Storing private keys in a place that you do not control is ridiculous. You are putting your trust in a service, thus making your own keys untrustworthy to yourself.
Put your public keys wherever you want. They are public. The SKS keyservers work well for this already, however.
The idea of getting crypto to the masses is laudable, but this is reinventing existing infrastructure and introducing new dangers to the system at the same time.
Please DO NOT USE keybase.io ... at least until the source is opened and we can see what they are doing.
Encouraging it is still bad news. I think we should be discouraging use of keybase until they fold on this feature and think of a better way.
That said I am new to this whole thing myself. Is there a difference between what goes on in this process, and backing up your private key as you normally do backups? It is encrypted here (granted using a JavaScript CLI which is in itself bad news)
Keybase never has to know what your private key is or store it. So, yes, you are completely free to continue managing your private and public keys however you are used to.
Of course, managing and creating your own keys outside of keybase and then importing your public key in to it does mean you lose out on some of the convenience of the service but, like you say, it's too early to trust them with everything. This doesn't invalidate their novel approach to trust anchoring though (which you can fully partake in without having to hand over your private key).
> Keybase never has to know what your private key is or store it. So, yes, you are completely free to continue managing your private and public keys however you are used to.
And if they did require my private key I could always just not use the service at all. This is sortof besides the point. I'm not concerned about being coerced into anything. I'm concerned that they're sending the wrong message. Do you remember when Facebook used to ask for your Gmail password before we had OAuth? Do you think that was cool too?
> like you say, it's too early to trust them with everything
I'm not saying it's too early to trust them with everything. I'm saying you should never trust anybody with your private key. I don't care if it's my best friend, giving my private key to somebody is one more place it can get discovered. PGP offers something unique in that it can give you a network without any trust. You can weather the storm of broken https and MITMs and get to the person you're talking to. The only thing it doesn't fix is somebody owning your desktop. This is a beautiful thing if you think about it, and this sort of thing would dilute it.
I pretty much agree with everything you've said but I think most of the worries are rendered harmless if keybase are clear and up front about the trade offs. If you have a need for cast iron privacy and security, don't use them. If, on the other hand, you just want a semi-secure solution that prevents run of the mill third parties from intercepting reasonably benign day to day communication then maybe the risk is worth the convenience. You could also maintain a second keypair unconnected to keybase for things that need to be really secure and private.
For me, the interest is solely with their approach to trust anchoring. I like that it simultaneously provides a place to post a brief bio, a public key and a way to tie the key holder to github and/or twitter accounts. I'm using that part of their offering now but I have no intention of ever giving them my private key.
If there could be some sort of plugin that could verify that you're running source that's been vetted, that'd potentially be fine. The problem is that normally you can't be sure of what you're being served, it could be a different program every time.
Even still, a browser is a big complicated program that could be compromised in some way, so it's still an iffy proposition. But, that's just a hunch.
It's a CLI, command line interface. I assumed you were talking about their NodeJS application, which is code downloaded to your computer which you can verify at any time you like.
How would opening the source help? If you're worried about their server you can't be sure of what they're running. The private key you send them, in their defense, is encrypted, and the CLI is open source.
Keybase.io is also a Keybase client, however certain
crypto actions (signing and decrypting) are limited to
users who store client-encrypted copies of their
private keys on the server, an optional feature we
didn't mention above.
I don't get this just like I don't get the bitcoin "hubs" or "wallets" or whatever they are.
Your crypto keys, like your bitcoins, are just small text files. They are nothing special at all and can be completely managed, and secured, on your own local systems.
There is nothing but fragility and loss down this road and people that really need security in their comms will not expose themselves to that fragility (just like smart folks probably weren't putting their bitcoins in third party "wallets").
It's about making these things easy to use for more people. For people who don't have the time / energy / desire to learn about the systems they use, in order to use them.
But then again, it's a bit like making democracy easier by having only one party on the ballot? That is to say: Making things easier in a way that undermines the whole point of why you should be doing it in the first place kinda defeats the purpose, doesn't it?
Yes, I hear that part of the pitch, but in my mind the people that have a need for the security that encrypted messaging provides will need to grasp it deeply enough to not need the handholding.
And conversely, the "consumers" that aren't compelled by strict requirements to understand how text files work don't need the security anyway.
Maybe. But just consider that GitHub popularized git among professional developers. I don't think it's the audience this initiative has to reach. Though it will certainly make crypto more accessible, I doubt that doing the analogous thing to github will give keybase the userbase that would most benefit from their services (less tech savvy people).
Maybe not in this incarnation, but when they roll out an API it could be baked into all kinds of things.
For example, consider a multi-service contact managers like the Windows Phone People Hub or Contacts + on Android. They let you establish a database that represents people as collections of identities across various services. These services could add a feature that discovers public keys hosted with keybase.io for your contacts based on proofs offered by the identities you've already mapped to each contact. This could be presented as a simple "have key yes/no" indicator, and symbols showing which service-identity pairs have vouched for that key, as well as warnings if any of the identities have vouched for a DIFFERENT key.
Obviously client-to-client is always best, but you could extend this model to cloud services, even email. It could provide an organic authentication layer.
Now, you can argue that it's only as secure as your twitter / github / domain. Fine. But your twitter / github / domain ARE you on the internet. For most purposes, you're just "User X on Service Y". It can be useful to be able to prove that outside of Service Y. In addition, it's really valuable to be able to have multiple "proofs". An attacker would need to compromise four separate services to successfully spoof your identity (keybase, twitter, github, domain). That's not impossible, but it is hard and probably slow, especially if you're using two-factor authentication.
Finally, you can add additional out-of-band proofs. Hand-deliver a print out of your key to your associates, then they can pin that proof in the client and use keybase of on-the-fly verification, comparing everything to the key you provided them at your cypherpunk birthday party.
Nice counter-argument, with the concession that this is more like git than it is github. It might really put crypto on the radars of, and make it accessible to, the developers involved in these cloud services - which would be the equivalent of github. A jquery plugin that simply allows developers to include a verify-identity-feature, would actually go a lot further in bringing the rewards of crypto services to the larger audience, imho.
I think this is a fair criticism. However, if keybase is done right, it provides a place for consumer-facing email and storage services to do trust-able key exchange, using trust mechanisms embedded in services consumers already use.
With or without keybase, it is up to the major services to enable email and storage that uses public key encryption to secure it, and to do that with open source clients that can be verified.
Why not? I haven't checked the license that Keybase publishes things under but even if it wasn't an approved open source license, how would that impact the security so long as everything was published?
Their server software is proprietary and they have a feature which will allow users to store their private key with them. If you can't see it, it has NSA inside.
The problem is that my mom does not need to use git or github or even know what they are. I would not mind it if my mom encrypted her emails though, or at least knew how. Offhand, keybase.io looks nice but still a far ways away from a "mom friendly" system.
I'm a coder yet I don't understand much about encryption and certificates and signing. Keybase makes it more accessible to me. If you assume that there's many people like me (I bet there are: non-security obsessed coders, geeks, whatnot), then the existence of Keybase makes these concepts accessible to a larger crowd than before. That's a win.
I am working for Virtru, a startup building the "mom friendly" way to send encrypted email directly from your existing Gmail account (and others!). My Mom does not understand encryption at all, but has no problem using Virtru to communicate securely with some of her business co-workers.
Basically, it works like this (for example, with browser extension client):
1) the client generates a symmetric AES-256 key and uses that to encrypt the email locally
2) Gmail traffics the email to recipients normally, except the body of the email is now encrypted before it even leaves the client (the body also includes the unique id of the key, unencrypted)
3) the key is sent to a third party key store (Virtru) which controls access to the key based on identity (OAuth/OpenID)
It could be interesting to do some type of mash-up with Virtru and Keybase.io so that Virtru could automatically pull recipients' public keys and use a PGP type flow as opposed to the default of a symmetric key.
Happy to answer questions if anyone gives Virtru a try.
What we really need is an intermediary. The people who develop crypto primitives are currently too far removed from the people who develop consumer apps (obviously excepting guys like 'moxie), and (rightly or wrongly) the majority of consumer app developers don't know how or don't care about bridging the gap. A central key repository with de-centralized identity proofing like keybase would be an interesting idea if it had a good developer API (which I assume is in the works) and if good cross-platform PGP libraries existed (a bit trickier... GPG is not iOS-friendly and any lib which ignores that market is not serious about being accessible to consumers).
So, in other words, keybase could be a valuable and important step toward a "mom friendly" system, but it's a bit early to say.
I think the target userbase for Keybase is nerds who found GPG too horribly unintuitive to figure out how to use it for themselves. I know I was like that for a while.
The other target userbase is people who want to verify GPG keys that don't have a web of trust. This is useful for, say, me - I'm not part of the Debian dev team or anything, so I don't have many people around who can sign my GPG key. It's nice to be able to publish a link to Keybase on my website and have people be able to be pretty sure it's me.
I actually really like the trust model that keybase.io uses. You control a lot of a distinct spaces on the web: github, twitter, email, personal domain, etc. It makes a lot of sense to have those reinforce a single public cryptologic identity.
Isn't that the point though? Trust is decentralized over multiple accounts that you already control. Keybase just provides an easy way to access that decentralized trust.
Github is widely used and adopted by programmers. Did it help more devs start to use git? Probably. I honestly don't know. Will keybase.io help more devs start using crypto? Maybe. We won't know for a while.
After reading the site my impression is this just a (somewhat) fancier PGP key server. They're tackling the issue of making PGP easier for people, which I commend. Time will tell if it gets traction.
Sure, but my point is that if key base folded, there's nothing inherently "key base" about any of the underlying data. You still have your key pairs and can put them up somewhere else.
There's almost zero impact to you if they shut down.
Keybase.io is very much rolling their own system. I think that answers the question.