> Tomas is right, of course. For the passive case, using the first 2t+1 players
> always works, and for the active case, we do not use the
> local-multiply-and-reshare method anyway.
The thing is, I always just assumed that we always used the same set of shares,
and it is kind of easy to miss if yo
Hi,
Tomas is right, of course. For the passive case, using the first 2t+1 players
always works, and for the active case, we do not use the
local-multiply-and-reshare method anyway. The current implementation of active
security has
a preprocessing step based on either PRSS or hyper invertible matri
Martin Geisler <[EMAIL PROTECTED]> writes:
> That would be a good idea, also for performance. I suggest that we use
> a round-robin system where we determine the perticipating subset based
> on the current program counter.
Code for this would look like this:
diff --git a/viff/runtime.py b/viff/r
[EMAIL PROTECTED] writes:
> Hi all
>
>
> Today, Sebastiaan and I have been doing some serious thinking and
> looking into the VIFF code, and we feel convinced that we've found the
> bug.
Great work, thanks to both of you for solving the mystery! I guess this
bug is sufficiently grave that we shou
Hi all
Today, Sebastiaan and I have been doing some serious thinking and
looking into the VIFF code, and we feel convinced that we've found the
bug.
The problem lies entirely in the multiplication protocol. In
Runtime.mul, products of shares are computed and shared. Then secure
Lagrange inte
