otls
provides primitive building blocks for zkTLS or Web Proofs with the garble-then-prove method and QuickSilver. The current implementation includes the MPC Model
and Proxy Model
.
This is exactly the implementation of the garble-then-prove paper. More specifically, the client runs a 2PC (Garbled Circuit) protocol with the attestor in HandShake and AEAD encryption. In the Post Record phase, the client runs QuickSilver with the attestor to prove the integrity.
In the Proxy-TLS approach, the attestor acts as a proxy between the client and server, forwarding all TLS transcripts. The attestor can record both the Handshake transcripts and the ciphertexts exchanged between the client and server. At the end of the protocol, the client will prove to the attestor with QuickSilver about the validity of the ciphertexts.
In this case, the client proves the key in the AES encryption is derived (the KDF function) from the pms and the messages are encrypted with the same key under the ciphertext recorded by attestor.
- TLS 1.2
- Cipher suite: AES-GCM
otls
is dependent on primus-emp
.
git clone https://github.com/primus-labs/primus-emp.git
cd primus-emp
# Building
bash ./compile.sh
git clone https://github.com/primus-labs/otls.git
cd otls
# Building
bash ./compile.sh
All the test cases are located in the directory test
.
-
If you want to test the code in local machine, type
./run ./bin/[binaries] 12345 [more opts]
-
IF you want to test the code over two machine, type
./bin/[binaries] 1 12345 [more opts]
on one machine and./bin/[binaries] 2 12345 [more opts]
on the other.IP addresses are hardcoded in the test files.
-
An example should run as
./bin/example 1 12345 123 & ./bin/example 2 12345 124
because different parties need different numbers
This repository is provided as a free resource for the community. You are welcome to use, modify, and distribute the code in accordance with the repository's license. However, if you use this project in your own work, we ask that you acknowledge us by providing appropriate credit.
This README explains how to use ECDSA signatures to sign individual Pedersen commitments in the secure multi-party computation protocol.
Before using the ECDSA signing and verification functionality, you need to generate the necessary cryptographic keys. Follow these steps to create the required PEM files:
Generate an ECDSA private key using the secp256k1 curve:
openssl ecparam -name secp256k1 -genkey -out private_key.pem
This creates private_key.pem
containing your ECDSA private key.
Extract the corresponding public key from the private key:
openssl ec -in private_key.pem -pubout -out public_key.pem
This creates public_key.pem
containing your ECDSA public key.
You can inspect the contents of these files to confirm they're correct:
# View the private key details
openssl ec -in private_key.pem -text -noout
# View the public key details
openssl ec -in public_key.pem -pubin -text -noout
- Private Key (
private_key.pem
): Used by the signer to generate signatures. Keep this file secure and don't share it. - Public Key (
public_key.pem
): Used by the verifier to validate signatures. This file can be shared publicly.
The commitment signing process works as follows:
-
Signing Commitments:
- The signer loads the private key from
private_key.pem
- Each commitment point is individually hashed and signed
- All signatures are sent to the verifier
- The signer loads the private key from
-
Verifying Signatures:
- The verifier loads the public key from
public_key.pem
- Receives all signatures from the signer
- Verifies each signature against its corresponding commitment
- The verifier loads the public key from
// Sign all commitments individually
bool signed = conv.sign_commitments_with_ecdsa(com, chunk_len, "private_key.pem", pc);
if (signed) {
cout << "Created signatures: " << conv.get_signature_info() << endl;
}
// Verify all commitment signatures
bool verified = conv.verify_commitment_signature(com, chunk_len, "public_key.pem", pc);
if (verified) {
cout << "Verified signatures: " << conv.get_signature_info() << endl;
}
- Keep the private key (
private_key.pem
) secure and do not share it - In a production environment, use secure key storage solutions
- Consider implementing key rotation policies for long-term security
- Make sure file permissions are set appropriately (e.g.,
chmod 600 private_key.pem
)
If you encounter issues with signature verification, check:
- That both parties are using compatible key pairs
- The file paths to the key files are correct
- The commitments haven't been modified between signing and verification
- The file permissions allow the application to read the key files