Idiomatic method for delivering an individualized private output to each party

[csasmith]

Many of the functionalities I am implementing with the python interface require a different output to be delivered to each party. I am currently calling reveal_to() on each output to create a personal value, and then using the client interface to write back the value to each party. But the only way I have figured out how to make this work is to cast the underlying ._v value of the personal type to a cint, and then using cint.write_to_socket. My two concerns are:
(1) Is this even safe? By casting to a cint am I revealing the value for everyone to see?
(2) What is the idiomatic way of doing this?

For a minimal working example of what I have currently been doing:

import os, sys
# add MP-SPDZ/ to path so we can import from Compiler
sys.path.insert(0, os.path.dirname(sys.argv[0]) + '/../..') 
from Compiler.types import cint, sgf2n
from Compiler.library import listen_for_clients, accept_client_connection, if_
from Compiler.compilerLib import Compiler

usage = "usage: %prog [options] [args]"
compiler = Compiler(usage=usage)
compiler.parser.add_option("--num-parties", dest="n")

@compiler.register_function('foo')
def foo():
    n = int(compiler.options.n)
    # set up external client connections
    PORT_BASE = 15000
    listen_for_clients(PORT_BASE)
    socket = accept_client_connection(PORT_BASE)
    
    # each output is of type personal
    outputs = [sgf2n(i).reveal_to(i) for i in range(n)]
    
    # write personal outputs back to corresponding parties
    for party in range(n):
        @if_(party == socket)
        def _():
            cint.write_to_socket(socket, cint(outputs[party]._v))

if __name__ == "__main__":
    compiler.compile_func()

[mkskeller]

I haven't considered this use case before. One improvement I can think of is to use a Array for outputs (maybe you need to convert to cint to do this) so you can index them use run-time values.

[csasmith]

Ok thanks for the suggestion. Also, I am convinced the cast to cint before writing to socket is safe (ie does not reveal value to other parties). After digging through the generated asm (see below) and Processor/{instructions.h, Instruction.hpp, Instruction.cpp, Processor.hpp, Processor.h}, it looks like the cast results in a VM call to gconvgf2n, which turns the underlying gf2n value to an integer and stores it in the Processor's internal StackedVector<Integer> Ci, and then the VM makes a call to convint, which moves the value from Ci to the Processor's StackedVector<typename T::clear> C, and then the VM makes a call to writesocketc, which of course just writes the appropriate clear register value in C to the socket stream for the external client. Nowhere here did I see any communication with other parties (e.g., via call to exchange or otherwise).

I think in an ideal world the high level interface would give us something like personal.write_to_socket or maybe support binary_output() for sgf2n values. But I can definitely live with this for now.

ASM output of python3 Programs/Source/foo.py --asm-out foo --num-parties 2:

# foo-0--0
ldint ci2, 15000 # 0
listen ci2 # 1
ldint ci1, 15000 # 2
acceptclientconnection ci0, ci1 # 3
gldsi sg1, 0 # 4
ginputmask sg2, cg4, 0 # 5
gadds sg0, sg1, sg2 # 6
gldsi sg2, 1 # 7
ginputmask sg3, cg3, 1 # 8
gadds sg1, sg2, sg3 # 9
gasm_open 5, True, cg0, sg0, cg2, sg1 # 10
gsubc cg1, cg0, cg4 # 11
gsubc cg0, cg2, cg3 # 12
ldint ci2, 0 # 13
eqc ci1, ci0, ci2 # 14
jmpeqz ci1, 3 # 15
# foo-0-if-block-1
gconvgf2n ci1, cg1 # 16
convint c0, ci1 # 17
writesocketc 4, ci0, 0, 1, c0 # 18
# foo-0-end-if-2
ldint ci2, 1 # 19
eqc ci1, ci0, ci2 # 20
jmpeqz ci1, 3 # 21
# foo-0-if-block-3
gconvgf2n ci1, cg0 # 22
convint c0, ci1 # 23
writesocketc 4, ci0, 0, 1, c0 # 24
use_inp 1, 0, 1 # 25
use_inp 1, 1, 1 # 26
use 1, 7, 2 # 27
# foo-0-memory-usage-10
ldmc c0, 8191 # 28
gldmc cg0, 8191 # 29
ldmint ci0, 8191 # 30
ldms s0, 8191 # 31
gldms sg0, 8191 # 32
active True # 33

[mkskeller]

Indeed, there is no safety issue in accessing _v. As a general rule, the only way of revealing values is by calling reveal() explicitly.

As for the feature requests, I'd like to understand the use case a bit better. The infrastructure of reveal_to, personal, and party-specific binary_output has been built on the assumption that there is only one relevant party. The difficulty of your example comes from the fact that you start with n items, each of which is implicitly assigned to one party that is supposed to get the output. Is this correct? From the toolchain's point of view, this would imply fixing the number of parties at compile time, as there is generally no notion of a per-party thing in the VM design. However, one could construct some glue to make the transition from n items to one per-party item smoother while keeping in mind that the global complexity cannot be O(1) as the per-party output protocol has to be run for every party individually. I'm also wondering how you expect an extension binary_output to GF(2^n) to help, as the same restrictions apply there.