TLShare

Prerequisites

• Docker and Docker Compose
• Git

Getting Started

Clone the repository and initialize submodules:

git clone --recurse-submodules git@github.com:NillionNetwork/tlshare.git
cd tlshare

If you already have the repository, update submodules with:

git submodule update --init --recursive

This guide explains how to build and test the TLShare repository using Docker, without needing to install dependencies directly on your host machine.

Curve Selection

OTLS supports two different elliptic curves for cryptographic operations in the com_conv example:

• Ed25519 (default): A widely-used curve optimized for performance and security
• BLS12-446: A pairing-friendly curve suitable for advanced cryptographic protocols

You can select the curve during the build process sing command line argument:

1. Using command line argument

docker compose build --build-arg RELIC_CURVE=BLS12-446

2. Using default (Ed25519):

docker compose build

The build output will indicate which curve is being used. If an unknown curve is specified, the build will fail.

Threads

We are using threads to simulate different machine executions. We will dedicate 4 threads for each party through the taskset command. Example using the 4 first threads:

taskset --cpu-list 0-3 <command>

Network configuration

Use the following command from the folder net-config inside the container:

• LAN (1 Gbps, RTT = 0 ms):

./net-config.sh on 0 1000

• To remove network modifications:

./net-config.sh off

• WAN (100 Mbps, RTT = 50 ms):

./net-config.sh on 50 100

[MPC mode] Running OTLS and PVSS with Docker

Getting Started

Docker initialization

1. Build the Docker image (Use the default case for MPC mode):

docker compose build

2. Run the Docker container in interactive mode:

docker compose up -d
docker compose exec otls bash

ECDSA keys generation

Please, follow the instructions in OTLS documentation on how to generate an ECDSA signature key pair.

Note: ensure that the files (private_key.pem and public_key.pem) are saved inside src/otls.

Running OTLS and PVSS

Use the required network configuration from above.

3. Once inside the container, you can run the otls com_conv test:

cd src/otls/
bash ./compile.sh /opt/primus-emp
# For local testing (both parties on same machine)
./run ./build/otls/bin/test_com_conv 12345

When running successfully, you should see:

• "ALICE check passed" from the verifier
• "BOB check passed" from the prover
• Timing and communication statistics for both parties

Note: The TLShare paper presents an optimized version of com_conv with only one signature. This is implemented in the test com_conv_opt. In this variant, the attestor (Alice) only produces one signature of all the commitments together. To run this test proceed as follows:

cd src/otls/
bash ./compile.sh /opt/primus-emp
# For local testing (both parties on same machine)
./run ./build/otls/bin/test_com_conv_opt 12345

Make sure the test is not commented in the CMakeLists.txt file. This variant is not compatible with the corresponding PVSS phase, as the current implemented version assumes we just want to share one value with the MPC nodes. This means that the current PVSS implementation only requires one commitment to be sent and the corresponding signature to be verified. Otherwise, the client would need to send all commitments to the MPC nodes to allow signature verification over all of the them.

4. You can run the pvss part as described in the PVSS documentation from src/pvss folder.

Running PVSS with different commands

We provide an example on how to run the (n=2; t=2) scenario. Use the network configuration from above accordingly.

n=2; t=2

1. Adapt the config file according to the parameters:

• n is the number of servers (uncomment the corresponding number of servers)
• t is the threshold

2. Start servers in different terminals:

taskset --cpu-list 4-7 cargo run --bin server 0  # Leader
taskset --cpu-list 8-11 cargo run --bin server 1

3. Run client(s):

taskset --cpu-list 0-3 cargo run --bin client

Binary File Formats

The commitment conversion protocol generates several binary files containing cryptographic data that is used in the pvss part of the protocol:

commitments.bin

This file contains elliptic curve points representing Pedersen commitments, stored in compressed format.

Structure:

• Each commitment is stored as a compressed elliptic curve point
• Point size: 33 bytes (for compressed format on the curve used)
• Format: Sequential concatenation of compressed points
• Total size: num_commitments * 33 bytes

Layout:

[Point 1 (33 bytes)][Point 2 (33 bytes)][Point 3 (33 bytes)]...

signatures.bin

This file contains ECDSA signatures for each commitment, stored in DER format.

Structure:

• Each signature entry consists of:
  • Length field: 4 bytes (little-endian integer)
  • Signature data: Variable length DER-encoded ECDSA signature
• Format: Sequential concatenation of [length, signature] pairs

Layout:

[Length 1 (4 bytes)][Signature 1 (variable)][Length 2 (4 bytes)][Signature 2 (variable)]...

h_value.bin

This file contains the secondary generator point h used in the Pedersen commitment scheme.

Structure:

• Single compressed elliptic curve point
• Point size: 33 bytes (for compressed format on the curve used)
• Format: Single compressed point
• Total size: 33 bytes

Layout:

[h Point (33 bytes)]

messages.bin

This file contains the message values extracted from the input chunks used in the Pedersen commitments.

Structure:

• Each message entry consists of:
  • Length field: 4 bytes (little-endian integer)
  • Message data: Variable length big-endian encoded BIGNUM
• Format: Sequential concatenation of [length, message] pairs
• Number of entries: Same as number of commitment chunks

Layout:

[Length 1 (4 bytes)][Message 1 (variable)][Length 2 (4 bytes)][Message 2 (variable)]...

randomness.bin

This file contains the randomness values (blinding factors) used in the Pedersen commitments.

Structure:

• Each randomness entry consists of:
  • Length field: 4 bytes (little-endian integer)
  • Randomness data: Variable length big-endian encoded BIGNUM
• Format: Sequential concatenation of [length, randomness] pairs
• Number of entries: Same as number of commitment chunks

Layout:

[Length 1 (4 bytes)][Randomness 1 (variable)][Length 2 (4 bytes)][Randomness 2 (variable)]...

[FHE mode] Running OTLS and TFHE-ZK with Docker

Getting Started

Docker initialization

1. Build the Docker image (Use the default case for MPC mode):

docker compose build --build-arg RELIC_CURVE=BLS12-446

2. Run the Docker container in interactive mode:

docker compose up -d
docker compose exec otls bash

ECDSA keys generation

Please, follow the instructions in OTLS documentation on how to generate an ECDSA signature key pair.

Note: ensure that the files (private_key.pem and public_key.pem) are saved inside src/otls.

Running OTLS

Use the required network configuration from above.

3. Once inside the container, you can run the otls com_conv test:

cd src/otls/
bash ./compile.sh /opt/primus-emp
# For local testing (both parties on same machine)
./run ./build/otls/bin/test_com_conv_g2 12345

When running successfully, you should see:

• "ALICE check passed" from the verifier
• "BOB check passed" from the prover
• Timing and communication statistics for both parties

Running TFHE-ZK approach

4. You can run the tfhe-zk part as described in the tfhe-ze documentation from src/tfhe-zk folder.

Running QuickSilver approach

5. You can run the quicksilver approach as described in the quicksilver documentation from src/quicksilver folder.