Overview
EHBP (Encrypted HTTP Body Protocol) is a protocol that encrypts HTTP message bodies end-to-end while leaving HTTP headers in the clear for routing. This allows encrypted payloads to transit proxies unchanged while maintaining all standard HTTP semantics. The protocol uses HPKE (RFC 9180) for hybrid public key encryption, ensuring that only the intended recipient can decrypt the message body.How It Works
Architecture
EHBP is implemented as two complementary components:- Client Transport: Encrypts outgoing request bodies and decrypts incoming response bodies
- Server Middleware: Decrypts incoming request bodies and encrypts outgoing response bodies
Message Flow
For each HTTP exchange:Encryption Process
Request Encryption:- Client fetches server’s public key from
/.well-known/hpke-keys
- Client generates ephemeral key pair
- Client derives HPKE encryption context from server’s public key
- Client encrypts request body as a stream of length-prefixed chunks
- Client includes
Ehbp-Client-Public-Key
andEhbp-Encapsulated-Key
headers
- Server reads client’s public key from request header
- Server derives HPKE encryption context from client’s public key
- Server encrypts response body as a stream of length-prefixed chunks
- Server includes
Ehbp-Encapsulated-Key
header
Body Framing
Encrypted bodies are framed as a sequence of chunks:- Each chunk has a 4-byte big-endian length prefix
- Length counts ciphertext bytes only
- AEAD encryption (AES-256-GCM) is applied to each chunk
- End of message is indicated by HTTP entity body termination
Protocol Headers
Request Headers
Ehbp-Client-Public-Key
: Required for any request expecting an encrypted response (including GET requests with no body)Ehbp-Encapsulated-Key
: Required only when request has an encrypted bodyTransfer-Encoding
: Set tochunked
when sending encrypted bodies
Response Headers
Ehbp-Encapsulated-Key
: Required for encrypted responsesEhbp-Fallback
: Set to1
if server responded in plaintext (when fallback is enabled)
Implementation Examples
Go Server Middleware
Go Client Transport
JavaScript/TypeScript Client
Key Distribution
Server Public Key Discovery
Servers must expose their HPKE configuration at:- Content-Type:
application/ohttp-keys
- Body: Key configuration as defined in RFC 9458 Section 3
key_id
: 0kem_id
: X25519_HKDF_SHA256cipher_suites
: HKDF_SHA256 with AES_256_GCMpublic_key
: Server’s KEM public key bytes
Identity Management
Server Identity:CLI Tools
The EHBP repository includes command-line tools for testing and development.Example Server
Example Client
Fetch Tool
curl-like tool that sends encrypted requests:Use in Tinfoil Node SDK
The Tinfoil Node SDK uses EHBP to encrypt all API request and response bodies to the inference enclaves. This is particularly important for browser environments where TLS certificate pinning is not available. Why EHBP in the browser? Since browsers don’t support certificate pinning, EHBP provides an alternative mechanism to verify you’re communicating with the attested enclave. The SDK:- Fetches the enclave’s attested HPKE public key
- Encrypts all request bodies directly to that verified key
- Decrypts response bodies from the enclave
TinfoilAI
client:
- Client automatically fetches and verifies the enclave’s public key
- All request bodies are encrypted with EHBP before transmission
- All response bodies are decrypted after receipt
- HTTP headers remain visible for API routing and load balancing
EHBP in Action
You can see EHBP in action by visiting chat.tinfoil.sh and inspecting the network tab. The request payload shows encrypted content that only the attested enclave can decrypt: