Secret Sharing Floating point numbers in IEEE-754 Format

Question

Various papers in the literature (such as https://eprint.iacr.org/2022/322.pdf, https://eprint.iacr.org/2013/850.pdf) use the sign, exponent, and significand values to additively secret share the original floating point secrets and later perform arithmetic operations on the shares of sign, exponent, and significand values to obtain the final output shares. However, they didn't provide details on how this secret sharing is actually performed. As I have newly started working on floating point MPC, I have some questions in this regard. It will be really helpful if any clarity can be given on this.

1. As per, IEEE-754 representation, the sign, exponent and significant bits are of sizes 1, 8 and 23 respectively. So, do I need to take three different ring sizes while secret sharing these values? Because if I take prime p = 2^23 or such higher values, then its possible that the exponent of some share may be more than 256 which is logically not possible.

2. Now if I took three different prime of 2^1, 2^8 and 2^23 for each of the parts. Then a different problem occurs. I provided the following example to illustrate the scenario.

Suppose I want to additively secret share a value of 10.123 into three parts using ring operations. 10.123 has sign, exponent, and significand values as 0, 130, and 2226127 respectively. One possible set of secret shared values can be {0, 131, 3202129}, {0, 129, 4807935}, {0, 126, 2604671} respectively. However, repacking and reconstruction using these values provide a completely different floating point value as repacking of {0, 131, 3202129}, {0, 129, 4807935}, {0, 126, 2604671} makes the floats 22.1076, 6.2926, 0.65525 respectively. This sums up to 29.05545 which is very much higher that 10.123.

How the secret sharing can be performed securely so this doesn't happen as the MPC computations using these shares provide wrong outputs during computation? The final output is coming based on the input 29.05545, not 10.123.

Thank you for the help in advanced.

Answer 1

Note that your first linked paper open-sourced their code here. The second paper doesn't have code that is nearly as easy to track down. It mentions using Sharemind and secrec. I can find the paper on Sharemind (which seems to be some sort of company?)'s website here. They also publicly-available git repos here, including some which may be relevant (libsoftfloat and libsoftfloat_math maybe?), but the documentation is not that good, so it is difficult to say anything concrete.

Sticking with the first paper, we can see they have their floating-point secret sharing library here. If you look at (for example here), you can see how they implement floats.

In general though

Because if I take prime p = 2^23 or such higher values, then its possible that the exponent of some share may be more than 256 which is logically not possible.

In other areas of secret-sharing, this is not an issue. Consider for example the setting where you want to secret-share some structured data (say a string, encoded in UTF8 or whatever). The easiest way to do this is to

1. serialize this to a bit-string of bounded length (say $k$ bits)
2. secret-share the $k$-bit bit-string

note that the shares of the $k$-bit bit-string will often be uniformly-random $k$-bit bit-strings. If one tries to interpret them as UTF8-encoded strings, it is likely this will fail. This does not hurt the initial application though.

Of course, when one wants to compute on the secret-shared data, things like this may end up being an issue. To figure out what they precisely do, we can read either the code or the paper. Here is a selection from your first linked paper

Bitwidth optimizations. The functionalities of primitive operations in SECFLOAT use operations over integers or fixed-point numbers that can be realized using 2PC frameworks such as ABY [29], SPDZ [44], etc. These frameworks use a uniform bitwidth, e.g., 64, for all values. This restriction of uniform bitwidth mandates use of larger than necessary bitwidths for many sub-computations that is wasteful for SECFLOAT’s functionalities and leads to unnecessary performance penalties. As an additional optimization, SECFLOAT’s functionalities use mixed-bitwidth computation and ensure that expensive high bitwidths are used only sparingly: the computations use as low bitwidths as possible, switch to high bitwidths via extensions when necessary, and then come back to low bitwidths via truncations.

This makes it sound like they do use secret-sharing over different rings. This is stated other times during the paper as well, e.g.

We use 2-out-of-2 additive secret sharing schemes over different rings [17], [68] between two parties P0 and P1

Looking further into their paper, we see Table 1, which describes several "primitive" operations they use to do their work. Several of them (say "unsigned mixed-bitwidth-multiplication") appear to be things that you are confused about. If this is the case, reading the source they cite for their operations (which is the SIRNN paper) may make some sense.

For your very specific question about computing floating-point operations on secret-shared data though, this is in the first paper you linked. Specifically, Section 5.C and 5.D describes their multiplication and addition protocols. To figure out precisely how they do what you ask, I would suggest reading those sections (or the paper overall), or perhaps looking at their code if you find that easier.