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

101–110 of 114 posts

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

#101

Post by [deleted] »

maxtaco wrote: post #38
rdl wrote: post #22

Earlier quoted context omitted.

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

[deleted]

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

#103

Post by mikegriff »

kstrauser wrote: post #97
malgorithms wrote: post #56

Earlier quoted context omitted.

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…

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

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

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

#104

Post by rlpb »

awalton wrote: post #95
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…

> platform-neutral tool that's been independently audited and managed by my OS's package manager Your OS's package manager is simply wrapping up whoever else's software in a nice pretty bow and releasing it. The only veracity it has is that the person who put the bow on it signed it. It's highly unlikely they did any kind of "independent auditing" or managing beyond writing some script to build the software. Or worse…

Part of what distribution-managed trust establishes is that it puts all distribution users (of that particular distribution) in the same boat. This is incredibly useful for verification purposes.

If I cared, I could even cross-verify across distributions by comparing their source tarballs.

> Or worse: if Debian is an example, they'll say "I don't understand this code, therefore it's not useful", comment it out, and ship horribly broken software to you.

The other point of view: they fix software so that it is useful, and I can easily have an integrated system. For the one problem you point out, there are hundreds (or probably even thousands) of useful integration patches that distribution users take advantage of every day, without even realizing it (and those suitable for upstream projects generally get pushed that way, too).

If you don't like distributions, then don't use them. And have fun with that.

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

#105

Post by rlpb »

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…

If you care about this, then use an agent (eg. gpg-agent). With this general mechanism, you can arrange your own system, including something out-of-band if you wish.

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

#106

Post by 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@ or glengreenwald@ 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.

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

#108

Post by maxtaco »

tveita wrote: post #94
maxtaco wrote: post #91

Earlier quoted context omitted.

Many Random Oracle crypto proofs assume a value is random and then substitute in something that's not quite so good, so I think it's a valid thought experiment. And some passwords do have 256 bits of randomness (i.e., ~15 random words from the dictionary). I think we disagree on what margin of password security we feel comfortable with.

Right, in random oracle proofs you assume that values are random, and then you replace them with something that no one can distinguish from random. Then you consider it broken when someone finds a distinguisher requiring three exabytes of output, because any distinguishable non-randomness breaks the proof. It's trivial to make a distinguisher for user passwords. Just guess "password". There's an inherent difference b…

We hope to roll out 2FA shortly. If enabled, you'll need to present a token before retrieving your encrypted private key from the server. Though of course it won't help if our server is hacked or subpoenaed.

We haven't tried cracking uploaded keys. It's a good idea, but expensive, we could be using those cycles to mine litecoins instead!

Thanks for your feedback, we appreciate it.

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

#109

Post by jcrawfordor »

cyphunk wrote: post #106

> '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@ or glengreenwald@ keys into gpg servers. The adverse effect of this names system has a heavier weight than the positive. If people want to improve usability…

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?

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

#110

Post by cyphunk »

jcrawfordor wrote: post #109
cyphunk wrote: post #106

> '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@ or glengreenwald@ keys into gpg servers. The adverse effect of this names system has a heavier weight than the positive. If people want to improve usability…

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

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

Post reply on HN