Protocol Overview

OpenHTTPA

Attestation-first HTTP with message-level encryption, hybrid post-quantum key exchange, and hardware-rooted trust — for confidential multi-party applications.

🔐 Post-Quantum ML-KEM-768 TEE-Attested Sessions 📦 Message-Level Encryption 🤝 MPC-Ready 📋 RFC 8941 Wire Format

HTTPS vs OpenHTTPA

Traditional HTTPS secures the transport channel. OpenHTTPA secures each message and proves — via hardware attestation — exactly what code processes it inside the TEE.

Traditional HTTPS / TLS 1.3
OpenHTTPA
AtHS Protocol

Attestation Handshake (SIGMA-I)

The AtHS (Attest Handshake) is a 1.5-RTT SIGMA-I exchange that derives a hybrid post-quantum session key bound to a TEE attestation quote. Click ► Play to step through, or click any message to inspect headers.

Ready — press Play
Client
Browser / SDK
Generates ephemeral
key pair
0
OPTIONS preflight click to expand
 Client → Server  ·  CORS preflight for ATTEST method
OPTIONS / HTTP/2
Host: openhttpa.aiql.org
Access-Control-Request-Method: ATTEST
Access-Control-Request-Headers: attest-cipher-suites, attest-key-shares, attest-random
Origin: https://openhttpa.aiql.org

/* Server response: */
HTTP/2 204 No Content
Access-Control-Allow-Methods: ATTEST, GET, POST
Access-Control-Allow-Headers: attest-*
Access-Control-Max-Age: 86400
A standard CORS preflight lets browsers send the custom ATTEST method cross-origin. No key material is transmitted here.
1
ATTEST / — AtHS Request  (key shares + nonce) click to expand
 Client → Server  ·  AtHS Request (custom ATTEST HTTP method)
ATTEST / HTTP/2
Host: openhttpa.aiql.org

Attest-Versions: openhttpa
              /* RFC 8941 Token list — supported HTTPA versions, ordered */

Attest-Cipher-Suites: X25519_ML_KEM768_AES256GCM_SHA384, P384_ML_KEM1024_AES256GCM_SHA384, X25519_AES256GCM_SHA384, X25519_CHACHA20POLY1305_SHA256, P256_AES256GCM_SHA256
              /* Per CipherSuite::preferred_list() — server picks first mutually-supported suite */

Attest-Random: :V29ybGQxMjM0NTY3ODkwYWJjZGVmZ2hp:
              /* RFC 8941 Byte Sequence — 32-byte nonce, fresh per handshake */

Attest-Key-Shares: :eyJlY2RoZV9wdWJsaWMiOiI8MzItYnl0ZXM-IiwibWxrZW1fcHVibGljIjoiPDExODQtYnl0ZXM-In0=:
              /* base64url(JSON( ClientKeyShare { ecdhe_public: [u8; 32], mlkem_public: [u8; 1184] } ))
                 Both fields included verbatim in HKDF combiner IKM (HybridSharedSecret::combine) */

Attest-Base-Creation: new
              /* Token: "new" = fresh ATB; "resume" = ticket-based resumption */

Attest-Date: 2026-04-28T10:00:00Z
              /* ISO-8601 — server may reject stale requests */
The client sends ClientKeyShare { ecdhe_public: Vec<u8> [32 B], mlkem_public: Vec<u8> [1 184 B] } serialised as JSON and base64url-encoded per RFC 8941 Byte Sequence. Both keys are included verbatim as ecdhe_pk_c and mlkem_ek_c in the HKDF combiner IKM — binding the derived session key to this exact key material. No private key material is transmitted.
2
200 OK — AtHS Response  (TEE quote + server key share)
 Server → Client  ·  AtHS Response
HTTP/2 200 OK

Attest-Version: openhttpa
              /* Chosen protocol version */

Attest-Cipher-Suite: X25519_ML_KEM768_AES256GCM_SHA384
              /* Selected suite — governs AEAD algorithm + HKDF hash */

Attest-Base-ID: :A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6:
              /* 16-byte ATB session identifier — included in all subsequent TrRs */

