Janus Dam Nielsen <janus.niel...@alexandra.dk> writes: > Hi Marcel, > > I am not opposed to your suggestion. However I would like to point out > that in VIFF you compute on shares and not field elements!
Well, we've actually made the outer runtime interfaces in such a way that add, mul, xor, etc... accept both integers, FieldElements and Shares. The methods then wrap their input as needed -- or they *dont* wrap it if that leads to a short cut (e.g., constant multiplication) > Computing directly on the field elements is hacking the abstractions > of VIFF. Computation on field elements or rather the representation of > a Share can be useful as an optimization, however this optimization > should be confined within applications or runtimes, and should not > progress over interface boundaries as I fear you are suggesting. I think we are in agreement: public methods on the runtimes will keep returning Shares. Methods used internally in runtimes can return other things as needed. To me it sounds like a better API to require preprocessing functions to return a list of Deferreds: [D(?), D(?), ...], instead of a Deferred list of tuples containing Deferreds :-) I think it will simplify the interface nicely, at least for consumers. Using simpler types also leads to less memory usage which has a positive effect on performance, as Marcel notes. So let's go for it. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty 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
