Work misunderstanding

[CapSparkle]

Excuse me, but i don't understand how this library works. There is "Share" class. It is " A secret-shared value. ..." as you say, but i see only some wrapper over numbers i don't understand. I don't see process of number sharing or circuits building or something else to MPC related

You wrap integeres into secint, but how could it help to remain value of sorting integers in secret? If some entity will have gotten x array to perform oddeven_merge_sort() func on its comp it anyway will have can reconstruct true values of sorting numbers. So, i don't understand how that solution provide confidentiality to sorting numbers :c

And i dont understand multiparty case of work. As i see if i setup it there is no changing in algorithm work. But MPC implies a lot of different communications

Please, explain me what part of MPC issue your library solves. c:

[lschoe]

Yeah, good question. For the piece of code you're showing it's indeed the case that the values aren't secret at all. In fact, all MPyC code that we run in a notebook like this will be run in 1-party mode, hence without any secrecy at all! But even in 1-party mode, the computations are already done using all the built-in multiparty protocols. So, when running the above code in 3-party mode all values that are computed along the way will be secret shared.

Of course, to make things interesting we need to start with some private inputs. For this you use the MPyC runtime method mpc.input(). Maybe the demo unanimous.py is a good place to see how this can be done. Many of the other demos also use mpc.input(). Another way to start is to generate a random input jointly. See for example the demo onewayhashchains.py, where mpc.random.getrandbits() is used to generate random values without any party knowing those values. These values will only exist in secret-shared form.

I'm also attaching a notebook SecIntsExposed.ipynb that I've just written to explain you the basic issue. Best to use with the latest version MPyC v0.6.4+. Also the Python script version SecIntsExposed.py attached for convenience, see this zip file SecIntsExposed.zip.

[CapSparkle]

Thank you for your detailed answer! I will try to view and to comprehend all you sended in comming days.

[MarcT0K]

Hello, I would have a follow-up question regarding this issue: does using "real" secret-shared values (i.e., generated with mpc.input()) instead of "fake" secret-shared values (i.e., only wrapped integers) have any form of computational (and communicational) impact? Do MPyC process these values in the exact same way? In other words, if we had used mpc.input() in the sorting example given above, would the result of a benchmark be identical?

I see that computations on "fake" secret shares output secure objects with awaitable share. Hence, I have the feeling that everything happens as with "real" shares. I tried to read the asynchronous code but I am not sure to grasp all the details yet so I prefer to confirm this with you

[lschoe]

Yes, indeed, trivial sharings arising from the use of (i) a = secint(42) for example are handled exactly the same as nontrivial sharings arising from something like (ii) a = mpc.input(secint(42 if mpc.pid == 0 else None), senders=0). The polynomial for a trivial sharing (i) just happens to be of degree 0, that is, a horizontal line, whereas for (ii) the polynomial will be of degree $t$, where $t$ is the corruption threshold $0 \leq t < m/2$ for $m$ parties.

For (i), no communication takes place because each party is simply programmed to use the same value of 42 in this case as their share, which all lie on the horizontal line with vertical intercept of 42.

For (ii), party 0 will locally generate a random polynomial $a(X)$ of degree $t$ with constant coefficient 42, and send share $a_i = a(i+1)$ to party $i$ for $i=0,\ldots,m-1$ via the private point-to-point channels connecting party $0$ with the other parties (sending $a_0$ to itself).

The use of mpc.input() costs one round of communication. For the sorting example this will not influence the benchmark a lot because the actual sorting steps are much more involved. Similarly, we routinely use mpc.output() at the end of a test, which also costs one round of communication and we don't care really about the impact on the overall time.