ntfyx

Encrypted content. Clear limits.

How ntfyx protects messages and where endpoint trust still matters.

End-to-end content encryption

Titles, bodies, options, answers, links, and display names are encrypted at endpoints. HPKE uses DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, and AES-256-GCM. Each recipient gets an independent ciphertext. Separate P-256 ES256 keys sign the entire compact JWS, including all recipient ciphertexts. Relays return the original complete signed envelope.

Device authority

The primary phone holds the Inbox management root and signs each Topic roster. A Source has only its own sending and reply keys. Each browser receives its own receiver keys; it cannot manage the Inbox, read another Source’s private messages, or inherit old request authorization.

Browser trust

Private browser keys are non-extractable WebCrypto keys stored in IndexedDB. Cached content uses a local non-extractable AES-GCM key. This reduces accidental key export; a compromised app build, malicious extension, or controlled endpoint can still access decrypted content. Browsers trust the code served on every load. No analytics, advertising scripts, or service worker are part of the Inbox.

Pairing and revocation

Pairing uses a five-minute, one-use, high-entropy QR secret and HPKE PSK exchange bound to the origin, role, intent, and keys. Disconnecting a browser revokes its capability and clears local state. Offline disconnect clears local state first and requires phone-side revocation if the server could not be reached. Already-delivered content cannot be remotely erased.

Metadata and cryptographic limits

The relay sees opaque IDs, time, byte size, coarse message kind, request state, and delivery information. It cannot search encrypted content. This design does not provide full key transparency or historical forward secrecy after a receiver private-key compromise. Standard cryptographic building blocks do not by themselves prove the product secure.

Review and reporting

An independent security review has not yet been completed. Production release is gated on review and remediation of high-risk findings. The security contact must be verified before launch; no unverified mailbox is advertised as monitored. During development, report findings privately to the repository owner through an already-established channel. Do not include real keys or private user content.