overflow handling error in sfix multiplication

[GuopengLin]

Hi, Keller, When performing sfix multiplication with large numbers, the overflow handling is inconsistent. For two very similar inputs that should both result in an overflow, one correctly produces NaN while the other produces a seemingly valid number, which is likely a result of arithmetic wrap-around.

For example, when performing sfix multiplication with inputs 1231234 and 1231234, the result is NaN. But with inputs 1231234 and 1231235, the result is 12166.

The issue can be observed with the following mpc code:

a = sfix.get_input_from(0)  
b = sfix.get_input_from(0)  
result = a * b
print_ln("Result: %s", result.reveal())

I run this mpc code with ring.sh.

[mkskeller]

I cannot reproduce this. What is the output if you add the following line?

print_ln("%s %s %s", a.v.reveal(), b.v.reveal(), result.v.reveal())

[GuopengLin]

When the input is 1231234 and 1231234, the output is

Result: NaN
80690151424 80690151424 1711538176

When the input is 1231234 and 1231235, the output is

Result: 12166
80690151424 80690216960 797310976

The following is my test code.

a = sfix.get_input_from(0)
b = sfix.get_input_from(0)
result = a * b
print_ln("Result: %s", result.reveal())
print_ln("%s %s %s", a.v.reveal(), b.v.reveal(), result.v.reveal())

[mkskeller]

I was using a different truncation protocol. I don't think this can be fixed efficiently as checking the range of the multiplication result would be much more expensive than the multiplication itself. The default truncation protocol in rings removes higher bits on purpose for efficiency reasons. The NaN output is only used when the revealed output is outside the range, but the protocols aren't guaranteed to produce results outside the range even when this would be the correct outcome.