Martin Geisler <mg <at> daimi.au.dk> writes: > > Martin Geisler <mg <at> daimi.au.dk> 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. >
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. 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. 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) 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. (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. /Jesper _______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
