Nen

About Nen

Nen addresses a gap that is not a flaw in TLS so much as the place TLS stops. HTTPS protects a request in transit and does it well, but the moment TLS terminates — at the load balancer, the CDN edge, the serverless runtime — the JSON body sits in plaintext across logs, databases, proxies and every third-party hop. Nen keeps the payload itself encrypted end to end, so the trust boundary moves inward past all of that to the specific code that genuinely needs to read the data. The integration is deliberately small: swap fetch for nenFetch on the client, wrap the route handler with withNen on the server, and the handshake, key rotation, per-request HMAC and replay protection happen underneath, roughly ten lines start to finish. The cryptography is post-quantum by default — ML-KEM-768 key exchange under FIPS 203 with ChaCha20-Poly1305 for the payload — which matters specifically for harvest-now-decrypt-later exposure, since payloads that come to rest as ciphertext in a queue or a database stay protected. Encrypted server-sent-event streaming is supported, along with in-memory, Redis and edge session stores. The site is unusually careful about what it does not claim: it states plainly that the two Nen endpoints necessarily hold plaintext, publishes a threat model and protocol spec, and even links a page arguing that if your only concern is the public transit leg, PQ-TLS already covers you. The SDK is open source with no limits.

Key Features

Tags