Jesper Buus Nielsen <[EMAIL PROTECTED]> writes: Hi Jesper,
>> 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.
>
>
> Just an input:
>
> Another solution to making the code look(1) more symmetric is to have
> a notion of local variables with an owner. Runtine, the variable will
> contain the identity of the owner P_i, and in client P_i the variable
> will also contain a value. At P_j != P_i it contains only the identity
> of P_i.
I am not sure I understand this... Are you thinking of a program along
the lines of this where each variable is a tuple that contains either
just a player ID or a player ID + a value:
a = (1, None)
b = (2, None)
c = (3, None)
if rt.id == 1:
a = (1, get_input_from_user())
if rt.id == 2:
b = (2, get_input_from_user())
if rt.id == 3:
c = (3, get_input_from_user())
When all three parties have executed this piece of code, they all have
three variables, but only one of the variables will be a (ID, value)
pair, the other two will be (ID, None) pairs.
> Below I write local variables in lover case and the already existing
> global variable on upper case. Ignoring the exact syntax of the
> variable declaration, code could then look as follows:
>
> a "belongs to* P_i
> b "belongs to* P_j
> c "belongs to* P_j
>
> [Read data into a, b, c]
>
> A, B, C, D, E = rt.shamir_share(a, b, c, a, 7)
>
> The last line simply secret shares the input values as usual. For a
> constant, like 7, use a dummy sharing. For a local variable like c,
> let the owner P_j play dealer of the value held by c at P_j.
What is the second "a" argument doing? Ahh wait, I think I get it! :-)
You let all the players specify the same input variables to the
comparison, but because exactly one out of the three players will have
an (ID, value) pair for each input we get the needed asymmetry.
So what currently looks like this
my_input = get_input_from_user()
A, B, C = rt.shamir_share([1, 2, 3], Zp, my_input)
if rt.id == 1:
D = rt.shamir_share([1], Zp, my_input)
E = 7
becomes
my_input = get_input_from_user()
if rt.id == 1:
a, b, c = (1, my_input), (2, None), (3, None)
if rt.id == 2:
a, b, c = (1, None), (2, my_input), (3, None)
if rt.id == 3:
a, b, c = (1, None), (2, None), (3, my_input)
A, B, C, D, E = rt.shamir_share(Zp, a, b, c, a, 7)
Interesting! It seems cleaner and more symmetric...
> Now at least sharing is symmetric. However, we just push the asymmetry
> to the reading of data into the local variables. That would, however,
> then at least be moved away from the sharing. So, if sharing is
> replaced by threshold encryption only one line must change, into e.g.
> A, B, C, D, E = rt.threshold_encrypt(a, b, c, a, 7)
I think that applies to the current code as well, or not?
> Another advantage of having local variables is that these later can be
> used to hold values to which the owner is committed. This can be
> convinient when implementing active security.
That sounds interesting too. With the current code I would imagine it
looking like this:
if rt.id == 1:
x = rt.commit([1], some_input)
else:
x = rt.commit([1])
or if we branch earlier:
if rt.id == 1:
some_input = get_input_from_user()
else:
some_input = None
x = rt.commit([1], some_input)
> (1) I say "look" as it was already agreed upon above that there *is* a
> real need to have different control paths in different clients. The
> discussion therefore becomes more an aestetic one, of how nicely we
> want this to be hidden in the code, and why? I assume that we do want
> to hide the asymmetry in the above discussion.
Yes, exactly! My initial solution was to bad asymmetri completely... a
bit radical :-) So it very interesting to see different solutions as to
how we can bring it back.
And now it the right time to do it -- we can still easily do search and
replace on the code since I assume that 99% of all VIFF code is in our
repository. (Someone, please prove me wrong! :-)
--
Martin Geisler
pgpH5JCS8uImf.pgp
Description: PGP signature
_______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
