On 21/10/2009, at 20.28, Marcel Keller wrote:
Martin Geisler wrote:
Janus Dam Nielsen janus.niel...@alexandra.dk writes:
I am not opposed to your suggestion. However I would like to point
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)
I agree (see also my answer).
I would still like to stress that Shares are the basic values in VIFF.
The interface is then designed in such a way, so that we can do
various optimizations, but computing on field elements (a particular
representation of a share) is an optimization, which I am very happy
that the interface allows us to do. But it is still an optimization.
Computing directly on the field elements is hacking the abstractions
of VIFF. Computation on field elements or rather the
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
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
Using simpler types also leads to less memory usage which has a
effect on performance, as Marcel notes. So let's go for it.
So this makes 2 votes in favour of it and 1 against it. Maybe we
should have a meeting to discuss it. What do you think?
I can agree on this as well, as long as we don't make field elements
Janus Dam Nielsen
Research and Innovationspecialist, PhD.
CENTRE FOR IT-SECURITY
THE ALEXANDRA INSTITUTE LTD.
T +45 42 22 93 56
viff-devel mailing list (http://viff.dk/)