Hi Janus,

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!. Computing directly on the field elements is hacking the abstractions of VIFF.

I don't think so. Since I work with VIFF, it treats field elements as they would be shares with threshold 0. You can multiply and add field elements and shares. Furthermore, if you open to shares and multiply them, VIFF doesn't multiply locally, but executes the multiplication for shares of higher threshold. You have to do the following to achieve local multiplication:

a = open(share_a)
b = open(share_b)
c = gather_shares([a, b])
c.addCallback(lambda (a, b): a * b)

Therefore, I think that VIFF computes on field elements as well as on shares almost equally.

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 believe that if you would implement an OrlandiTuple class and overload operators there with the current _plus, _minus, and _const_mul functions, the OrlandiRuntime could reuse the add, sub, and lin_comb functions from PassiveRuntime and maybe even the mul function from BasicActiveRuntime. The OrlandiTuple would then be something equivalent to a FieldElement in the older runtimes.

Best regards,

viff-devel mailing list (http://viff.dk/)

Reply via email to