# 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.