Re: [viff-devel] Asymmetric protocols
Tord Ingolf Reistad <[EMAIL PROTECTED]> writes: > I agree only sharing and opening will be asymmetric, and there are > many cases in which an opening will be asymmetric. To make it really > confusing there might be cases in which the opening might be > dependent upon some secret shared variable. > > E.g. lets say you are in a hospital and that the nurses (doctors and > administrators also) would have Pda's with location information. Now > the nurses do not want their location to be tracked, so there is no > central location server. > > [... cool scenario ...] > > In this example who the receiver of the message is, is not known > until we have determined who is the closest. Wouldn't you have to implement this by 1. Compute a secret sharing of the message m where each player holds a share. 2. Compute secret shared indicator variables b_i, one for each player. The variable b_i would be 1 iff player i should receive the message. 3. Compute m * b_1, m * b_2, ..., m * b_n. 3. For all i, open m * b_i asymmetrically so that only player i learns the value. I don't know if there is an easier way to do this, but I think the above would work. And it would only require that VIFF can open shares to a subset of the players. Or maybe I am missing something... this was just my initial though :-) -- Martin Geisler ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Asymmetric protocols
Martin Geisler wrote: > [EMAIL PROTECTED] writes: > > >> Are there really other problems than sharing (and opening a shared >> value towards only one party)? > > I don't think so. All other operations (addition, multiplication, > comparison, etc...) are done on variables which represent values in > the ideal functionality implemented by VIFF. So they are not tied to > any particular player and so I think we can limit these asymmetric > operations to sharing and opening. > I agree only sharing and opening will be asymmetric, and there are many cases in which an opening will be asymmetric. To make it really confusing there might be cases in which the opening might be dependent upon some secret shared variable. E.g. lets say you are in a hospital and that the nurses (doctors and administrators also) would have Pda's with location information. Now the nurses do not want their location to be tracked, so there is no central location server. Now one nurse puts out a request for help, and the algorithm has to find the closest nurse that is not busy to give the request to. The calculations to find the closest nurse is done using MPC, but then the call for request should be revealed only to the one fitting the description. The others should just get a dummy request (logged or discarded by the computer). In practice the nurse who's assistant was needed would hear a ring tone, and the pda would display that help was needed in room XXX. For all the other nurses (doctors and administrators), their pda would only log that an event where location information was needed was processed by the MPC module. They would not get any information about what kind of request it was, or anything else. In this example who the receiver of the message is, is not known until we have determined who is the closest. As a side note: I am working on a new comparison protocol, I have some problems with it so it might not work, but if it does then I need to compute both in some field Z_p and Z_q for different primes p and q. Can VIFF handle that or is it hard wired to only work in one field? ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
Re: [viff-devel] Asymmetric protocols
Tord Ingolf Reistad <[EMAIL PROTECTED]> writes:
(Please remember to send your replies to the list too.)
> [... use case about locating the nearest nurse securely...]
I found your use case very interesting, but probably also quite
difficult. But I really wanted to comment on the side note:
> As a side note:
> I am working on a new comparison protocol, I have some problems with
> it so it might not work, but if it does then I need to compute both
> in some field Z_p and Z_q for different primes p and q. Can VIFF
> handle that or is it hard wired to only work in one field?
Tomas needed VIFF to handle multiple fields, so this is indeed
possible! I'm glad to see that this feature is useful :-)
Try looking at the two-fields.py example, it shows how one can share
numbers over different fields and easily work with them. You basically
just have to avoid mixing Shares from different fields -- that will
give you an exception.
If you need to convert a GFElement from one field to another, then you
can do this by accessing the value field of a GFElement:
>>> from viff.field import GF
>>> Z17 = GF(17)
>>> Z23 = GF(23)
>>> x = Z17(15)
>>> y = Z23(x.value)
>>> x, y
({15}, {15})
If you have a Share (a Deferred GFElement) then you add a callback to
do the conversion:
x.addCallback(lambda e: Zp(e.value))
Here x is a Share and Zp is a field (created by a call to GF as
above). The lambda function is called when x gets a value (when the
value arrives over the network). The value is a GFElement, and we can
simply use e.value to refer to the Python integer stored in the
GFElement. Passing that to Zp will yield another GFElement, and the
total effect is that x becomes a Share holding a Zp GFEelemnt.
If we continue the example above we can do this to make a Share object
holding the x GFElement:
>>> from viff.runtime import Share
>>> x_share = Share(None, x)
I'm passing None since I don't have a Runtime around. That is okay for
this example. Now x_share is a Share which has a value, and in that
case we can access that using
>>> x_share.result
{15}
We can check the modulus too:
>>> x_share.result.modulus
17
(Accessing the result field like this is a big no-no in normal
programs since you cannot be sure that it is there since the Share
might not have a value yet. That is why you need to use callbacks to
schedule your peeking until the result is ready.)
Adding the callback has the result of converting the GFElement at once
(since the value is already there):
>>> x_share.addCallback(lambda e: Z23(e.value))
>>> x_share.result.modulus
23
I hope this makes sense, otherwise please ask again!
--
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
