I like the idea of Keybase.io, but I would prefer to use it in a way in which I don't have to trust them at all. As it stands, you need to install their command-line tool and have it directly manage your GPG keychain. For that, I'd prefer to have a platform-neutral tool that's been independently audited and managed by my OS's package manager rather than their keybase-installer tool which seems to want to update very frequently with who-knows-what changes.
While we like being #1 on Hacker News, bad (good?!) timing is what earned us this spot.
It will be the case very soon that you can push your key to Keybase and prove all your identities, without ever installing the client the OP dislikes. Technically, you can already, we just need to put together very explicit instructions and documentation that's different for each kind of proof. By ugly necessity, what it takes to prove yourself on twitter is different from github is different from DNS, etc. Documenting the API was our priority coming into this week.
Later this week the site will have very specific instructions on how to prove your identities (even the complicated ones) simply from your shell plus GPG.
Then those who care can verify all those proofs with a script, in a language of their choice. No Node or NPM needed for any of it.
There was some discussion below about "trusting" the Keybase server's definition of the public key that comes back. The goal here is to remove that trust. Software of your choice can download a Keybase user's keys, the links to their proofs.
Excellent! I'm glad that we're on the same page here. Thanks for making the service, once the single point of trust (your client) is removed I should be able to fully recommend it to everyone I want to communicate with.
Just a thought: I like how you walk the user through the steps you took to prove that the owner of the private key signed the tweet. I suggest you also provide the appropriate commands to perform the verification ourselves as well. The client does this, but for users operating without it it'll be very useful.
This feature is now live on keybase.io. You can prove Twitter, GitHub or Web site identities without posting a secret key or installing our installer. We give you a (rather long) pipeline to run at your shell.
Interesting, I didn't know that. I still need some way to produce the verification files/tweets for my own account, though, and currently the only way to do that is with the client. (Maybe it works in the browser if you upload your key, I did not do that for the same reason the post author didn't.)
Additionally, I have used GPG and their website with javascript based crypto in some cases without using their NPM app. I believe their goal is to get other client implementations out there on the public api.
Basically, there's a whole id/ namespace where you register your personal information, and there's a d/ namespace where you register domain names (akin to DNS). Onename is the same except they use i/ (they haven't even tried to discuss it and basically did it all from scratch to start clean)
The major problem is that you basically need a namecoin client to interact with the data... unless you use dnschain [0], which act as a HTTP-to-Namecoin and DNS-to-Namecoin bridge. Try this:
And unlike keybase's "it's complicated so it must be good" proofs, onename's proofs are easy -> add a pointer from your onename namespace to your social media property and a pointer back to onename to prove you own it. No need to generate signatures that break when anything changes.
please correct me if I'm wrong, but I think this is not really decentralized.
It's a single authority that owns a namespace in namecoin and is giving out sub-names.
It's decentralized in the same way a twitter account is.
Anyone running a full Namecoin node (ie, anyone running Namecoin client) can register an identification.
OneName is providing a convenient web portal to this key-value store on Namecoin, so their business model is somewhat analogous to Blockchain.info's (or perhaps they have another business model in mind, who knows?).
Nobody can own namespaces. They're "just" acting as a middleman for buying names in Namecoin in a namespace they've defined themselves, but anyone could bypass them and buy their own names in that namespace.
The annoying thing is, we already have a namespace for identities, it's standardised and documented on the wiki. They came in and defined their own namespace for no good reason.
> platform-neutral tool that's been independently audited and managed by my OS's package manager
Your OS's package manager is simply wrapping up whoever else's software in a nice pretty bow and releasing it. The only veracity it has is that the person who put the bow on it signed it. It's highly unlikely they did any kind of "independent auditing" or managing beyond writing some script to build the software.
Or worse: if Debian is an example, they'll say "I don't understand this code, therefore it's not useful", comment it out, and ship horribly broken software to you.
At the end of the day, you have to trust someone. Whether you trust keybase.io or not is entirely up to you - liz setup an incredibly tedious blog post to basically say just this.
Part of what distribution-managed trust establishes is that it puts all distribution users (of that particular distribution) in the same boat. This is incredibly useful for verification purposes.
If I cared, I could even cross-verify across distributions by comparing their source tarballs.
> Or worse: if Debian is an example, they'll say "I don't understand this code, therefore it's not useful", comment it out, and ship horribly broken software to you.
The other point of view: they fix software so that it is useful, and I can easily have an integrated system. For the one problem you point out, there are hundreds (or probably even thousands) of useful integration patches that distribution users take advantage of every day, without even realizing it (and those suitable for upstream projects generally get pushed that way, too).
If you don't like distributions, then don't use them. And have fun with that.
How do I know that the changes keybase-installer is downloading are the same as those in the repo? I'd have to do a lot of legwork every single time I update just to be sure. Better to use a tool I can verify once and use forever, or better yet, not use one at all.
Hopefully the pace of changes will slow down once we arrive on the correct core feature set and we sort out the bugs. An earnest thanks to HNers and others for being such great alpha testers BTW.
In reality, the biggest risk for routine comsec with pgp is that no one uses it because it's difficult, but the very specific app of code signing is something where keys need a lot of protection IMO. (I am mostly fine with START TLS for email security 99.99% of the time)
The thing which terrifies me is that the npm keybase app asks for my GPG key directly in the same window, and it's impossible for me to (easily) tell when the password prompt is from my GPG binary (which I pretty much trust) vs. the npm binary.
I'm using keybase now (rdl), mostly because I trust Chris Coyne personally, and because my key is old. I'm creating a new 4096 RSA key soon, and will be a lot more paranoid about protecting it -- it will only ever exist on read/use only smartcards after initial generation on a secure machine. (sadly, openpgp card doesn't support export and replication, so to be durable, I have to generate it externally and load onto a bunch of cards and then delete the external key; I'm not willing to trust my keys to a single smartcard I carry with me.)
Using keybase with gpg agent is maybe a bit safer. I don't really mind being forced to do bad stuff by keybase, due to the risks to them if they're caught, as long as it doesn't expose my keying material. gpg agent plus a hardware smartcard should mostly protect me. The pure-software alternative would be a bunch of text-file messages which I can manually cut and paste and move around between clearly-distinct processes running in separate shells/windows (or machines!).
I've been thinking about something a lot better than openpgp card, though, as a secure end-user key management device, with more than just key protections. Unfortunately that means making custom hardware, and that makes little sense in the volumes PGP achieves; maybe if there are other client-side security credentials like ssh or bitcoin, I'd do it.
There's one instance in which we prompt for your PGP password directly, since gpg doesn't give us command line access to the needed feature: that's adding the username <you@keybase.io> to your public key if it's not already there. Aside from that, we never need your PGP password and just rely on gpg to prompt for it when needed. If you're seeing other prompts, it could be bug, please let us know!
The point is that in a terminal window I have no idea what comes from the keybase binary vs. the gnupg binary it calls out to. You could throw up a convincing looking prompt, steal my passphrase (optionally crashing or passing it on to the real binary to delay suspicion), and then send the key and the passphrase back to your servers.
Realistically, I'm not going to validate the keybase binary, npm, etc. every time I update the app. (and even if I am, many users won't). And a "user of interest" could be given a "special" binary pretty easily.
If your binary output a text file or whatever with commands for GPG, which I could then execute and put back into keybase, that would solve the problem.
I agree, usability nightmare, but it would be a nice paranoid option.
Hmm, interesting idea. In general, there is only one sensitive operation per keybase invocation (though many signature verifications that use only public keys), so this is doable but cumbersome.
If you care about this, then use an agent (eg. gpg-agent). With this general mechanism, you can arrange your own system, including something out-of-band if you wish.
Anyone using gpgme will trigger the pinentry program, which you can make recognisable if you need a trusted UI.
Or, if paranoid enough, you can store the key on a stick (like a cryptostick) - in this case, it doesn't matter what you type in since the key never escapes.
Note that this is all while assuming that you do not trust what runs on your computer.
You can build a newer version from an official Ubuntu source package. Start by adding a line to a file in /etc/apt/apt.conf.d/ that pins all your packages to 12.04, "precise":
APT::Default-Release "precise";
Then add a line to your /etc/apt/sources.list to include saucy (or trusty), which has the right version of node.
deb http://archive.ubuntu.com/ubuntu saucy main restricted universe
deb-src http://archive.ubuntu.com/ubuntu saucy main restricted universe
Saucy won't be supported after this year. You can either use Trusty now, or wait for Trusty to be officially released next month and then switch.
This puts the packages in the current directory. Now just install the one(s) you want:
dpkg -i nodejs_0.10.15~dfsg1-4_amd64.deb
Edit: wow, I just noticed how many packages that build-dep step pulls in. I hope that doesn't step on anything important :( At that point, you might as well just add a file /etc/apt/preferences.d/01node with these lines:
I've only been glacing here and there, but I keep seeing discussion of uploading ones private key to keybase being an actual mechanism that is supported / encouraged / extant ?
The existence of that option is utterly insane IMO. I assumed it was some kind of IQ test for users; if they accept the offer, they get deleted. Sadly, that seems not to be the case.
We seem to have hit a real nerve here. I ask everyone to question their assumptions just for a moment. If you post a public key, you are letting the world see p*q. Is it insane to let some people see AES_k(p,q) if k is 256 random bytes? If you think yes, then you are making a strong judgment about the relative difficulty of two very different problems in Crypto that are thought to be quite hard. I realize there are issues surrounding coming up with good k's and keeping those k's secret; are these issues at the core of people's objections?
Imagine that Keybase is compromised. It starts serving a password-prompt page that looks identical to the previous, but now sends your decrypted key straight to the malicious attacker.
Storing your private key on Keybase allows Keybase to become a single point of failure, which pretty much defeats the whole point of distributed social verification in the first place.
And worse -- it only needs to send that special password prompt page to a specific IP or user of interest, and maybe only when it comes from a mac box (if the victim is known to do auditing on a linux box, but uses it as a regular client on mac).
Shipping packaged software with evil inside to ~everyone is risky because at least one user is likely to find a bug (accidentally) and try to trace/reverse/whatever (or, at the very least, if you do networked evil, some kind of IDS/firewalling).
Per-user downloads, especially at time of each use, are vastly more risky; this is the "hushmail attack".
We're definitely worried about the hushmail attack, and we disclaim browser-based crypto on the site for those who want to protect against powerful adversaries. Some users might not have those concerns.
You've obviously indicated valid concerns, but note, they're not indictments of storing an encrypted private key on the server so much as they are of browser crypto.
As an aside, the web is an extremely convenient application distribution platform, it seems like a shame we can't securely use it for anything remotely sensitive. Is there a middle ground somewhere? e.x. signed bundles of HTML/CSS/JS?
If you ever run into a VBScript on an old section of microsoft.com, it's likely to be signed. I think I've seen a Sharepoint Javascript file with a signature block on the end but I wonder if MS had more plans for this.
We agree this is a problem, all of those who try to access their private key during the compromise would be in trouble. Those who stayed offline would be safe.
BTW, this argument does not extend to the CLI or other uncompromised clients. People who sync their private keys across devices with the CLI are unaffected.
I'm confused. It sounds like users are able to sync their private keys with the CLI, or with the web interface. It also sounds like if they do it with the web interface, they are at risk, whereas with the CLI they are not at risk.
If my understanding is correct, my question is: What is the reason for this difference in security for the two use cases, and isn't there some way to provide web access without reducing security? What about browser add-ons? Client certificates?
As the article pointed out, what if your key (AES_k) is compromised? I mean what is the point of storing `AES_k(p,q) if k is random` unless you keep k somewhere?
What do you use that for?
I like the idea of a common way of proving one owns certain social identities. It is probably worth pointing out that the level of trust we give varies - Google "trusts" I own the domain when I put their random key on my homepage. Its not the kind of trust we would send (a lot of) money using, but its the level you guys seem to be aiming for - its a good level in a fair society.
Can I suggest that feature is a distraction from your core offering and a really big negative perception problem.
Almost everyone who will use this for the first x years will be technically savvy - for example having heard of PGP. And as such they will have seen a hundred "secure" sites that try and keep passwords and keys on the server - do not associate yourself with that level of security obfuscation.
Cut some code out of your codebase, keep your marketing message small and tight - and offering to also sync keys across devices is not a tight message.
So when you say "if k is 256 random bytes" it's a flat out lie?
e: if k really was 256 random bytes, or bits even, it would mostly be an unnecessary complication. But that's a completely opposite situation from a key derived from a user chosen password.
https://keybase.io/
"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.
On the website, all crypto is performed in JavaScript, in your browser. Some people have strong feelings about this, for good reason."
I had a similar issue with the verifying process. I opened an issue requesting better documentation on the signing command so that people can write their own clients: https://github.com/keybase/keybase-issues/issues/174
Yeah, thanks for making this issue. (Chris here, one of the two working on Keybase. I commented on that issue recently.) Getting proofs working totally outside our alpha client (and getting them well documented) is something we're working on this week. Keybase will not require running Node at all to interact with it.
There will be 2 ways to "prove" yourself as a programmer on Keybase:
1. running `keybase prove github` (or whatever service) which is interactive; the keybase client can generate the nice statement for you and pass it off to GPG for signing. This is already working.
2. running something in your shell which requires nothing but gpg and standard shell commands. The key elements here are that you need to generate a signed statement connecting your two accounts, and you need to post it on github. This is pretty simple and won't require Node at all.
Oh, and 3. using some other software of your choice that implements 2.
The reason #2 isn't documented yet is that it's a bit more complicated in certain cases. Consider what it takes to perform a twitter proof (click the "show the proof")
The signed statement itself isn't hosted on twitter (it won't fit) but needs to be boiled down into an agreeable tweet-sized hash. In order to prove twitter manually, you need to generate this statement, boil it down, make the tweet, and push the statement to Keybase.
All this will come, and our goal with Keybase isn't to require Node or npm for anyone.
yes, sorry if that wasn't clear. What I'm saying is that we'll have them documented very shortly. It's a priority for us, which I believe will address the OP's issue.
We'll have documentation on:
- what needs to be in the signed statement
- how to hash the statement for safety on the platform you're posting, if necessary (twitter: yes, github: no, DNS TXT: yes, web domains: no, etc.)
- how to tell Keybase about the statement (API call)
- how to post the statement on Keybase (API call; this is needed in the scenario where it's hashed, twitter style)
These will all be proof specific, which is necessary for reasons you can imagine. Character encodings allowed, where proofs go, what length they can be, etc., what goes into a proof (username?), etc., are all platform specific.
But the goal is that someone can do this with software of their choice.
Ok, well, keybase is less than a month old. You are refusing to use bleeding-edge software because it's not supported by your Linux distro. That means you're probably not the target user for what is described on the website as alpha software. Doesn't mean you won't be at some point when they've added functionality and extended the APIs, but for now you don't feel comfortable using it.
I think that's a fair stance to take on early-alpha software.
I can answer this for Keybase: first off, it's not because we can't learn other languages (someone suggested that below). In fact, we spent 10 years programming OkCupid in C++, and we've built some high performance projects in Go. It's hard to imagine someone could program anything even remotely like Keybase and lack the programming skills to do it in a variety of languages.
Anyway, in our case we (1) like the async programming model, and actively use it -- on the server side, our services tend to be modular and actually speak over RPC layers to each other, not just one big ugly web process. Node is great at this.
And (2) in this case, because we wanted to have a lot of shared code among our first implementation of a client, our browser front end, and our server. It worked very well to work on all three with one language. It's worked out.
I personally miss compiling C++. :-)
There's a very good chance we'll end up writing a Go client for Keybase. We might switch the official reference client once the functionality is more locked down.
Lastly: it's really CoffeeScript, not JavaScript. Which is a different can of worms to open on here.
The primary argument against node.js (and perhaps ruby) AFAIC is that many users will not already have it installed. Python/Perl/Bash you can count on all users having. C is a fine choice, but of course requires more packaging to be user friendly.
I've used zsh as my interactive shell for years, but I always still write bash scripts instead of zsh scripts. You can count on bash scripts running just about anywhere.
I was working with Capistrano almost a decade ago when it was called SwitchTower, so yeah -- it is kind of old school considering most "startup" developers are under 30.
npm is a fantastic package manager that integrates very well with github, and node -- in the opinion of a lot of people -- has a rather intuitive system for installing and loading third party modules.
EDIT: also wanted to add that node exposes your standard POSIX-style interfaces to the OS, so there's really no reason it can't be a general purpose replacement for other languages for writing system tools.
You just have to know that you're placing all your trust in keybase. If keybase says they have verified that `liz` is a certain facebook account, and you are acting based on that in encyrpting something to `liz`, you are trusting that:
* keybase acted honestly
* nobody compromised keybases software when it was doing the verification
* _after_ it did the verification, nobody managed to get keybase to switch out `liz`s key for some other key that wasn't really liz's (either because keybase was compromised, or keybase was untrustworthy... maybe because the government made them be?)
That last one is the kicker for me. If keybase catches on, surely they are going to get government orders to swap our one key for another key at some point.
The traditional web of trust does not require trusting any of those things, or at least not in those simple forms.
On the other hand, yes, there are reasons traditional PGP hasn't caught on, and usability is a big one. But, still, to compromise security for usability... if you go all the way there, you just wind up where we are now, not secure at all, right?
So, okay, is there value in going some of the way there, and getting some improved security but not as much as you could, for a more usable experience? Maybe. The danger is that people will think they are getting a lot more security than they are getting, and that situation can be worse than no security at all.
One thing Snowden taught us is that if you have to trust a third party to be honest... it's not that the people running keybase aren't honest, it's that the government will _compel_ them to be dishonest if it ever matters to them.
It's not correct that you need to trust Keybase. The way that someone verifies their social identity is by posting a tweet (or equivalent) signed with their private key. So you can look up someone's public key on Keybase and then verify that Keybase gave you the correct key, by checking the signature on their original tweet / other social verification posts.
Assuming you actually do this level of verification yourself (rather than allowing keybase to do it for you), the only thing you have to trust is that Keybase/Twitter/Github/Facebook/etc aren't all simultaneously colluding to give you a bad key. That seems to me like a reasonable assumption in pretty much all plausible circumstances.
Aha, good point! Hmm, have to think about that more.
It might be cool if there were an open source tool (from keybase or not) that would do this check for you. Most people in the target audience aren't going to be able to do it yourself.
That might be something cool for keybase to provide. (Yes, of course you'd still have to trust the open source tool, but that's why it's open source, etc.).
Before sending something particularly sensitive, you could run the tool to check that the public key you have still matches what was posted on their twitter, facebook, etc. (And yes, if someone can hack the old tweet on twitter, then of course, yeah).
Ah, you can re-verify the user at any point, not just the first time you add them as a contact or whatever? Neat.
Okay, this is good marketting for the product, because you are convincing me that at least it might have evaded some of these problems, and is worth further investigation. :)
To put it shortly: it's not Keybase that verifies that `liz` is a certain Facebook account. `liz` generates cryptographic proofs and publish them on Facebook, you get them and verify them. Keybase.io can't switch anything, unless also `liz`'s FB (and Twitter, and GH...) is compromised and the proofs switched.
This is a common and understandable misconception with Keybase threat-model, they should probably try even harder to put it up front.
What OP says is that she does not trust the way the tool to generate these proofs is distributed.
If you trust Twitter/Facebook/Github, you can verify assertions about account ownership by retrieving the signed message from those services and verifying they encode the correct data and that the signatures verify.
However, this does not protect against a malicious service provider from modifying the message to replace it with a different user.
Couldn't they create a challenge/response type authentication that proofs that liz has the private key for her public key?
Liz wants to authenticate. Keybase sends her a challenge, which she encrypts using her private key. Keybase uses her public key to verify that liz owns the private key for her public PGP key. Easy peasy.
Yeah, I know this is somehow the point. On the other hand it (maybe?) would be more useful if they would just verify that certain online-personas (e.g. github, pgp, blog) are the same person, which you could do.
I want to know that liz, is the liz that blogs and liz who forks on github, not necessary her facebook/linkedin/real name.
It seems that I can authenticate, get a few people to track me, than revoke my key and upload a new one.
I can also, obviously, recover my password via email.
And at the end of the process, people who were "tracking" me will still be tracking me. I am not sure this is supposed to happen.
As long as you don't follow the delete account track, this seems correct. People who track you can choose to be notified by Keybase.io of the change in your key (which is the default option). Additionally, if you can re-prove your identity against the same external identities this makes sense as a way to recover from a compromised key.
There was a keybase security vulnerability reported last week as well. I'm not sure if it is 100% relevant because it had nothing to do with js crypto, but it could have allowed someone to impersonate 'liz' as 'iiz'
ok, the distro has an outdated version of x software. This is a pretty common issue with older distributions. The great thing about debuntu is that you can pin packages to newer versions!
I don't even get as far as being able to verify myself. When I follow their instructions to upload my public key, I get "Whoa: Error: Unknown public key version: 3". Which doesn't really help me know what's actually wrong.
No thanks. Not going to install a slew of node packages all from untrusted sources so that i can "claim" my name in some PGP key DB. Key DB's are not the way to go. Name associations are worse. As someone illustrated by pumping snowden@<somedomain> or glengreenwald@<somedomain> keys into gpg servers. The adverse effect of this names system has a heavier weight than the positive.
If people want to improve usability they first should start with authentication. That is, authenticating keys. Second they should develop systems that permit for predictable imperfections in a manner that the user can understand.
Keybase seeks to solve the exact problem you just pointed out by connecting PGP keys to established online identities (Twitter, Github, etc.). You could create a Keybase account for Edward Snowden, sure, but his friends wouldn't trust it when they discover that the Twitter account they know to be his hasn't verified the key.
You say that people should start with authentication. That's exactly what keybase is trying to do. Realize that it's a hard problem. How would you implement it?
I acknowledge that there is positive to this reputation scheme. It lets Alice ratchet up-trust. But Bob has to be able to somehow confirm the attached accounts. Keybase assumes Bob will check this.
1. It assumes that Malory didn't copy paste all the content of Alice's bitbucket/alice account into an unclaimed github/alice.
2. It assumes a state actor cannot change the content on github, twitter, etc at the moment Bob attempts to validate the associates with Alice's keybase name.
3. Many Bob's will misplace their trust in the names on Keybase just as they do with GPG WoT (Web-of-Trust) systems because Bob doesn't really check the assumptions, caveats and things he should before trusting the key is Alice's.
This name/key anchoring will work for casual users of PGP who are not worried about malicious users clever enough to copy+paste enough content to attempt a Sybil attack. It works for people that are probably already in communication with each other for some time. But it should not be used for someone needing to retain anonymity, or anyone worried about state adversaries, or anyone worried about an "advanced persistent" adversary, or in the post-snowden world anyone wanting to communicate with a journalist.
It's point #3, how people actually use/abuse WoT's like this, that I feel outweighs the narrow positive scenarios. Keybase might be an improvement on absolutely horrific and broken existing WoT's such as http://pgp.mit.edu (I cannot believe this thing is still non-ssl only) and it explores imperfect security, which I am a big fan of. I just think WoT's in general have some other fundamental problems.
If I connect to a computer which uses some public key, and I verify that key with keybase.io. I could connect again and the public key could change but still be valid.
Ultimately you're trusting keybase.io not to mess with the verification process, correct?