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.
Refusing to verify myself: I am liz on Keybase.io
81–90 of 114 posts
Re: Refusing to verify myself: I am liz on Keybase.io
#82Couldn'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.
Re: Refusing to verify myself: I am liz on Keybase.io
#83Couldn'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.
Keybase seems to want identity proofs to be independently verifiable, which would not work with challenge/response mechanism.
Re: Refusing to verify myself: I am liz on Keybase.io
#84Couldn'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.
Keybase seems to want identity proofs to be independently verifiable, which would not work with challenge/response mechanism.
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.
Re: Refusing to verify myself: I am liz on Keybase.io
#85Earlier quoted context omitted.
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.
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.
Re: Refusing to verify myself: I am liz on Keybase.io
#86Earlier quoted context omitted.
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…
Isn't that exactly what the command line client does when you verify a user?
Yes, it is, and it's 100% open source.
Re: Refusing to verify myself: I am liz on Keybase.io
#87Earlier quoted context omitted.
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.
I'm confused. It sounds like users are able to sync their private keys with the CLI, or with the web interface. It also sounds like if they do it with the web interface, they are at risk, whereas with the CLI they are not at risk. If my understanding is correct, my question is: What is the reason for this difference in security for the two use cases, and isn't there some way to provide web access without reducing sec…
A browser extension is in our (ever-expanding) todo list. We had one a few months ago, but we have to do a fair amount of work to get it back up to snuff.
Re: Refusing to verify myself: I am liz on Keybase.io
#88I 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.
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.
Re: Refusing to verify myself: I am liz on Keybase.io
#89Earlier quoted context omitted.
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…
Isn't that exactly what the command line client does when you verify a user?
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. :)
Re: Refusing to verify myself: I am liz on Keybase.io
#90Earlier quoted context omitted.
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.
Hopefully the pace of changes will slow down once we arrive on the correct core feature set and we sort out the bugs. An earnest thanks to HNers and others for being such great alpha testers BTW.