Proxied Output Delivery

[gionut]

Multinode Communication Between Parties: Certificate Issues

Context

I have a SPDZ2k protocol with 2 parties (P0 and P1) and a client C. The parties want to share a private value with C, but they can't do it directly using the standard Output Delivery Protocol due to a constraint: P1 cannot communicate with C.

Workaround approach:

1. P1 sends its shares (signed and encrypted with C's public key) to P0
2. P0 forwards these shares together with its own shares to C
3. C decrypts and verifies the shares from P1, then computes the original secret value

To implement this, P0 and P1 use the Multinode Computation approach to open communication channels for forwarding encrypted shares.

Code Example

@if_(get_player_id()._v == 0)
def _():
    data = Array.create_from(sint(2))
    listen_for_clients(15000)
    print_ln("Server listening on port 15000")
    p1 = accept_client_connection(15000)
    data.get_vector(base=0, size=1).write_fully_to_socket(p1)
    data.assign_vector(sint.read_from_socket(p1))
    value = data[0].reveal()
    print_ln("Received value: %s", value)

@if_(get_player_id()._v == 1)
def _():
    data = sint.Array(1)
    print_ln("Client connecting to server on port 15000")
    p0 = init_client_connection('localhost', 15000, 1, relative_port=False)
    data.read_from_socket(p0)
    data[0] = data[0] ** 2
    data.write_to_socket(p0)

Questions

1. Understanding of Multinode Computation

Do I understand the Multinode Computation concept correctly? My understanding is that parties can offload secure computation to worker nodes. For example, if P0 and P1 have 1000 shares of secret values, each can offload 250 shares to 4 private worker nodes, then receive the results and reconstruct the original value.

In my example above, I'm expecting P1 to receive the share of data that belongs to P0.

2. Certificate/SSL Handshake Error

Since my worker node is both a client and a party, I set relative_port=False in the init_client_connection call. However, the program fails with SSL handshake errors:

Compilation output:

--- 1. Compiling proxy_delivery (Ring 64) ---
Default bit length for compilation: 63
Default security parameter for compilation: 40
Compiling file Programs/Source/proxy_delivery.py
Writing to Programs/Schedules/proxy_delivery.sch
Writing to Programs/Bytecode/proxy_delivery-0.bc
Hash: 8d4bed6add8570080d3235b1dfd7d80702517314edcdce20d12cdcfc647472d7
Program requires at most:
           1 integer opens
           1 integer triples
           1 integer simple multiplications
           2 virtual machine rounds
Compilation Successful.
Setting up the ceritficates
Setting up SSL for 2 parties
Generating a RSA private key
.+++++
...................+++++
writing new private key to 'Player-Data/P0.key'
-----
Generating a RSA private key
....................................................+++++
........+++++
writing new private key to 'Player-Data/P1.key'
-----
Doing Player-Data
link C0.pem -> 176c8f38.0
link C0.pem -> 2bbeb738.0
link C1.pem -> 9b9552db.0
link C1.pem -> 0b3cf1ac.0
link P0.pem -> 690ad341.0
link P0.pem -> 16036ff6.0
link P1.pem -> 0c19e31f.0
link P1.pem -> 98ab66c2.0
Setting up SSL for 2 parties
Generating a RSA private key
.......................+++++
.+++++
writing new private key to 'Player-Data/C0.key'
-----
Generating a RSA private key
.............+++++
...............+++++
writing new private key to 'Player-Data/C1.key'
-----
Doing Player-Data
--- 2. Running SPDZ2k (2 Parties) ---
[P0] Using SPDZ2k security parameter 64
[P0] Using statistical security parameter 40
[P1] Using SPDZ2k security parameter 64
[P1] Using statistical security parameter 40
[P0] Trying to run 64-bit computation
[P1] Trying to run 64-bit computation
[P0] Server listening on port 15000
[P1] Client connecting to server on port 15000
[P1] Client-side handshake with P1 failed. Make sure both sides  have the necessary certificate (Player-Data/C1.pem in the default configuration on their side and Player-Data/P1.pem on ours), and run `c_rehash <directory>` on its location.
[P0] Server-side handshake with C1 failed. Make sure both sides  have the necessary certificate (Player-Data/P0.pem in the default configuration on their side and Player-Data/C1.pem on ours), and run `c_rehash <directory>` on its location.
[P0] The certificates should be the same on every host. Also make sure that it's still valid. Certificates generated with `Scripts/setup-ssl.sh` expire after a month.
[P0] See also https://mp-spdz.readthedocs.io/en/latest/troubleshooting.html#handshake-failures
[P0] Signature (should match the other side): b67d9f74d756f34047af21ffa275e2a2/a457cb683c72573b6db0e2accc121cbd
[P0] SSL error: handshake: tlsv1 alert internal error (SSL routines, ssl3_read_bytes) [asio.ssl:336151608]
[P1] The certificates should be the same on every host. Also make sure that it's still valid. Certificates generated with `Scripts/setup-ssl.sh` expire after a month.
[P1] See also https://mp-spdz.readthedocs.io/en/latest/troubleshooting.html#handshake-failures
[P1] Signature (should match the other side): b67d9f74d756f34047af21ffa275e2a2/cd50e3583379424dac7a84339271cdcc
[P1] SSL error: handshake: certificate verify failed (SSL routines, tls_process_server_certificate) [asio.ssl:337047686]

Issues observed:

• The error messages indicate the system is trying to connect P1 with itself P1.

[P1] Client-side handshake with P1 failed. Make sure both sides  have the necessary certificate (Player-Data/C1.pem in the default configuration on their side and Player-Data/P1.pem on ours), and run `c_rehash <directory>` on its location.
[P0] Server-side handshake with C1 failed. Make sure both sides  have the necessary certificate (Player-Data/P0.pem in the default configuration on their side and Player-Data/C1.pem on ours), and run `c_rehash <directory>` on its location.

Questions:

• Is using Multinode Computation the correct approach for party-to-party communication in this scenario?
• How should certificates be configured when one party acts both as a client and a party to another party?
• Is there a better way to implement this forwarding pattern where P0 needs to receive data from P1 to forward to an external client?

Environment

• MP-SPDZ Version: 0.4.2 (Dec 24, 2025)
• Protocol: SPDZ2k
• Number of parties: 2

[mkskeller]

• Is using Multinode Computation the correct approach for party-to-party communication in this scenario?

No. P0 would learn all the data as it is not encrypted end-to-end but only per connection.

• How should certificates be configured when one party acts both as a client and a party to another party?

You might be able to fix the certificate failure by changing the id in the init_client_connection call and/or copying certificates, but this is moot given the point above.

• Is there a better way to implement this forwarding pattern where P0 needs to receive data from P1 to forward to an external client?

This seems to be a use case for VPN or port-forwarding. That way, the communication between C and P1 would be appropriately encrypted.

I would also note that the code example would fail because P0 will try to multiply and reveal a secret but P1 wouldn't. This violates the protocol, and it is the design reason for "hiding" _v in personal values such as the one returned by get_player_id().

[gionut]

Hi Marcel,

Thank you for your reply and the suggestions about VPN/port-forwarding.

I think I may have been unclear about my first question regarding the security model.

What we're trying to implement is a way to perform the output/input delivery protocol without direct communication between the client and P1. The approach would be:

For output delivery:

• P1 sends its shares to P0, signed and encrypted with C's public key (so P0 cannot decrypt or modify them)
• P0 bundles its own shares with P1's encrypted shares and forwards everything to C
• C decrypts P1's shares, verifies signatures, and reconstructs the secret

For input delivery:

• C sends masked input to P0, along with the input encrypted and signed for P1
• P0 forwards the encrypted input to P1
• P1 decrypts and verifies, then both parties proceed with the protocol

This is why I was exploring the Multinode Computation example. My specific question was: Can P1 perform cryptographic operations (encryption/signing) on its shares before sending them to P0, and then use init_client_connection with personal values (based on get_player_id()) to establish party-to-party communication for this forwarding pattern?

Regarding the VPN/port-forwarding approach: Would we need to use runtime conditions based on get_player_id() to instruct P1 and P0 to handle different connection appropriately? Or is there a recommended pattern for configuring parties to accept connections from both other parties and external clients simultaneously?

Thanks again for your guidance.

[mkskeller]

Can you specify what you mean by "direct communication"? When you say "signed and encrypted", this looks to me like establishing a secure channel, which can be facilitated by a tunnel between P1 and C via P0, just like any encrypted connection on the internet. If liveness is an issue, there would need to be another out-of-band solution, but my impression is that everyone would need to be live at the same time to facilitate the rest of the protocol.

My specific question was: Can P1 perform cryptographic operations (encryption/signing) on its shares before sending them to P0, and then use init_client_connection with personal values (based on get_player_id()) to establish party-to-party communication for this forwarding pattern?

No. The framework doesn't provide the cryptographic operations.

Regarding the VPN/port-forwarding approach: Would we need to use runtime conditions based on get_player_id() to instruct P1 and P0 to handle different connection appropriately? Or is there a recommended pattern for configuring parties to accept connections from both other parties and external clients simultaneously?

If you use VPN/port-forwarding, you wouldn't need to use player-specific operations. You can open a connection between C and P1 via the tunnel and proceed with the usual client interface.