Attest-Key-Share: :eyJlY2RoZV9wdWJsaWMiOiI8MzItYnl0ZXM-IiwibWxrZW1fY2lwaGVydGV4dCI6IjwxMDg4LWJ5dGVzPiJ9:
              /* base64url(JSON( ServerKeyShare { ecdhe_public: [u8; 32], mlkem_ciphertext: [u8; 1088] } ))
                 mlkem_ciphertext = MlKemPair::encapsulate(client_mlkem_public) on server
                 Client: MlKemPair::decapsulate(mlkem_ciphertext) → kem_ss (never on wire) */

Attest-Random: :WFlaQUJDREVGMTIzNDU2Nzg5MDEyMzQ1:
              /* Server nonce — mixed into HKDF alongside client nonce */

Attest-Quotes: :SGVsbG8gV29ybGQhIFRFRSBBdHRlc3RhdGlvbiBRdW90ZQ==:
              /* TEE attestation evidence (SGX DCAP quote / TDX TD Report / TPM PCR log).
                 quote.report_data = SHA-384(AtHS transcript) — binds enclave to this exact
                 handshake; client MUST verify before deriving any keys. */

Attest-Expires: 3600
              /* RFC 8941 Integer — ATB session lifetime in seconds */
Attest-Quotes is the key differentiator from TLS. The server computes T = SHA-384(client_random ‖ server_random ‖ client_share_json ‖ server_share_json), then calls TeeProvider::generate_quote(&QuoteRequest { report_data: T[0..48] }). report_data[48..64] is zero-padded. The hardware embeds T in a tamper-proof MRENCLAVE / TD Report / PCR measurement. The client verifies the quote — and that its report_data equals the T it computed independently — before deriving any session keys.
3
POST /api/submit — TrR (AEAD-encrypted payload) click to expand
 Client → Server  ·  Trusted Request (TrR) — session-protected
POST /api/submit HTTP/2
Host: openhttpa.aiql.org
Content-Type: application/json

Attest-Base-ID: :A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6:
              /* References the ATB established in AtHS */

Attest-Binder: :4f6e636521AEAD_MAC_over_request_headers_and_counter:
              /* AEAD tag over canonical headers + monotonic sequence counter.
                 Tampered headers or replayed requests are immediately detected. */

/* Body: AES-256-GCM ciphertext (key = session_key derived in AtHS) */
/* Plaintext: {"party_id":"alice","value":42}                        */
[nonce 12B][ciphertext ...][auth-tag 16B]
After AtHS, every request body is encrypted with client_write_key (AES-256-GCM, 32 B). Unlike TLS, this protection survives termination at proxies or load balancers — only the intended TEE server holds the key. Attest-Binder is validated by ReplayGuard<64>: a 64-word × 64-bit sliding bit-window (4 096-nonce capacity). Nonce 0 and nonces older than the window are rejected; duplicate nonces trigger ReplayError::Replay. The nonce itself is constructed using the TLS 1.3 §5.3 XOR scheme: nonce = write_iv ⊕ seq_counter.
TEE Server
Hardware Enclave
Generates attestation
quote + key share

Session Key Derivation openhttpa-crypto/src/key_exchange.rs · hkdf.rs

Both parties independently derive identical session keys — no key material is transmitted. The combiner follows draft-ietf-tls-hybrid-design §3.2 for IND-CCA2 security.

Step 1 — Key agreement & decapsulation
X25519 ECDH
client_priv × server_pub
ecdhe_ss
32 B
ML-KEM-768 Decap
mlkem_ct, client_decap_key
kem_ss
32 B
Step 2 — IND-CCA2 combiner IKM  HybridSharedSecret::combine()
ecdhe_ss
kem_ss
“openhttpa hybrid kem v1”
label [20 B]
ecdhe_pk_c
32 B
ecdhe_pk_s
32 B
mlkem_ek_c
1 184 B
mlkem_ct
1 088 B
HKDF-Extract
combined_secret
Step 3 — Handshake transcript hash  Sha384::chain_update()
client_random
32 B (Attest-Random)
server_random
32 B (Attest-Random)
client_share_json
Attest-Key-Shares
server_share_json
Attest-Key-Share
T = SHA-384(…)
48 B
🛡 report_data[0..48] = T — TEE hardware seals the quote over T, binding MRENCLAVE to this session
Step 4 — HKDF-SHA384 expand  salt = “openhttpa handshake v2”
combined_secret
IKM
+
T
transcript
HKDF-Extract
PRK
HKDF-Expand
info = T ‖ label
master_secret
48 B
client_write_key
32 B → AES-256-GCM
server_write_key
32 B → AES-256-GCM
client_write_iv
12 B nonce base
server_write_iv
12 B nonce base
The combiner includes all public keys and the ML-KEM ciphertext — not just the raw shared secrets — so the combined secret is IND-CCA2-secure even if one component is broken. An attacker must break both X25519 and ML-KEM-768 simultaneously. Separate client_write_key / server_write_key prevent reflection attacks. HKDF info labels bind each derived key to the full transcript: T‖“client write key”, etc.
Wire Protocol

