[guardian-dev] WOT and Authentication Research

Hans-Christoph Steiner hans at guardianproject.info
Fri Jan 18 12:37:07 EST 2013

Sepia and VIFF sound the most interesting to me, in that they seem simpler and
are in languages we can use on a lot of platforms (Java and Python).
Personally, I'd work in python for anything experimental because it is just
such a more productive and playful language than Java.


On 01/18/2013 11:55 AM, Natanael wrote:
> All secure multiparty computation (SMPC) implementations I've seen so far
> has custom programming lanugages that need to be compiled directly for
> them. I think that for simplicity we need to implement some interpreter or
> bytecode VM for them to not have to port everything separately to them.
> Otherwise the porting efforts of the software to run in them can be a bit
> too much. Are there a simple JVM or something like that which we could
> port? Then we could reuse Java implementations of these things. Just
> remember that SMPC on it's own adds it's fair share of computational
> overhead, so it's quite important to make sure these things are optimized.
> If it wouldn't be reasonable to port some kind of bytecode VM or
> interpreter to them, then we need to port GPG and some more to them.
> Various SMPC implementations, I don't know which ones that could useful for
> this purpose;
> FairplayMP: http://www.cs.huji.ac.il/project/Fairplay/
> Sepia: http://www.sepia.ee.ethz.ch/
> Viff: http://viff.dk/
> SIMAP and some more (nothing available for download?):
> http://ny.alexandra.dk/uk/labs/Security-lab/Pages/Secure-Multiparty-Computation.aspx
> If anybody is willing to experiment with this and get it working, please
> help out. I don't have much experience in programming and I have none in
> applied crypto, just general knowledge about it.
> How it would have to work in general (if I got it right):
> First of all, you have a main keypair (your standard GPG key), and for each
> group of signatures (work intranet, your private stuff, hobbies, etc) you
> make a separate keypair that you sign that with. I guess most of you can
> figure out why this separation is useful, otherwise I can explain it in
> more detail (would require a few more paragraphs of text).
> In the software client you use to share your signatures, you pick your
> recipient and what to share (this can actually be generalized to share any
> kind of data).
> The SMPC virtual machine needs your private key to perform a challenge
> response, so both parties have to specify the other persons's public key
> and also use the keypair of their own that the other party specified. If
> the SMPC virtual machine is secure, your private key should remain secure.
> So the input from each party to the SMPC virtual machine is your main
> keypair + recipient's public key + your signatures to share + the public
> key of the keypair(s) you used to make them. The output is the signatures
> with their respective public keys from the other party that he/she shared
> with you.
> In the SMPC virtual machine, it first simply compares the key you specified
> for the recipient with the public key in the keypair that the recipient
> provided. Then it goes one and verifies the private keys by signing
> something with them and checking the signatures against the public keys.
> For example it could simply sign the data you're sharing (this won't leave
> the SMPC virtual machine, only the specified output above leaves it).
> I don't *think* I've missed anything in there. If anybody spots any errors
> or knows how to improve the scheme, please share.
> 2013/1/17 Hans-Christoph Steiner <hans at guardianproject.info>
>> 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. :)

More information about the Guardian-dev mailing list