Evolving zkTLS: Part 2 of Privacy-Preserving Computation from Decentralized Oracles

PUBLISHED

04.11.2025

AUTHOR

Dimitris Mouris, Manuel Santos, and Miguel de Vega

CATEGORY

Project Update

Part 2: Nillion’s Private-to-Private Oracles

 

This is Part 2 of our zkTLS blog post series; check out the first one here if you have not read it yet. Our previous blog post explored a gap in decentralized oracle technologies; there is no Private-to-Private decentralized oracle solution. Public-to-Public oracles import publicly available data such as stock prices, weather forecasts, etc., into smart contracts, while Private-to-Public allow a statement about private data to be used on-chain while maintaining privacy. See our categorization below:

For a more in-depth discussion, check out our previous blog post.

In this blog post, we will dive into three new solutions for Private-to-Private decentralized oracles. First things first, though! Most existing protocols can be viewed in two broad categories: MPC-based and Proxy-based. The former types of protocols (i.e., the MPC model) run the TLS handshake under MPC and do not need to trust any single external party. This means that the TLS client and an attestor/verifier collaborate to execute an MPC protocol and generate any materials needed for the TLS session with the server. In the latter (i.e., Proxy) model, the attestor acts as a proxy between the server and the client and signs the encrypted TLS messages between them.

While the MPC model offers a more elaborate solution that minimizes trust, the Proxy model offers significantly smoother experience and performance. Different Proxy implementations have different trade-offs, but we won’t get into it in this blog post as it is orthogonal to our goal, and our Private-to-Private oracle can work with any existing zkTLS model. We refer the reader to this thorough blog post about existing protocols.

Proxy-based protocols face an important challenge as the proxy does not know the key that encrypts the client-server traffic, and although it signs the data, if a different key is provided, there is a possibility that the ciphertext can decrypt to something different than the original message. This is referred to as the key commitment issue. Proxy-based protocols have different ways of defending against the key commitment issue, such as proving that a specific key was derived faithfully during the TLS protocol ^{\text{2}} or even inspecting that the TLS response header is well-formed ^{\text{3}} ^{\text{4}}, etc.

Nillion’s Private-to-Private Oracles

Our goal is to move beyond zkTLS static proofs (e.g., proofs of account ownership, proofs of humanity ^{\text{5}}, proofs of making purchases on websites, etc.) and instead extract sensitive data from TLS connections and import it to Web3 servers that are backed either by MPC or FHE. Concretely, our approach transforms TLS data into secret shares compatible with MPC or into ciphertexts suitable for FHE. We introduce three solutions, each leveraging a different secure computation technique: TEE, MPC, and FHE.

All three solutions have a similar setup: a Client establishes a TLS connection with a TLS Server (e.g., a bank) through a Proxy, while one or more blind computation servers (i.e., FHE Server or MPC Servers) receive data extracted from the session, backed by a cryptographic guarantee of origin. Specifically, the Client and TLS Server exchange encrypted messages using AES-GCM and the Proxy signs the encrypted TLS traffic with Elliptic Curve Digital Signature Algorithm (ECDSA). The Proxy plays a critical role in guaranteeing data provenance.

Let’s now examine each of the three solutions in more detail.

1. TEE-based Private-to-Private Oracle

The first solution uses a trusted execution environment (TEE) to extract the data from the TLS-encrypted messages and either secret share it to MPC Servers or encrypt it towards an FHE Server. The flow is as follows: after the Client receives the AES-encrypted response from the TLS Server (that is also signed by the Proxy), the Client forwards the signed encrypted response to the TEE and the AES key over a secure channel. The TEE is responsible for verifying the provenance of the data and correctly blinding it before sending it to the secure computation servers. To ensure provenance, the TEE performs two key checks:

  1. Signature verification: It verifies the Proxy’s signature on the encrypted data using the Proxy’s public key. This guarantees that the ciphertext originates from the valid TLS Server.
  2. TLS header validation: It ensures the header of the TLS record is well-formed. This step is crucial to defend against attacks that exploit the non-committing nature of AES keys.

To correctly blind the data, the TEE first decrypts the TLS ciphertexts and extracts the relevant fields before secret-sharing or encrypting them. This solution comes with certain trust assumptions; more specifically, the blind computation server(s) trust the TEE that has verified the provenance of the TLS records, has properly verified the signature of the Proxy, and blinded the correct data. Both the TEE-to-MPC and TEE-to-FHE variants follow this common flow; we explore them in more detail below.

1.1. TEE to MPC: The TEE-to-MPC variant is shown in the figure below and consists of a TEE and multiple MPC servers. After the TEE decrypts the AES-encrypted data, it uses secret sharing to securely share the sensitive data to the MPC servers. The MPC servers can now use the secret shares to perform any private computation.

1.2. TEE to FHE: The TEE-to-FHE variant is shown in the figure below and consists of a TEE and an FHE Server. After the TEE decrypts the AES-encrypted data, it encrypts the sensitive data using fully homomorphic encryption (e.g., any scheme such as TFHE, CKKS, BGV, BFV can work here), and sends the FHE-encrypted data to the server. The FHE server can now use the encrypted data to perform any private computation.

 

