# End-to-End Encryption (E2EE)

Payload Encryption

OpenShard applies AES encryption to the inference request payload before it leaves the buyer process. The raw inference input — including the prompt, message history, model parameters, and any other request fields — is encrypted at the buyer and transmitted as an opaque ciphertext in the encryptedQuery field. The seller decrypts this payload only after completing the ZK proof verification step and resolving the session key through ECDH.

This design ensures that inference content remains confidential in transit regardless of what network infrastructure handles the request. A passive observer watching encrypted traffic, a misconfigured reverse proxy logging request bodies, or a tunnel provider with full packet visibility would see only ciphertext. The AES helper logic for payload encryption and decryption is provided by the crypto package and is applied uniformly to all privacy-enabled requests.

ECDH Session Key Exchange

The AES session key itself is protected through Elliptic Curve Diffie-Hellman key agreement. For each privacy-enabled session, the buyer generates a fresh ephemeral keypair. It derives a shared secret by combining its ephemeral private key with the seller's long-term static public key. It uses this shared secret to encrypt the AES session key, and includes both the encrypted session key and its own ephemeral public key in the request payload.

The seller, holding its own static private key, performs the same ECDH derivation using the buyer's provided ephemeral public key to recover the identical shared secret. It uses this to decrypt the session key, and then uses the session key to decrypt the inference payload.

This mechanism achieves forward secrecy at the session granularity. Even if a seller's static private key were compromised at some future point, past inference sessions encrypted under ephemeral buyer keypairs cannot be retroactively decrypted without also recovering the specific ephemeral private key used in that session. Because ephemeral buyer keypairs are generated fresh per session and discarded afterward, historical session content remains protected.

Encrypted Payload Structure

A fully privacy-enabled inference request from buyer to seller carries five distinct fields in its privacy layer. The encryptedQuery field carries the AES-encrypted inference payload. The buyerCommitment field carries the cryptographic identity anchor with no raw EOA present. The zkProof field carries the zero-knowledge proof artifact. The encryptedSessionKey field carries the ECDH-protected AES session key. The ephemeralPublicKey field carries the buyer's ephemeral ECDH public key required for the seller to derive the shared secret.

The seller processes these fields in a strict sequence: verify ZK proof, check nullifier against the replay cache, store the nullifier, derive the ECDH shared secret using the ephemeral public key and the seller's static private key, decrypt the session key, decrypt the inference payload, then proceed with payment validation and upstream forwarding.

<br>


---

# Agent Instructions: 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.openshard.ai/core-concepts/privacy-mechanism/end-to-end-encryption-e2ee.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.