Citat af Håvard Vegge <hava...@stud.ntnu.no>:
Thanks for clarifying!
Guess there are a lot of different variations of the definitions,
notions, etc. regarding secret sharing and MPC...
One of my problems is that when running the included sort.py
protocol with n=5 and t=2, the sorting of the array fails:
Original array: [{33}, {61}, {95}, {67}, {37}]
Sorted array: [{6692966529242218069}, {35128728804386641877},
{6621921405115695795}, {27880759555216652877}, {34356088148296101764}]
Made 9 comparisons
Works with n=5 and t=1 though...
That definitely looks like a bug to me. It has been about forever
since I looked at the VIFF code, but I think I'll try this out, see if
I can get the bug as well.
Mikkel Krøigård wrote:
Citat af Håvard Vegge <hava...@stud.ntnu.no>:
Hi!
I'm trying to do some basic benchmarks with different number of
players. A few questions:
1. Why have VIFF defined the threshold t to be the number of
corrupt players, while the classical literature defines it as "t
participants can reconstruct the message"?
Well, in what I have read, it is most often referred to as the
threshold for the number of tolerated corruptions, though yes I
have also seen it described as the number of shares needed to
reconstruct. I don't think there's anything wrong with the way we
do it, as long as it is clearly defined.
2. Say I create the config files this way:
python generate-config-files.py -n 5 -t 2 localhost:9001
localhost:9002 localhost:9003 localhost:9004 localhost:9005
Would this indicate that the polynomial is quadratic (of degree 2)
and that 3 players in theory could reconstruct some secret?
Yes.
3. Assume three of these five players provide input, while the
last two players do not. Will all players still participate in the
actual computation, or are the last two just passive spectators
and receives only the output?
-n 5 indicates that 5 servers will participate, regardless of how
many will provide input. Think of it from the perspective of
security. If the input was shared to 3 servers, we could not
tolerate 2 corruptions.
_______________________________________________
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
_______________________________________________
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk