Refusing to verify myself: I am liz on Keybase.io • Hacker News Board

Re: Refusing to verify myself: I am liz on Keybase.io

#51

Post by rdl » Mon, Mar 31, 2014, 6:42 PM UTC

maxtaco wrote: post #39

rdl wrote: post #21

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) tel…

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

Re: Refusing to verify myself: I am liz on Keybase.io

#52

Post by maxtaco » Mon, Mar 31, 2014, 6:43 PM UTC

davmre wrote: post #46

maxtaco wrote: post #38

Earlier quoted context omitted.

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 i…

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.

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.

Re: Refusing to verify myself: I am liz on Keybase.io

#53

Post by maxtaco » Mon, Mar 31, 2014, 6:44 PM UTC

rdl wrote: post #51

maxtaco wrote: post #39

Earlier quoted context omitted.

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 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…

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

Re: Refusing to verify myself: I am liz on Keybase.io

#54

Post by rdl » Mon, Mar 31, 2014, 6:45 PM UTC

davmre wrote: post #46

maxtaco wrote: post #38

Earlier quoted context omitted.

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 i…

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

Re: Refusing to verify myself: I am liz on Keybase.io

#55

Post by rdl » Mon, Mar 31, 2014, 6:47 PM UTC

maxtaco wrote: post #53

rdl wrote: post #51

Earlier quoted context omitted.

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…

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

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.

Re: Refusing to verify myself: I am liz on Keybase.io

#56

Post by malgorithms » Mon, Mar 31, 2014, 6:47 PM UTC

kylec wrote: post #23

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…

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.

Re: Refusing to verify myself: I am liz on Keybase.io

#57

Post by maxtaco » Mon, Mar 31, 2014, 6:49 PM UTC

lifeisstillgood wrote: post #44

maxtaco wrote: post #38

Earlier quoted context omitted.

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 i…

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. I…

k is derived from a password in this case, so capture of the password implies capture of k.

We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.

Re: Refusing to verify myself: I am liz on Keybase.io

#58

Post by jnbiche » Mon, Mar 31, 2014, 6:53 PM UTC

riffraff wrote: post #50

jnbiche wrote: post #43

Earlier quoted context omitted.

Have you checked out OneName? It runs on the Namecoin blockchain, so it's quite decentralized. I've not actually tried it yet, but it looks pretty damn cool. https://onename.io/

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.

No, you're wrong. It's entirely decentralized. Have a look at the spec: https://github.com/onenameio/onename

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?).

Re: Refusing to verify myself: I am liz on Keybase.io

#59

Post by maxtaco » Mon, Mar 31, 2014, 6:55 PM UTC

rdl wrote: post #54

davmre wrote: post #46

Earlier quoted context omitted.

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…

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.

Re: Refusing to verify myself: I am liz on Keybase.io

#60

Post by kylec » Mon, Mar 31, 2014, 6:58 PM UTC

malgorithms wrote: post #56

kylec wrote: post #23

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…

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…

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.