Could keybase.io do for crypto what GitHub did for Git?
matthew-sinclair.com
matthew-sinclair.com
Keybase.io is very much rolling their own system. I think that answers the question.
It's a store (much like github) for standard PGP/GPG keys. And it provides a convenient CLI for basic tasks.
As far as I can see, it does no more rolling of its own system than Github.
There's no way within GPG to easily determine whether you have a trust path to a given key unless you have all the intermediate keys already.
The big assumption keybase.io seems to challenge here is that your online identity doesn't consist only of your public key.
I think Github helped more in creating a fresh and easy way to follow/contribute to open projects.
To me that makes it seem even more so like keybase. The core of the product is there but it's environment it was makes it special.
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.
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.
But GitHub PR UI is more convenient. At least for me and a number of other users. It also lowers the bar, making contributions more likely.
The people that would have not contributed if there was no GitHub might be wrong, but the projects get more patches. That's it.
Finally, youtube-dl is on GH, but if you send me a patch via email, I can just 'git am'. GitHub won't get in the way.
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.
edit: and you think your previous account got hellbanned because of "disagreement with the herd". Open your eyes and take a look at yourself.
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.
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.
ssh user@rsync.net "git clone git://github.com/freebsd/freebsd.git freebsd"
keybase encrypt maria -m 'Grab a pint tonight?'
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.
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.
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.
Not the worst idea ever, in my opinion.
I prefer to talk on internet forums or exchange clear-text emails, because deniability.
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.
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
However, I don't quite understand how "anyone can forge messages after the conversation" works. Can you explain any more?
The answer is yes. But, as others here have pointed out, you can use ephemeral keys for some applications.
keybase prove {twitter,github}
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.
And the fact that Keybase.io even suggests uploading your private key puts a big fat "AVOID" sign on the service for me.
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.
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.
* 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.
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.
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.
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.
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)
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).
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.
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.
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.
First line of the home page:
Keybase will be a public directory of publicly auditable public keys.
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.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").
And conversely, the "consumers" that aren't compelled by strict requirements to understand how text files work don't need the security anyway.
So then who needs the keybase ?
I'd say this is a pretty big assumption. Wouldn't it be great to live in a world where you didn't need to understand it to be protected by it?
I don't think that world exists. I think this is true in all realms - not just cryptography or infosec...
Yes, but somehow people manage to keep screwing it up in spectacular ways.
Edit1: All gone
Edit2: Coinbase just sent me some more, I sent invites to everyone who mailed me. I got 1 left now.
Edit3: They are all gone now. Thanks for playing!
(Can't see any emails in your profile.)
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.
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.
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.
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.
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)
https://www.virtru.com/what-is-virtru
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.
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.
Also, I don't like the choice of a centralized solution for privacy problem. It could have been decentralized.
It's just like saying, I don't want to list my phone number in this phone book. Doesn't make your phone number any less valid.
There's almost zero impact to you if they shut down.