Header Wire Format

All Attest-* headers conform to RFC 8941 Structured Field Values. Binary payloads use the SFV Byte Sequence type: base64url (no padding) wrapped in : delimiters. Select a tab to explore each protocol phase.

Field kind SFV type Wire example Notes
Binary blobs (keys, nonces, quotes) Item – Byte Sequence :aGVsbG8=: base64url, no padding, colon-delimited per RFC 8941 §4.1.8
Cipher suite / version lists List of Token X25519_ML_KEM768…, openhttpa Comma-separated; ordered by preference (most preferred first)
Scalar state flags Item – Token new Unquoted identifier (no quotes, no colon delimiters)
Integers (expiry, counters) Item – Integer 3600 Plain decimal integer; no quotes required
 ATTEST Request — AtHS Phase
ATTEST / HTTP/2

Attest-Versions: openhttpa
Attest-Cipher-Suites: X25519_ML_KEM768_AES256GCM_SHA384, P384_ML_KEM1024_AES256GCM_SHA384, X25519_AES256GCM_SHA384, X25519_CHACHA20POLY1305_SHA256, P256_AES256GCM_SHA256
Attest-Random: :V29ybGQxMjM0NTY3ODkwYWJjZGVmZ2hp:
Attest-Key-Shares: :eyJlY2RoZV9wdWJsaWMiOiI8MzItYnl0ZXM-IiwibWxrZW1fcHVibGljIjoiPDExODQtYnl0ZXM-In0=:
Attest-Base-Creation: new
Attest-Date: 2026-04-28T10:00:00Z
Method / version
Header name
Header value
 200 OK — AtHS Response
HTTP/2 200 OK

Attest-Version: openhttpa
Attest-Cipher-Suite: X25519_ML_KEM768_AES256GCM_SHA384
Attest-Base-ID: :A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6:
Attest-Key-Share: :eyJlY2RoZV9wdWJsaWMiOiI8MzItYnl0ZXM-IiwibWxrZW1fY2lwaGVydGV4dCI6IjwxMDg4LWJ5dGVzPiJ9:
Attest-Random: :WFlaQUJDREVGMTIzNDU2Nzg5MDEyMzQ1:
Attest-Quotes: :SGVsbG8gV29ybGQhIFRFRSBBdHRlc3RhdGlvbiBRdW90ZQ==:
Attest-Expires: 3600
Status line
Header name
Header value
 Trusted Request (TrR) — session-protected
POST /api/submit HTTP/2
Content-Type: application/json
Attest-Base-ID: :A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6:
Attest-Binder: :4f6e636521AEAD_MAC_over_request_headers_and_counter:

/* Body — AES-256-GCM ciphertext (session_key derived in AtHS)  */
/* Plaintext:  {"party_id":"alice","value":42}                   */
[nonce 12B][ciphertext ...][auth-tag 16B]
Header name
Header value
Encrypted content
multiparties

Multi-Party Computation

Three parties submit private values inside TEE-attested OpenHTTPA sessions. The server aggregates without revealing individual values — the result includes an attestation quote proving computation occurred inside the enclave.

Submit Secret Value

🔒 OpenHTTPA Session Proof

Base-ID Cipher Suite Version Post-Quantum Transcript Hash Session Keys Quote Type Verified TEE Hardware tdx tdx nvidia_gpu TTL
View all Attest-* wire headers from this handshake
→ AtHS Request
Header Wire Value Notes
← AtHS Response
Header Wire Value Notes

Reveal Aggregate

Aggregated sum (TEE-verified)
Parties:    TEE-attested
View attestation quote (base64)

                

Protocol Log

[init] OpenHTTPA demo — backend at loading...
[init] Waiting for party submissions…
loading wasm…
Agentic AI & MCP

Confidential Tool Execution (MCP)

Leverage the Model Context Protocol (MCP) to execute tools securely inside a TEE. Every tool call is a TrR (Trusted Request) protected by OpenHTTPA, ensuring even the host cannot inspect tool arguments or results.

