> For the complete documentation index, see [llms.txt](https://docs.cortensor.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortensor.network/technical-architecture/data-management/security-and-privacy/privacy-features-three-party-encryption.md).

# Privacy Features: Three-Party Encryption

Cortensor is introducing **privacy-preserving features** to enable secure, verifiable inference without exposing sensitive data. At the core is a **three-party encryption model**, allowing the **User, Miner, and Oracle** to establish a shared symmetric session key.

Goals:

* **Confidentiality** – inputs and outputs remain encrypted end-to-end.
* **Trustlessness** – no single party controls the key.
* **Integrity** – all parties contribute fairly to the key generation process.

Two candidate methods have been designed and prototyped:

* **Method 1:** Combined ECDH with Commitment Sharing
* **Method 2:** Coordinator-Based Key Distribution

The network has not yet finalized which approach will be adopted for **SessionV3**.

***

### Method 1: Combined ECDH with Commitment Sharing

#### Concept

All three parties generate a shared key derived from **pairwise ECDH operations**. To ensure that **all three secrets** (`ab`, `ac`, `bc`) are included, each participant shares a **commitment** to the secret that the others cannot compute.

#### Process

1. Each party computes the two pairwise secrets available to them.
2. Each party publishes a **commitment** to the missing secret so the others can combine it deterministically.
3. All parties hash and expand the combined values into a **symmetric session key**.

#### Benefits

* No single party controls the key.
* Symmetric key is never transmitted in plaintext.
* All three participants equally contribute.

#### Considerations

* Requires an **extra communication round** for commitments.
* More complex implementation compared to Method 2.

***

### Method 2: Coordinator-Based Key Distribution

#### Concept

One party acts as a **coordinator**, generates a random symmetric key, and securely distributes it to the others using ECDH-encrypted channels.

#### Process

1. A coordinator is chosen (User, Miner, or Oracle).
2. The coordinator generates a random symmetric key.
3. The coordinator encrypts and distributes the key to the other two parties over secure channels.
4. All three parties align on the same symmetric session key.

#### Benefits

* Simpler, fewer message rounds.
* Flexible — any party can act as coordinator.
* Well-suited when one party naturally initiates the session.

#### Considerations

* Coordinator temporarily controls key generation.
* Slightly weaker decentralization than Method 1.

***

### Current Status

* Both **Method 1** and **Method 2** are functional prototypes.
* No decision has yet been made on which will be adopted for **SessionV3**.
* Final integration will be handled through the planned **SessionKeystore** to manage public keys and session-level key negotiation.

***

### Next Steps

* Benchmark both methods for:
  * **Performance impact** in live sessions.
  * **Complexity of integration** with Router Node and SDK.
  * **Developer experience** (API usability).
* Select a default method for **SessionV3**, while preserving flexibility to support both.

***

⚠️ **Status:** Prototyped. Pending evaluation and selection for SessionV3.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.cortensor.network/technical-architecture/data-management/security-and-privacy/privacy-features-three-party-encryption.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.