2. MPC-based Private-to-Private Oracle

The second solution does not use a TEE as the medium to verify the authenticity of the ciphertext and generate the corresponding blind material. Instead, the Client works together with the MPC Servers to guarantee the provenance and correctness of the blind data. To achieve this, the Client starts by secret sharing the AES key and then sends the TLS traffic to the MPC Servers alongside the signature from the Proxy. Then, the MPC Servers jointly perform the AES decryption of the TLS traffic under MPC using the shares of the AES key. As a result, each MPC server only ends up with shares of the sensitive data. Finally, each MPC Server performs two crucial checks:

  1. Signature verification: Each MPC Server locally verifies the Proxy’s signature, guaranteeing that the TLS ciphertexts originate from the valid TLS Server.
  2. TLS header validation: The MPC Servers reconstruct the first few blocks and assert that the header of the TLS is well-formed. Similarly to the TEE-based solution, this prevents the exploitation of the non-committing property of AES keys.

3. FHE-based Private-to-Private Oracle

The third solution is similar to the MPC-based approach but relies on FHE with a single server instead of multiple MPC Servers. Also, it does not use a TEE for decrypting and re-encrypting data to the FHE server. Instead, the Client encrypts the AES key using the FHE public key and sends it to the FHE Server. Alongside, the Client sends the AES-encrypted TLS traffic, the Proxy’s signature, and the plaintext header corresponding to the AES ciphertext. The FHE Server then homomorphically decrypts the AES ciphertext using the FHE-encrypted AES key, resulting in an FHE-encrypted TLS message. With this information, the FHE Server performs the usual security checks:

  1. Signature verification: The FHE Server locally verifies the Proxy’s signature, ensuring that the TLS ciphertexts originates from a legitimate TLS Server.
  2. TLS header validation: The FHE Server first checks that the plaintext header sent by the Client is well-formed. It then homomorphically compares the relevant blocks of the FHE-encrypted TLS message with the plaintext header. This process prevents the exploitation of the non-committing property of AES keys.

In the above scenario, the private key is owned by the Client, which restricts the ability to combine data from multiple clients. By adopting a multiparty FHE architecture ^{\text{6}} ^{\text{7}}, this limitation can be overcome. In this setup, the decryption process then requires collaboration among multiple decryptor servers, each holding a share of the decryption key. This architecture is similar to the single FHE Server model but eliminates the need for homomorphic comparison during the TLS header validation security check. Additionally, the Client no longer needs to send the header in plaintext, and the FHE Servers are not required to homomorphically compare the plaintext header with the FHE-encrypted TLS message. Instead, the FHE Servers collaboratively decrypt the relevant header and perform the validation in plaintext.

TLS is the protocol that enables secure data exchange between clients and servers by allowing the client to verify the authenticity of the data received from the server. However, a client cannot use the data received from a TLS connection to provide any type of guarantee to third parties. The integration of Web2 data into Web3 ecosystems has long been a challenge due to data provenance, privacy concerns, and security constraints. Providing data provenance in Web3 allows consuming Web2 data in a verifiable way, i.e., we know where data originated from and that they are authentic and have not been tampered with. Historically, decentralized applications (dApps) have relied on traditional oracles to access off-chain information. However, these solutions have primarily catered to public data, leaving private data underutilized and often inaccessible due to security risks.

What’s Next for Nillion’s Private-to-Private Oracles

At Nillion, we are working on integrating these proxy-based solutions with various zkTLS technologies to advance the development of Private-to-Private Oracles. This initiative aims to create a secure and decentralized framework for private data use. In the next Part of this blog post series, we will present a demo in collaboration with a leading industry partner, showcasing how centralized private information can be securely exported into shares within a decentralized system. Stay tuned for more updates as we continue to push forward and explore this space.

References

  1. Wetzel, Bastian. “TLS Oracles (zkTLS): Liberating Private Web Data with Cryptography” Medium, 16 Apr 2024, https://bwetzel.medium.com/tls-oracles-liberating-private-web-data-with-cryptography-e66e5fad7c34
  2. “zkTLS Overview” Primus, 2025, https://docs.primuslabs.xyz/data-verification/tech-intro/
  3. Malolan, Madhavan. “Proxying Is Enough” Reclaim Protocol, 29 May 2024, https://blog.reclaimprotocol.org/posts/proxying-is-enough
  4. Zhongtang et al. “Proxying is Enough: Security of Proxying in TLS Oracles and AEAD Context Unforgeability” eprint, 2024, https://eprint.iacr.org/2024/733.pdf
  5. zkPass. “zkTLS — The Cornerstone of Verifiable Internet” Medium, 17 Dec 2024, https://medium.com/zkpass/zktls-the-cornerstone-of-verifiable-internet-da8609a32754
  6. Chatel et al. “PELTA – Shielding Multiparty-FHE against Malicious Adversaries” eprint, 2023, https://eprint.iacr.org/2023/642.pdf
  7. Dahl et al. “Noah’s Ark: Efficient Threshold-FHE Using Noise Flooding” eprint, 2023, https://eprint.iacr.org/2023/815.pdf

 

Image

Follow @BuildOnNillion on X/Twitter for more updates like these