TLS terminates at your CDN, load balancer, or WAF. After that point, request and response bodies are plaintexts. Cloudflare, AWS ALB, GCP -- they can all read your API payloads. For most production APIs, this is the reality.
hpke-http adds RFC 9180 HPKE encryption on top of TLS. It's a drop-in middleware for FastAPI (server) and aiohttp/httpx (client). Zero application code changes:
That's it. Your existing routes, request.json(), return values -- all unchanged. Bodies are encrypted end-to-end between client and origin server.
What it does: encrypts/decrypts request and response bodies using X25519 + HKDF-SHA256 + ChaCha20-Poly1305. PSK mode binds each request to an API key. Counter-based nonces prevent replay attacks. SSE streaming and file uploads work with O(chunk_size) memory. Optional zstd compression before encryption.
What it does NOT do: encrypt URLs, headers, query params, or status codes. Those remain visible to intermediaries. This is not a replacement for TLS -- it's a layer on top.
Cipher suite is a single opinionated choice (no algorithm negotiation), validated against official CFRG test vectors and Wycheproof. 10K lines of library, 14K lines of tests including property-based fuzzing and statistical randomness verification.
We looked for an open-source, standards-based HTTP body encryption middleware and couldn't find one, so we built it. Apache-2.0.
I built exec-sandbox because I wanted VM-level isolation for AI-generated code on my Mac without running Linux in a VM first.
Most sandboxes (E2B, Hopx) use https://firecracker-microvm.github.io/, on macOS, you need nested virtualization. exec-sandbox uses QEMU with Apple's Hypervisor.framework (HVF) and runs natively on macOS, including Apple Silicon.
What makes it different:
- Native macOS + Linux, no Docker, no nested VMs, just brew install qemu
- 1-2ms warm start, pre-started VM pool beats E2B's 150ms cold start
- Port forwarding without network, expose localhost:8080 while blocking all outbound (DNS + IP)
- Domain allowlisting, allowed_domains=["api.github.com"] for granular control
- CLI for automation, sbx run *.py -j 10 --json with concurrency control
- Package validation, blocks typosquatting against PyPI/npm top 10k
- Self-hosted, no session limits, unlike E2B's 24-hour cap
NATS is a fantastic piece of software. But doc’s unpractical and half backed. That’s a shame to be required to retro engineer the software from GitHub to know the auth schemes.
Project creator there. The biggest challenge in marketing this project to potential customers is not the fact that it does not work well, but the unions and human problems. It really marked me.
Indeed. I’m the project creator. That’s standard legal notice we must add to these kind of “large” repos. If not a dev team should maintain it full time with security incidents response managed within a SLA, which is not the case there. The same project is working in production for a few customers.
Probably related to AWS outage. Are they infra not reliable enough? Do you think this kind of critical communication service should be deployed cross-provider?
hpke-http adds RFC 9180 HPKE encryption on top of TLS. It's a drop-in middleware for FastAPI (server) and aiohttp/httpx (client). Zero application code changes:
That's it. Your existing routes, request.json(), return values -- all unchanged. Bodies are encrypted end-to-end between client and origin server.
What it does: encrypts/decrypts request and response bodies using X25519 + HKDF-SHA256 + ChaCha20-Poly1305. PSK mode binds each request to an API key. Counter-based nonces prevent replay attacks. SSE streaming and file uploads work with O(chunk_size) memory. Optional zstd compression before encryption.
What it does NOT do: encrypt URLs, headers, query params, or status codes. Those remain visible to intermediaries. This is not a replacement for TLS -- it's a layer on top.
Cipher suite is a single opinionated choice (no algorithm negotiation), validated against official CFRG test vectors and Wycheproof. 10K lines of library, 14K lines of tests including property-based fuzzing and statistical randomness verification.
We looked for an open-source, standards-based HTTP body encryption middleware and couldn't find one, so we built it. Apache-2.0.
https://github.com/dualeai/hpke-http