Tord Ingolf Reistad <to...@stud.ntnu.no> writes: Hi Tord,
Please use the list-reply function in your mail program (it might be
called "reply to all" or something like that). I'm sending this reply
back on the list.
> Thank you for the help, with the coding problem.
No problem!
> I am also trying to understand was the use of deferred objects.
> So I understand that a share is a deferred object, but can I also
> compute with field elements as deferred objects?
You should think of Share objects as deferred field elements. The Share
class is a subclass of Deferred, so every Share is a Deferred. Share
objects promise to call their callbacks with a field element as
argument.
So if we do this:
>>> from pprint import pprint
>>> from viff.runtime import Share
>>> from viff.field import GF
>>> Zp = GF(17)
>>> s = Share(None, Zp)
then s is a Share object which promisses to eventually contain a field
element from the Zp field. We can now add callbacks:
>>> s.addCallback(lambda x: x + 3)
<Share at 0xabc596c>
>>> s.addCallback(pprint)
<Share at 0xabc596c>
>>> s.callback(Zp(10))
{13}
The reason why we have this specialized Deferred class is that it
overloads the arithmetic operators. So
s + 3
will result in something very similar to
s.addCallback(lambda x: x + 3)
Here the x in the lambda expression is a field element, which itself
overload the aritmetic operators to do the right thing.
The end result is that we can use normal infix notation to do arithmetic
on (future) field elements in shares.
> I would also have liked to contain the callbacks in
> test = self.test_not_all_zero(r_as_bits, mask)
> such that the protocol was oblivious to if there was a callback in the
> code test_not_all_zero and I just got the boolean value back, but that
> is probably not possible?
Here's the code:
>> def protocol_part_1(self, r_as_bits, r, mask, x):
>> test = self.test_not_all_zero(r_as_bits, mask)
>> self.r = r
>> self.x = x
>> return test.addCallback(self.protocol_part_2)
>>
>> def protocol_part_2(self, test):
>> if test:
>> c = self.r + self.x
>> c_open = self.runtime.open(c)
>> result = gather_shares([c_open])
>> callback_result = result.addCallback(self.print_answer)
>> return callback_result
>> else:
>> print "No value, False"
>> return False
Since you really need to branch on the boolean result, you cannot avoid
adding an explicit callback. The reason is that you cannot wait on a
value in VIFF, you always have to tell VIFF what it should do when the
value arrives at some point in the future.
> My goal is to keep most of the code oblivious as to if it is computing
> with shares or field elements. This greatly simplifies the testing and
> readability of the code.
I see, that is indeed a nice property. And it can work some of the way,
as you've seen, but only for simple functions which only do arithmetic
on the shares.
> Tord
--
Martin Geisler
VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
pgpEF8LaONDNQ.pgp
Description: PGP signature
_______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
