Closed thinh11 closed 4 years ago
Indeed, well spotted! The problem will disappear if you replace secfxp(None)
by secfxp(None, integral=True)
in the assignments for c
and d
. This way the parties that do not provide input still get the information that the fixed-point value happens to be a whole number. The secure protocols handling fixed-point numbers take advantage of this.
But this feature is not documented yet. Still working on what a good API is for such cases, and setting the integral
attribute directly is the current approach. Nicer approach is that the input party will tell the other parties about this, if the information that the value happens to be integral is not sensitive by itself.
A tip regarding "MPyC idiom." It's best to avoid multiple calls to mpc.input() in different branches of a conditional. So, the assignments to c
and d
, including the above correction, are better rendered like this:
c = mpc.input(secfxp(10 if mpc.pid==0 else None, integral=True), senders=0)
d = mpc.input(secfxp(200 if mpc.pid==1 else None, integral=True), senders=1)
mpc.mul
gets stuck onSecFxp
inputs for more than 2 parties.mpc.div
only works forSecFxp
inputs with 2 parties.SecInt
inputs will give wrong answers.SecFxp
inputs with more than 2 parties will result in errors.mpc.reciprocal
seems to only work correctly forSecFld
Example code: