19 ms·
Could keybase.io do for crypto what GitHub did for Git?
- davidw 13y agoThe 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.
- skrebbel 13y agoIt's a step in the right direction. 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.
- ndeine 13y agoI 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.
- edraferi 13y agoI 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.
- conorgil145 13y agoI 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) https://www.virtru.com/what-is-virtru 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.
- napoleond 13y agoWhat 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.
- skrebbel 13y agoI'm a complete crypto noob, but if i do keybase encrypt maria -m 'Grab a pint tonight?' (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.
- sokrates 13y agoThe 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 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. Not the worst idea ever, in my opinion.
- skrebbel 13y agoWow, that's pretty cool indeed. I completely did not understand that off their landing page though. Thanks for the clarification!
- Fede_V 13y agoGreat 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?
- malgorithms 13y agoThe 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.
- RyanZAG 13y agoGitHub is good because it doesn't re-invent the wheel - it uses Git. If Github had rolled their own system it probably wouldn't have taken off. Keybase.io is very much rolling their own system. I think that answers the question.
- suhair 13y agoWe're not reinventing any cryptography here - the goal is a simple way to look up and trust keys, based on known public identities. from keybase.io
- Crito 13y agoI assume that he means they are reinventing keyservers (e.g. http://pgp.mit.edu:11371/ http://pgp.mit.edu:11371/, and the web of trust for verifying authenticity of public keys), not the crypto itself.
- masklinn 13y ago> Keybase.io is very much rolling their own system. 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.
- el-dawg 13y agoIsn'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.
- JulianMorrison 13y agoWhere's the money stream, will they disappear or be aqui-hired?
- atonse 13y agoDoesn't matter - same with github. If you don't want to use their service, you stop. 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.
- JulianMorrison 13y agoGithub sells private repos.
- atonse 13y agoSure, 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.
- oijaf888 13y agoThe creators founded/exited SparkNotes and OkCupid. I don't think they are looking to be aqui-hired.
- dublinben 13y agoThat doesn't mean the site doesn't need a sustainable business model.
- irickt 13y agoCould Github do for crypto what Github did for Git? https://github.com/substack/cipherhub https://github.com/substack/cipherhub
- defrex 13y agoFrom the README: 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.
- edwintorok 13y agoYou 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.
- renata 13y agoIf you think keybase.io cannot be compromised by a court order, intruder, or employee, I have a bridge I'm looking to sell on the cheap.
- defrex 13y agoGranted, 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.
- rk17 13y agoMaybe. 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).
- Zigurd 13y agoI 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.
- rk17 13y agoSo what crypto needs is an easy-to-use plugin for developers, so more end-users can take advantage of this software.
- edraferi 13y agoMaybe 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.
- oznathan 13y agoIf I were them I would market more the online identity verification aspect and not mention one word about crypto or GPG. Also, I don't like the choice of a centralized solution for privacy problem. It could have been decentralized.
- edraferi 13y agoIsn'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.
- oznathan 13y agoIf they hold your key, your privacy can be violated. By them, by someone who buys the company or by a secret government court order.
- icebraining 13y agoThen download the client and store the key yourself.
- oznathan 13y agoI can't store the key myself and I wouldn't want to. I can create it myself but it's stored in a central key server.
- matthewsinclair 13y agoI've made an update to the original post to link to this article: http://blog.lrdesign.com/2014/03/thoughts-on-keybase-io/ http://blog.lrdesign.com/2014/03/thoughts-on-keybase-io/ which has some good arguments against my original optimism.
- caio1982 13y agoI'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).
- jeffbr13 13y agoAs 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.
- zAy0LfpBZLC8mAC 13y agoYou 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.
- stonogo 13y agoIf by "what GitHub did for Git" you mean "turn into a social network for programmers and nobody else," then the answer is "maybe."
- notacoward 13y agoDo 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.
- dasil003 13y agoI think you should look at the adoption curve of git before and after GitHub to temper your snark. edit: and you think your previous account got hellbanned because of "disagreement with the herd". Open your eyes and take a look at yourself.
- notacoward 13y agoLikewise, I'm sure. Did your personal attack, grounded in defense of the conventional view, contribute to the discussion?
- dasil003 13y agoYou're a hilarious guy. Don't dish it out if you can't take it.
- CJefferson 13y agoWhere is this adoption curve for me to look at?
- FiloSottile 13y agoAnd 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.
- notacoward 13y agoYep, 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.
- huslage 13y agoStoring 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.
- corford 13y agoYou don't have to store your private key with keybase.
- orblivion 13y agoEncouraging 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)
- corford 13y agoKeybase 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).
- orblivion 13y ago> 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.
- dewey 13y agoIf you want to see for yourself, shoot me a mail. I have 2 invite codes to share. 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!
- aaren 13y agoI'd like an invite if anyone else has one! Email in profile.
- dewey 13y agoEdit4: Obviously I was talking about keybase, not coinbase. Too late to edit now.
- bitcrusher 13y agoFollowing dewey's lead, I've got 6 invites to share. Shoot me an email or reply here. First come and all of that.
- kstrauser 13y agoMay I have one? I'd email you directly but can't find your address here.
- bitcrusher 13y agoSure, my email address is in my profile.
- 13y ago
- davexunit 13y agoProprietary software and security do not mix.
- orblivion 13y agoThe CLI is FOSS as far as I understand.
- oijaf888 13y agoWhy 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?
- davexunit 13y agoTheir 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.
- blahbl4hblahtoo 13y agoProbably not.
- joshdance 13y agoGithub 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.
- brianbarker 13y agoAfter 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.
- rsync 13y agoI 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").
- endlessvoid94 13y agoIt'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.
- rsync 13y agoYes, 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. So then who needs the keybase ?
- endlessvoid94 13y ago> 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. 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?
- rsync 13y agoYes, it would be great. I don't think that world exists. I think this is true in all realms - not just cryptography or infosec...
- 13y ago
- deleted 13y ago[deleted]
- vgrichina 13y agoBut Github is already doing same thing for crypto as it is doing for Git ;) https://github.com/substack/cipherhub https://github.com/substack/cipherhub