Don't worry liz -- you'll always be a whiny little twat to me on Keybase.io.
Refusing to verify myself: I am liz on Keybase.io
41–50 of 114 posts
Re: Refusing to verify myself: I am liz on Keybase.io
#42You can build a newer version from an official Ubuntu source package. Start by adding a line to a file in /etc/apt/apt.conf.d/ that pins all your packages to 12.04, "precise":
APT::Default-Release "precise";
deb http://archive.ubuntu.com/ubuntu saucy main restricted universe
deb-src http://archive.ubuntu.com/ubuntu saucy main restricted universe
Next, run these:
sudo apt-get update
sudo apt-get build-dep -t saucy nodejs
sudo apt-get -b source -t saucy nodejs
dpkg -i nodejs_0.10.15~dfsg1-4_amd64.deb
Package: nodejs
Pin: release n=saucy
Pin-Priority: 1000
Re: Refusing to verify myself: I am liz on Keybase.io
#43I 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...
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.
Re: Refusing to verify myself: I am liz on Keybase.io
#44Earlier 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…
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. Its not the kind of trust we would send (a lot of) money using, but its the level you guys seem to be aiming for - its a good level in a fair society.
Re: Refusing to verify myself: I am liz on Keybase.io
#45There was a keybase security vulnerability reported last week as well. I'm not sure if it is 100% relevant because it had nothing to do with js crypto, but it could have allowed someone to impersonate 'liz' as 'iiz'
github report: https://github.com/keybase/keybase-issues/issues/397 blog: http://ejj.io/keybase-io-vulnerability/
Re: Refusing to verify myself: I am liz on Keybase.io
#46Earlier 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…
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.
Re: Refusing to verify myself: I am liz on Keybase.io
#47You 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 yoursel…
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 particularly sensitive, you could run the tool to check that the public key you have still matches what was posted on their twitter, facebook, etc. (And yes, if someone can hack the old tweet on twitter, then of course, yeah).
Re: Refusing to verify myself: I am liz on Keybase.io
#48You 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…
The system does not work like this.
To put it shortly: it's not Keybase that verifies that `liz` is a certain Facebook account. `liz` generates cryptographic proofs and publish them on Facebook, you get them and verify them. Keybase.io can't switch anything, unless also `liz`'s FB (and Twitter, and GH...) is compromised and the proofs switched.
This is a common and understandable misconception with Keybase threat-model, they should probably try even harder to put it up front.
What OP says is that she does not trust the way the tool to generate these proofs is distributed.
Re: Refusing to verify myself: I am liz on Keybase.io
#49I 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.
Re: Refusing to verify myself: I am liz on Keybase.io
#50Earlier quoted context omitted.
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...
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.