Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.lizdenys.com

Post reply on HN
Print view View original

31–40 of 114 posts

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

#31

Post by malgorithms »

eik3_de wrote: post #7

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

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.

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

#32

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

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

#33

Post by lwf »

jrochkind1 wrote: post #32

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…

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.

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

#34

Post by [deleted] »

oijaf888 wrote: post #27
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…

The changes are all pretty well documented in their git repo.

[deleted]

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

#35

Post by davmre »

jrochkind1 wrote: post #32

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…

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.

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

#36

Post by 0x006A »

malgorithms wrote: post #26
shazow wrote: post #10

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…

Can you document the api calls neede for #2?

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

#37

Post by kylec »

tlrobinson wrote: post #28
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…

It looks like you can just do this to import a key into GPG: curl https://keybase.io/[them]/key.asc | gpg --import It won't show you the identity proofs though.

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

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

#38

Post by maxtaco »

rdl wrote: post #22
rsync wrote: post #3

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

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?

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

#39

Post by maxtaco »

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!

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

#40

Post by malgorithms »

0x006A wrote: post #36
malgorithms wrote: post #26

Earlier quoted context omitted.

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…

Can you document the api calls neede for #2?

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.

Post reply on HN