<div dir="ltr"><div>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.<br>

</div>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.<br><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Various SMPC implementations, I don't know which ones that could useful for this purpose;<br>

<br></div><div class="gmail_extra">FairplayMP: <a href="http://www.cs.huji.ac.il/project/Fairplay/">http://www.cs.huji.ac.il/project/Fairplay/</a><br></div><div class="gmail_extra">Sepia: <a href="http://www.sepia.ee.ethz.ch/">http://www.sepia.ee.ethz.ch/</a><br>

</div><div class="gmail_extra">Viff: <a href="http://viff.dk/">http://viff.dk/</a><br></div><div class="gmail_extra">SIMAP and some more (nothing available for download?): <a href="http://ny.alexandra.dk/uk/labs/Security-lab/Pages/Secure-Multiparty-Computation.aspx">http://ny.alexandra.dk/uk/labs/Security-lab/Pages/Secure-Multiparty-Computation.aspx</a><br>

<br></div><div class="gmail_extra">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. <br>

<br></div><div class="gmail_extra">How it would have to work in general (if I got it right):<br>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).<br>

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).<br>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.<br>

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.<br>

</div><div class="gmail_extra">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).<br>

</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't *think* I've missed anything in there. If anybody spots any errors or knows how to improve the scheme, please share.<br></div><div class="gmail_extra">

<br><div class="gmail_quote">2013/1/17 Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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