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
Each party computes the two pairwise secrets available to them.
Each party publishes a commitment to the missing secret so the others can combine it deterministically.
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
A coordinator is chosen (User, Miner, or Oracle).
The coordinator generates a random symmetric key.
The coordinator encrypts and distributes the key to the other two parties over secure channels.
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.
Last updated