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 establishes an HPKE encryption context to the server’s public key
- Client encrypts request body as a stream of length-prefixed chunks
- Client includes the HPKE encapsulated key in the
Ehbp-Encapsulated-Keyheader
- Server decrypts request using the encapsulated key, establishing an HPKE context
- Server exports a secret from the HPKE context using the label
"ehbp response" - Server generates a random 32-byte nonce and derives response encryption keys via HKDF using
salt = concat(encapsulated_key, response_nonce) - Server encrypts response body with AES-256-GCM using the derived keys
- Server includes the nonce in the
Ehbp-Response-Nonceheader so the client can derive the same decryption keys
Bodyless requests: Requests without a body (GET, HEAD, DELETE, OPTIONS) cannot have encrypted responses. The encrypted request body provides implicit authentication of the encapsulated key—without it, a man-in-the-middle could substitute their own key. Applications requiring encrypted responses to bodyless requests should include a minimal body.
Body Framing
Encrypted bodies are framed as a sequence of chunks:- Each chunk has a 4-byte big-endian unsigned integer length prefix
- Length counts ciphertext bytes only (not the 4-byte header)
- Each chunk is encrypted with AES-256-GCM
- A chunk with length 0 may appear (empty write) and should be skipped by receivers
- End of message is indicated by HTTP stream termination (no sentinel chunk)
Protocol Headers
Implementation Examples
The EHBP reference implementation provides ready-to-use components for both Go and JavaScript. These examples show how to add encrypted body support to an existing HTTP server or client.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