Confidential MCP Call

Example: {}
MCP Result (Confidential)

            

Agent-to-Agent (A2A)

Agents communicate using M-HTTPA (Mutual OpenHTTPA), where both sides attest to each other before exchanging messages.

Swarm Orchestration

Attested Agent Mesh (AAM)

Orchestrate massive swarms of autonomous agents. Every agent in the mesh is TEE-attested, ensuring end-to-end cryptographic integrity across multi-hop delegations and secure tool execution.

Swarm Controller

Launch a high-fidelity simulation of 10 virtual agents performing mutual attestation and confidential Monte Carlo estimation.

Mesh Execution Log

Ready to simulate. Press "Launch" to start.
Audit & Transparency

Attested Provenance Chain

Inspect the full cryptographic chain of custody for multi-hop agent requests. Each hop appends its hardware identity, verified via TEE attestation.

Provenance Visualizer

Execute a swarm simulation or MCP tool to see provenance logs.
Regulatory & Standards

Standards & Compliance

OpenHTTPA is engineered for high-assurance environments, meeting the rigorous demands of the IETF and NIST. The following technical reports and specifications provide the formal foundation for the protocol.

IETF Submission

Internet-Draft (Protocol Wire)

The authoritative specification for the OpenHTTPA wire format, SIGMA-I handshake, and SFV header definitions.

Read I-D Specification
Security Audit

Mathematical Assurance

OpenHTTPA has undergone a rigorous expert security audit by top-tier mathematicians. The protocol is formally proven to provide secrecy, authentication, and perfect forward secrecy (PFS).

ProVerif Proof

Verified

Symbolic model verification of secrecy and authentication.

  • Secrecy: Payload data is provably inaccessible.
  • Authentication: Identity is bound to the TEE.
View Formal Models →

Tamarin Prover

Verified

Temporal analysis of Forward Secrecy and replay protection.

  • Forward Secrecy: History is safe after key leaks.
  • Agreement: Strong injective agreement verified.
View Proof Details →

Verification Infra

Reproducible prover source files and security analysis.

Reproduction Guide → Deniability Analysis →
$ make formal-verify

Expert Recommendations Implemented

Audit Status: PASS
✓ Lemma Granularity

PFS proof now distinguishes between long-term TEE identity and session secrecy.

✓ Implementation Review

Property-based tests integrated to verify canonicalization against symbolic failures.

✓ Privacy Analysis

Deniability trade-offs documented for high-accountability agentic workflows.

Real-time Inference

Confidential Streaming Chat

Experience end-to-end encrypted LLM inference with low latency. Each token is delivered as a separate encrypted chunk in a binary stream, protected by hardware attestation.

Confidential LLM Chat

Streaming Result (Decrypted)

Streaming Protocol Proof

Binary Framing [Len (4b)] || [Counter (8b)] || [Ciphertext] Integrity Cumulative SHA-384 Transcript Hash Protection Strict Monotonic Counters per Chunk Latency < 50ms per token (attested overhead)
[stream] Ready to receive tokens…
Web3 & Bitcoin Bridge

Confidential Oracle Bridge

Bridge off-chain Web2 data (market prices, weather, APIs) trustlessly to smart contracts. Data is fetched inside a TEE and mathematically bound to a TEE quote and ZK proof for on-chain verification.

Attested Data Fetch

GPU-Accelerated ZK (Metal/CUDA)
Oracle Response (Verified)

            

On-Chain Verification Proof

Protocol Binding SHA-384(Transcript) || SHA-256(Payload) TEE Evidence Awaiting fetch... ZK Receipt Awaiting fetch... Bridge Ready Pending
Real-time Streaming

Attested WebSockets

OpenHTTPA supports transparent encryption for WebSockets. Every frame is AEAD-encrypted with hardware-attested keys, preventing inspection by proxies or the host OS.

Secure Chat

Status: Disconnected

Live Decrypted Messages

No messages yet. Connect to start.

How it works

1. Handshake: Standard AtHS establishes session keys.

2. Upgrade: Client sends Upgrade: websocket with Attest-Base-ID.

3. Enforcement: Every binary frame is: [12B Nonce] || [AES-256-GCM( MSG_TYPE || Payload )]

4. Binding: AAD = AtbId. This ensures frames cannot be spliced between sessions.

TEE hardware driver error