Martin Geisler <[EMAIL PROTECTED]> writes:
> What about making the argument to shamir_share optional? If all
> three players specify a value, then the code looks and behaves like
> it does today:
>
> a, b, c = rt.shamir_share(input)
>
> If P1 and P2 provide input, all three players would execute:
>
> if rt.id == 1:
> a, b = rt.shamir_share(input)
> elif rt.id == 2:
> a, b = rt.shamir_share(input)
> else:
> a, b = rt.shamir_share()
>
> Here all three players receive shares from two inputs, hence the
> return type becomes a two-tuple.
>
> If it is only P1 who provides input, this program is executed:
>
> if rt.id == 1:
> a = rt.shamir_share(input)
> else:
> a = rt.shamir_share()
>
> Here the return value is a simple Share.
>
> I think this is the natural generalization of what we have today...
> Does it looks usable?
Replying to myself... I don't think it would work without any extra
information. Each player needs to know what the other playes will do,
and that information is not captured by the above scheme.
I think we need to explicitly write the list of players who will
provide input for a given Shamir sharing. For example, if P1 and P2
are sharing their inputs, then they would execute
a, b = rt.shamir_share(input, [1, 2])
each with their own value for input and P3 would execute
a, b = rt.shamir_share(None, [1, 2])
The same applied when opening secret shared values. Here we could
write
if rt.id == 1:
open_a = rt.open(a, 1)
else:
rt.open(a, 1)
That would mean that P1 gets the value of a in open_a, but the other
players get no return value from the rt.open call.
--
Martin Geisler
_______________________________________________
viff-devel mailing list (http://viff.dk/)
[email protected]
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
