Messaging With
Provenance.
End-to-end encryption with Merkle-anchored provenance. Every message lifecycle event — delivery, read, deletion — produces a cryptographic proof anchored in a transparency log.
Sovereign Mail encrypts in your browser with ECDH P-384. Private keys never leave IndexedDB. The server stores ciphertext it cannot decrypt, and every operation is independently verifiable.
The Stakes
91% of cyberattacks start
with a phishing email.
Business Email Compromise accounted for $2.9 billion in losses in 2023 alone. The attack works because email was never designed to prove who sent a message — only which domain it came from. SPF, DKIM, and DMARC validate infrastructure. They do not authenticate the individual.
Cryptographic, not administrative.
Every message is signed with ECDSA P-384. The recipient verifies the signature against the sender's Merkle-anchored public key — not a DNS record an admin controls. Between Sovereign Mail users, phishing is structurally impossible: the attacker cannot produce a valid signature without possessing the private key.
Prove delivery. Prove reading. Prove deletion.
Every lifecycle event produces a Merkle leaf: MAIL_DELIVERY at send, MAIL_READ on open, MAIL_DELETE on erasure. These are leaves in an append-only hash tree — not database entries the operator can modify. No email system produces independently verifiable lifecycle proofs.
Detect key substitution attacks.
In any E2E system, the server distributing keys can silently substitute its own. Sovereign Mail anchors every key registration in the transparency log. A substitution creates a visible, detectable event — the same principle behind Certificate Transparency for TLS, applied to email.
Prove erasure to regulators.
GDPR requires data erasure "without undue delay" but defines no mechanism to prove it occurred. MAIL_DELETE leaves provide independently verifiable evidence of data destruction — downloadable Merkle inclusion proofs that satisfy regulatory inquiries with cryptographic evidence, not confirmation emails.
01 — The Difference
Encryption Alone Is
Necessary, Not Sufficient.
Encrypted messaging protects content in transit. What it does not address is verifiable proof of delivery, receipt, and deletion — the lifecycle provenance that institutional use cases require.
| Encrypted Email Providers | Sovereign Mail | |
|---|---|---|
| Encryption | End-to-end encrypted with provider-managed key recovery. Recovery mechanisms create implicit decryption capability for the operator. | Client-side ECDH P-384 with ephemeral keys per message. AES-256-GCM. Private keys in IndexedDB, wrapped via PBKDF2 (600K iterations). No recovery backdoor — the server stores ciphertext it cannot decrypt. |
| Delivery proof | Server timestamp in a mutable database. No cryptographic binding between the delivery event and an independently verifiable record. | MAIL_DELIVERY leaf anchored in a Merkle hash tree at send time. Includes message ID, sender fingerprint, recipient fingerprints, and ciphertext hash. Independently verifiable. |
| Read receipts | Optional MDN headers. No enforcement mechanism. No cryptographic proof of receipt. | MAIL_READ leaf anchored when the recipient opens the message. Bound to the reader's authenticated identity and timestamp. Once committed, the proof is immutable. |
| Deletion | Confirmation message. No cryptographic proof of destruction. No independently verifiable audit trail for deletion events. | MAIL_DELETE leaf anchored per-party. Deleter's copy removed from object storage. Full blob purge when all parties have deleted. |
| Signatures | PGP or S/MIME available as optional add-ons. Not integrated into the core message lifecycle. | ECDSA P-384 sender signatures when signing key is loaded. Recipients verify the sender's identity cryptographically, not by trusting the From header. |
| External delivery | External delivery either refused or handled via silent fallback to unencrypted SMTP. No transparency into which path was taken. | External recipients receive actual email via relay. Fail-closed: only explicit key-not-found triggers the external path. Delivery is still Merkle-anchored. |
02 — Message Lifecycle
Compose. Encrypt.
Deliver. Prove.
Every message passes through four stages. Your browser does the cryptography. The server stores ciphertext and anchors proofs.
03 — Multi-Recipient Encryption
One Message, N Recipients,
N Separate Ciphertexts.
Each recipient gets their own encrypted copy. Each copy uses a unique ECDH shared secret. No recipient can derive another recipient's decryption key.
1. Generate ephemeral ECDH P-384 key pair
2. Generate 32-byte HKDF salt
For each recipient:
3. ECDH deriveBits(ephemeral, recipient.pub)
4. HKDF-SHA-384 → AES-256-GCM key
info: sovereign-mail-v1:{senderFp}:{recipientFp}
5. Encrypt subject + body with unique IVs
Sender copy:
6. ECDH deriveBits(ephemeral, sender.pub)
7. ECDSA P-384 signature (if signing key loaded)
1. Unlock private key with passphrase
(PBKDF2, 600K iterations, AES-GCM unwrap)
2. Import ephemeral public key from message
3. ECDH deriveBits(ephemeral.pub, recipient.priv)
4. HKDF-SHA-384 with stored salt → same AES key
info: sovereign-mail-v1:{senderFp}:{recipientFp}
5. AES-256-GCM decrypt subject + body
6. Verify ECDSA sender signature
7. MAIL_READ leaf committed on open
Proof returned: leaf hash, tree index, root
04 — Key Management
Your Keys. Your Passphrase.
Your Browser.
Private keys are generated in your browser using the Web Crypto API (ECDH P-384). Wrapped with a passphrase you choose. The server never sees your private key.
Browser-native ECDH P-384.
Key pair generated via crypto.subtle.generateKey. No server round-trip. No seed phrases. Exportable as JSON for backup.
Passphrase-protected IndexedDB.
Private key wrapped with AES-GCM via PBKDF2 (600K iterations, random 16-byte salt, 12-byte IV). Encrypted at rest. Unlocked per-session.
Key Registry + transparency log.
Public key registered with email binding. KEY_REGISTRATION event anchored in the Merkle tree. Contacts verify your fingerprint before encrypting.
Encrypted key export.
Download your encrypted key pair as a JSON file. Import on any browser. If you lose your passphrase, your messages become unreadable — by design.
05 — Transparency Events
Four Event Types.
Four Merkle Leaves. Four Proofs.
Every operation in Sovereign Mail produces a cryptographic event anchored in the transparency log. Each event becomes a leaf in the Merkle hash tree.
Anchored when you send. Contains message ID, sender fingerprint, recipient fingerprints, ciphertext hash. Proves the message existed at that timestamp.
Anchored when recipient opens the message. Contains reader fingerprint and read timestamp. Proves the message was accessed.
Anchored when a party deletes a message. Deleter's blob removed from object storage. Deletion bound to their fingerprint. Full purge when all parties delete.
Anchored when a user wipes their entire account. Records email hash and counts of deleted messages and blobs. GDPR-compatible proof of erasure.
06 — Architecture
Built on the
AGTS Backbone.
Sovereign Mail runs on the same infrastructure as Sovereign Drive and VPN Governance — edge workers, distributed metadata, encrypted blob storage, and the AGTS transparency log. Same login, same billing, same key registry.
ECDH P-384 + HKDF + AES-256-GCM.
Ephemeral ECDH per message. HKDF-SHA-384 with sender/recipient fingerprint binding. 12-byte random IVs. GCM authentication tags. Subject and body encrypted separately.
Merkle hash tree.
Every delivery, read, and deletion is committed as a leaf. Signed Tree Head (STH) published after each commit. Inclusion proofs via /verify endpoint.
Zero-trust gateway + Key Registry.
JWT-verified identity via zero-trust gateway. Public keys registered by email with fingerprint. Contact lookup before encryption ensures recipient authenticity.
Metadata + encrypted blob storage.
Message metadata in tenant-isolated database. Encrypted ciphertext blobs in distributed object storage with per-recipient keys. Attachments stored as separate encrypted blobs.
ECDSA P-384 sender authentication.
Same private key, dual-use: ECDH for key agreement, ECDSA for signing. Recipients verify the signature against the sender's registered public key.
Email relay integration.
External recipients receive real email with verification links. Fail-closed: only explicit key-not-found triggers the relay. Delivery is still Merkle-anchored.
Business Impact
The Cost of Unverifiable
Communication.
Business Email Compromise remains the most costly cyber threat. Internal deployment of Sovereign Mail eliminates intra-organizational spoofing — the most common and most expensive phishing vector.
MAIL_DELETE leaves provide independently verifiable evidence of data erasure. Respond to right-to-erasure requests with a downloadable Merkle proof, not a confirmation email.
Regulated enterprises replace "the system says it was sent" with independently verifiable cryptographic delivery receipts. MAIL_DELIVERY leaves constitute stronger evidence than server logs.
Key substitution detection closes the fundamental weakness in E2E encrypted email. Any attempt by the server to substitute a public key creates a detectable, visible event in the transparency log — the same principle that secures TLS certificates across the entire internet.
Every message produces a complete audit trail: delivery, read receipt, and deletion — each independently verifiable. For DORA, NIS2, and industry-specific regulations that require provable communication records, Sovereign Mail turns "we emailed it" into "here is the cryptographic proof."
Every Message.
Every Lifecycle Event.
Independently Verifiable.
Send a message. Watch it encrypt in your browser, deliver to the recipient, and anchor in the transparency log. Every event produces a Merkle inclusion proof.