[guardian-dev] WOT and Authentication Research

[Hans-Christoph Steiner]

Sounds like an interesting idea, I would like to see an implementation of it,
especially if it can be done with gnupg.

.hc

On 01/17/2013 05:04 PM, Natanael wrote:
> Ok, so secure multiparty computing is officially my new favorite toy. So
> here is how I'd make the signatures anymous enough;
> 
> First of all, we can't have signatures that can be tied to you after the
> fact in any way if somebody gets a copy of them. So they can't be standard
> signatures from your main keypair. The easy fix is to untie the keypair you
> sign things with from your main keypair and yet prove to those close to you
> that those signatures comes from you.
> 
> So, for each set of signatures that you are ok with being linked (if friend
> A and B meets, are you sure you want them to know which signatures you've
> shared with them both? absolutely sure?), make a separate keypair and prove
> that this keypair is yours. Sign what you need with those keypairs. And the
> secure and authenticated method of transfer to your friends, which can't be
> tied to you afterwards?
> 
> Two-way challenge-and-response with your main keypair, and then the new
> keypair with the signatures is passed along with it, all done inside the
> SMPC virtual machine. The recipient knows it came from you but can not
> prove it later, and nobody else can either.
> 
> Paranoid enough? I don't mind the keys being spread on keyservers in this
> scheme, because each keypair won't (or at least shouldn't) be shared with
> more than just a few people. People can't say for sure the signature came
> from me.
> 2013/1/17 Hans-Christoph Steiner <hans at guardianproject.info>
> 
>>
>>
>> On 01/16/2013 09:04 PM, Patrick Baxter wrote:
>>> Hi Hans,
>>>
>>> Thanks for jumping in on this. Keeping this short:
>>>
>>>> I think its possible to use the WOT without publishing your social graph
>>>> publicly.  The keyservers can be used only for keys and revokation, then
>>>> people can exchange local signatures in a p2p fashion without ever
>> publishing
>>>> them to keyservers.  This is very hard to do right now, but it is
>> something
>>>> that can definitely be automated and with little user interaction
>> needed.  I
>>>> hope to work on this as part of PSST this year.
>>>
>>> I still think the benefits of publishing signatures outweighs the
>>> anonymity problems. Its a very debatable point though so I think a
>>> solution to this would be to allow the owner of the key to set a flag
>>> that would allow or disallow other people to publish signatures of
>>> their own key. People could only upload signatures for user's that
>>> have allowed it.
>>
>>> If publishing signatures was distributed, what would be the method to
>>> determine who you share you signatures with? Once you share, whats to
>>> stop it from being re-shared? With a keyserver keeping record, I would
>>> think its easier to respect privacy in the matter of publishing
>>> signatures.
>>
>> Whether its a worthwhile exchange to publish signatures publically depends
>> a
>> lot on what the repercussions are.  For me personally, it is clear that the
>> benefits outweigh the loss of privacy because it is quite unlikely that my
>> government or anyone else will torture or kill people in my web of trust.
>>  In
>> places like Syria right now, its a very different equation, so there needs
>> to
>> be some flexibiliy.
>>
>> I could see three "modes" related to this:
>>
>> * paranoid: always use lsign, only exchange signatures face to face, no
>> exchange of signatures other than my own
>> * peer-to-peer: never export signatures to the keyservers, exchange all
>> signatures I know about when I meet face-to-face
>> * keyserver: export everything to the keyservers
>>
>> Ideally, this mode would be tagged in the signature itself so when a
>> 'paranoid' exchanges signatures with a 'keyserver' all signatures involving
>> the 'paranoid' do not get uploaded to the keyserver, and so on and so
>> forth.
>> I suppose that if the peer-to-peer mode works well, then nobody should
>> really
>> use the keyserver.
>>
>>>> There is a lot there, I'm wondering if you've condensed what
>>>> you're particular questions are since then?
>>>
>>> I'm focusing more on the advantages of having a single (but
>>> decentralized) key-server that is a framework for providing a useful
>>> mapping for any domain. So a server that allows only a single mapping
>>> to exist for each UID of a domain. Allows signatures (with privacy),
>>> requires proofs of control to initially establish a name, and has a
>>> flexible way for dealing with failures (so it is accessible). I think
>>> some remaining questions would be how to look as this from the user's
>>> perspective (independently authenticated > independent WOT path >
>>> exists on server that I sort of trust and have a pinned https
>>> connection too) and how to establish account control among failures
>>> (losing keys, losing account access, dos signups).
>>
>> Why do you want to push verification to the keyserver?  I suppose it could
>> provide another channel of authenticity data for bootstrapping.  But it
>> seems
>> once you've verified the fingerprint and its connection to a UID, then you
>> don't need the keyserver to verify anything.  That keeps the keyserver
>> simple.
>>
>>>> As a kind of aside, I think that the Zooko's triangle analogy is not
>> very
>>>> good.  It does not map the problem very well because it portrays the
>> three
>>>> elements as equally affected by each other, when I think that's clearly
>> not
>>>> the case
>>>
>>> Good point. Also, I think by decentralized he might mean having
>>> namespaces with unique identifiers. I think that's achievable in a
>>> decentralized system. So, I wouldn't look into that analogy of the
>>> triangle much more myself :)
>>>
>>
>> UUIDs seem to work pretty well for being "universally unique" and totally
>> decentralized. :)
>>
>