Re: [viff-devel] New passive multiplication protocol

2008-10-08 Thread Martin Geisler
"Claudio Orlandi" <[EMAIL PROTECTED]> writes:

(I send your off-list reply back on track)

> Where is a description of the new protocol?

"Use the source, Luke!" :-)

It is just the normal passive multiplication protocol where I have cut
away all the work that is not needed: we only need 2t+1 shares to
recombine, so only 2t+1 players will even calculate and broadcast
shares. The others simply wait on the 2t+1 shares.

>> The good question is now how we can get the best of both worlds so
>> that the case with (n, t) = (3, 1) remains fast.
>
> What about "if n=3 then RunOldProtocol else RunNewProtocol"? :)

Wrong syntax:

  "if n=3: RunOldProtocol() else: RunNewProtocol()"

:-)

But apart from that then you're right -- maybe that is what we have to
do if we can find a nice way to do it.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk


Re: [viff-devel] New passive multiplication protocol (was: FW: Bug in ViFF)

2008-10-08 Thread Claudio Orlandi
Where is a description of the new protocol?

> The good question is now how we can get the best of both worlds so
> that the case with (n, t) = (3, 1) remains fast.

What about "if n=3 then RunOldProtocol else RunNewProtocol"? :)
-- 
Claudio Orlandi

PhD student,
Department of Computer Science, Turing-223
Aarhus Universitet, Denmark
http://www.daimi.au.dk/~orlandi
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk


[viff-devel] New passive multiplication protocol (was: FW: Bug in ViFF)

2008-10-08 Thread Martin Geisler
Martin Geisler <[EMAIL PROTECTED]> writes:

> Martin Geisler <[EMAIL PROTECTED]> writes:
>
>> That would be a good idea, also for performance. I suggest that we
>> use a round-robin system where we determine the perticipating
>> subset based on the current program counter.
>
> Code for this would look like this:
>
> +def select_subset(self, threshold):
>
> [...]

A full patch is here:

  http://article.gmane.org/gmane.comp.cryptography.viff.patches/49

Add /raw to the end of the URL if you want the raw email for importing
with 'hg import'.

(Let me know again if you guys would prefer such code posted here
instead. It is slightly stupid to split the traffic in two like this.)

I tested this briefly yesterday evening and more this morning:

  (n, t)  Old New
  (3, 1)  1.3 ms  2.1 ms
  (4, 1)  1.6 ms  1.9 ms
  (5, 1)  1.9 ms  1.8 ms
  (6, 1)  2.2 ms  1.7 ms
  (7, 1)  2.5 ms  1.6 ms
  (8, 1)  2.8 ms  1.6 ms
  (9, 1)  3.1 ms  1.7 ms

With n=3 and t=1 the code does extra work compared to the old code,
but when the number of players increase compared to the threshold,
then each player ends up doing less and less, and the average time per
comparison therefore drops!

The new code lets n - (2t+1) players avoid:

* waiting for the two shares
* a local multiplication
* Shamir sharing
* network traffic

The good question is now how we can get the best of both worlds so
that the case with (n, t) = (3, 1) remains fast.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk