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

Post by oijaf888 » Mon, Mar 31, 2014, 7:29 PM UTC

jrochkind1 wrote: post #47

davmre wrote: post #35

Earlier quoted context omitted.

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…

Post by maxtaco » Mon, Mar 31, 2014, 7:42 PM UTC

tveita wrote: post #69

maxtaco wrote: post #57

Earlier quoted context omitted.

k is derived from a password in this case, so capture of the password implies capture of k. We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.

So when you say "if k is 256 random bytes" it's a flat out lie? e: if k really was 256 random bytes, or bits even, it would mostly be an unnecessary complication. But that's a completely opposite situation from a key derived from a user chosen password.

Post by lifeisstillgood » Mon, Mar 31, 2014, 8:33 PM UTC

maxtaco wrote: post #57

lifeisstillgood wrote: post #44

Earlier quoted context omitted.

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

k is derived from a password in this case, so capture of the password implies capture of k. We give people the option to store their encrypted secret keys on our server to make it easier to manage their key and sync it across their devices.

Post by tveita » Mon, Mar 31, 2014, 8:36 PM UTC

maxtaco wrote: post #73

tveita wrote: post #69

Earlier quoted context omitted.

So when you say "if k is 256 random bytes" it's a flat out lie? e: if k really was 256 random bytes, or bits even, it would mostly be an unnecessary complication. But that's a completely opposite situation from a key derived from a user chosen password.

It was a thought experiment to encourage people to think about the issue at hand and not dismiss it with a knee-jerk. Your concern is now key stretching and password selection.

Post by vertex-four » Mon, Mar 31, 2014, 8:54 PM UTC

riffraff wrote: post #50

jnbiche wrote: post #43

Earlier quoted context omitted.

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.