Live data from Hacker News

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

blog.lizdenys.com

21–30 of 114 posts

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

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

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

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

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

#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 frequently with who-knows-what changes.

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

#24
post #8
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?

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

Because they don't know BASH or Perl and writing a Ruby/Python script is more often than not faster and easier than doing the equivalent in C?

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

#26
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` (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...

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.

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

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

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

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

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

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

I also like the idea of Keybase.io, though I wish it was based on something a little more decentralized. The unfortunately-named WebFist looks cool:

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-w...

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

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

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.
Post reply on HN