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.
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)<p>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.<p>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.)<p>Using keybase with gpg agent is maybe a bit safer. I don't <i>really</i> 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!).<p>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.
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":<p><pre><code> APT::Default-Release "precise";
</code></pre>
Then add a line to your /etc/apt/sources.list to include saucy (or trusty), which has the right version of node.<p><pre><code> deb http://archive.ubuntu.com/ubuntu saucy main restricted universe
deb-src http://archive.ubuntu.com/ubuntu saucy main restricted universe
</code></pre>
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.<p>Next, run these:<p><pre><code> sudo apt-get update
sudo apt-get build-dep -t saucy nodejs
sudo apt-get -b source -t saucy nodejs
</code></pre>
This puts the packages in the current directory. Now just install the one(s) you want:<p><pre><code> dpkg -i nodejs_0.10.15~dfsg1-4_amd64.deb
</code></pre>
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:<p><pre><code> Package: nodejs
Pin: release n=saucy
Pin-Priority: 1000
</code></pre>
Then "apt-get install nodejs" will get the right version and all dependencies, no need to build from source.
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 ?<p>Surely not...
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: <a href="https://github.com/keybase/keybase-issues/issues/174" rel="nofollow">https://github.com/keybase/keybase-issues/issues/174</a>
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.<p>I think that's a fair stance to take on early-alpha software.
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:<p>* keybase acted honestly<p>* nobody compromised keybases software when it was doing the verification<p>* _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?)<p>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.<p>The traditional web of trust does not require trusting any of those things, or at least not in those simple forms.<p>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?<p>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.<p>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.
So to verify a key I need to install npm?<p>No thanks.<p>" It doesn't seem particularly safe for me to trust my valuable PGP keys to this system."<p>I agree
Couldn't they create a challenge/response type authentication that proofs that liz has the private key for her public key?<p>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.
I just signed up on keybase.io.<p>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.<p>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.
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'<p>github report: <a href="https://github.com/keybase/keybase-issues/issues/397" rel="nofollow">https://github.com/keybase/keybase-issues/issues/397</a>
blog: <a href="http://ejj.io/keybase-io-vulnerability/" rel="nofollow">http://ejj.io/keybase-io-vulnerability/</a>
This talks much more to me, tho:
<a href="http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vindex" rel="nofollow">http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vinde...</a><p>And of course, I like that it's distributed and not a business. I don't want people to do business on my identity.
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!<p><a href="http://packages.ubuntu.com/saucy/nodejs" rel="nofollow">http://packages.ubuntu.com/saucy/nodejs</a>
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.
> 'Prerequisites: Node.js'<p>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.<p>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.
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.<p>Ultimately you're trusting keybase.io not to mess with the verification process, correct?