
Refusing to verify myself: I am liz on Keybase.io - achernya
http://blog.lizdenys.com/2014/03/31/refusing-to-verify-myself/
======
kylec
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.

~~~
malgorithms
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.

~~~
kstrauser
So, am I (as #3000-something in the beta queue when I signed up for it) any
nearer to having an account I can start testing? :-)

~~~
mikegriff
Send me a mail, I have a couple of invites available.

------
rdl
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.

~~~
maxtaco
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!

~~~
rdl
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.

~~~
maxtaco
Agreed. We wish there was a practical solution to this problem, but at some
point, it's turtles all the way down.

~~~
rdl
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.

~~~
maxtaco
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.

------
sp332
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.

Next, run these:

    
    
      sudo apt-get update
      sudo apt-get build-dep -t saucy nodejs
      sudo apt-get -b source -t saucy nodejs
    

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:

    
    
      Package: nodejs
      Pin: release n=saucy
      Pin-Priority: 1000
    

Then "apt-get install nodejs" will get the right version and all dependencies,
no need to build from source.

------
rsync
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 ?

Surely not...

~~~
rdl
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.

~~~
maxtaco
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?

~~~
davmre
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.

~~~
rdl
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".

~~~
maxtaco
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.

~~~
rdl
Yeah -- from what malgorithms says, you're actually on the path to removing
dependency on a given binary being "near" my key material. I trust you guys
more than enough for now; I just don't want to have to trust you if this gets
wide adoption in 2 years once you become an actual target.

------
shazow
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](https://github.com/keybase/keybase-issues/issues/174)

~~~
malgorithms
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")

[https://keybase.io/chris/sigs/DZ9rccBD8u-Att6kQzhHHtw-924s7i...](https://keybase.io/chris/sigs/DZ9rccBD8u-Att6kQzhHHtw-924s7iNt05dB)

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.

~~~
0x006A
Can you document the api calls neede for #2?

~~~
malgorithms
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.

------
exelius
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.

------
eik3_de
Curious: Why do people choose JavaScript/node.js to write command line apps
over traditional languages for that task like python or ruby?

~~~
jonny_eh
Why do people choose python or ruby to write command line apps over
traditional languages like BASH, PERL, and C?

~~~
rsync
Exactly - I read:

"Why do people choose JavaScript/node.js to write command line apps over
traditional languages for that task like python or ruby?"

and was agreeing with the first part of the sentence and then laughed out loud
at the end ...

Are we really in a world where ruby is the old school traditionalist way to
write unix utilities ?

~~~
exelius
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.

------
jrochkind1
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.

~~~
davmre
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.

~~~
jrochkind1
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).

~~~
oijaf888
Isn't that exactly what the command line client does when you verify a user?

~~~
jrochkind1
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. :)

------
raverbashing
So to verify a key I need to install npm?

No thanks.

" It doesn't seem particularly safe for me to trust my valuable PGP keys to
this system."

I agree

------
phelmig
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.

~~~
dfox
Keybase seems to want identity proofs to be independently verifiable, which
would not work with challenge/response mechanism.

~~~
phelmig
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.

~~~
SomeoneWeird
This is exactly what Keybase does.

------
riffraff
I just signed up on keybase.io.

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.

~~~
mey
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.

------
theboss
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'

github report: [https://github.com/keybase/keybase-
issues/issues/397](https://github.com/keybase/keybase-issues/issues/397) blog:
[http://ejj.io/keybase-io-vulnerability/](http://ejj.io/keybase-io-
vulnerability/)

------
zobzu
This talks much more to me, tho:
[http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vinde...](http://gpg.mozilla.org/pks/lookup?search=0x4E8EA664&op=vindex)

And of course, I like that it's distributed and not a business. I don't want
people to do business on my identity.

------
kbar13
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!

[http://packages.ubuntu.com/saucy/nodejs](http://packages.ubuntu.com/saucy/nodejs)

------
mhandley
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.

------
cyphunk
> 'Prerequisites: Node.js'

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.

~~~
jcrawfordor
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?

~~~
cyphunk
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](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.

------
chris123
Bitcoin blockchain is looking to take market share for "trust" and
"verification" type things. The new web of trust.

------
maxtaco
Install-less, hosted-private-key-less Github, Twitter and Web site
verifications are now live on keybase.io. Enjoy!

------
rhoml
Yet another project that will end up at the bottom of the lake like all other
digital identity claiming sites.

------
dreamdu5t
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?

