Encrypt & Share — Dual-KEM Zero-Knowledge Architecture

Encrypt Flow

Encryption is entirely client-side. The browser generates keypairs and performs all cryptographic operations via the PQ Crypta API (api.pqcrypta.com). The server only ever receives ciphertext and encrypted key blobs — it never sees plaintext or the wrap key.

URL Structure

The URL is the complete security boundary. Everything before the # can be seen by the server. Everything after it is private to the browser.

Decrypt Flow

When a recipient opens the share URL, all decryption happens in the browser. The server provides only the opaque ciphertext envelope. The wrap key in the fragment unlocks everything — and the server never sees it.

Versioned Envelope

Every message is stored in a versioned JSON envelope. The version field ensures forward compatibility: as the encryption format evolves, older links continue to decrypt correctly using the appropriate version handler.

Database Schema

The share_messages table is the only persistent store. It holds the ciphertext envelope but nothing that can identify the message content or the parties involved.

CREATE TABLE share_messages (
    id              UUID         PRIMARY KEY DEFAULT gen_random_uuid(),
    blob            TEXT         NOT NULL,              -- JSON envelope (ciphertext only)
    key_blob        TEXT         NOT NULL DEFAULT '',   -- AES-wrapped private keys
    algorithm       VARCHAR(64)  NOT NULL DEFAULT 'ml-kem-1024+hqc-256',
    created_at      TIMESTAMPTZ  DEFAULT NOW(),
    expires_at      TIMESTAMPTZ  NOT NULL,
    view_count      INT          DEFAULT 0,
    burn_after_read BOOLEAN      DEFAULT FALSE,
    destroyed       BOOLEAN      DEFAULT FALSE,
    ip_hash         TEXT,                              -- SHA-256 (ip + salt), not reversible
    message_size      INT          DEFAULT 0,
    short_code        VARCHAR(12)  UNIQUE,              -- 6-char base-58 short link
    envelope_ver      SMALLINT     NOT NULL DEFAULT 1,
    destroy_auth_hash VARCHAR(64)              -- SHA-256(HKDF destroy key) — null on v1/v2 legacy
);

-- Partial indexes: only live messages are queried
CREATE INDEX idx_share_expires   ON share_messages(expires_at)  WHERE NOT destroyed;
CREATE UNIQUE INDEX idx_share_short ON share_messages(short_code) WHERE short_code IS NOT NULL;

The blob column holds the JSON envelope. Without the wrap key from the URL fragment, this data is computationally indistinguishable from random bytes. The key_blob column holds the AES-wrapped private keys. Neither field contains recoverable plaintext without the wrap key.

Zero-Knowledge Architecture

The defining security property of Encrypt & Share is zero-knowledge: the server holds ciphertext and cannot decrypt it, even with full administrative access and unlimited compute. This is not a policy claim — it is an architectural constraint.

This means:

• A subpoena to PQ Crypta produces only ciphertext.
• A server breach leaks only ciphertext.
• A database dump leaks only ciphertext.
• A network intercept of the API call leaks only ciphertext and the UUID lookup.

The only copy of the wrap key exists in the URL as held by the sender and recipient. If the URL is kept private, the message is private — against any adversary that does not have access to the sender’s or recipient’s device.

Algorithm Diversity

ML-KEM-1024 is based on the Module Learning With Errors (MLWE) problem — a variant of LWE with module structure, whose hardness assumption is the difficulty of distinguishing module lattice samples from random. HQC-256 is based on the Quasi-Cyclic Moderate Density Parity Check (QC-MDPC) problem — a code-based problem from information theory unrelated to lattices.

An attack that breaks ML-KEM-1024 must exploit the MLWE structure — this gives zero information about HQC-256’s QC-MDPC structure, and vice versa. The two security assumptions are mathematically independent. Both must fail simultaneously for any message in the system to be readable.

Length-Hiding Padding

Without padding, ciphertext length leaks message length. An adversary observing traffic can distinguish a “password” from a “3,000-word legal document” by their ciphertext sizes. This is a traffic analysis attack that survives end-to-end encryption.

Encrypt & Share pads all messages to a fixed 4,096-byte block boundary before encryption. The padding consists of cryptographically random bytes appended to the UTF-8 encoded message. A separator byte marks the boundary between content and padding to enable reliable unpadding. A 10-character note and a 3,000-character letter produce identically-sized ciphertexts (subject to the block-size multiple).

Tamper-Evident Metadata

Message metadata (expiry hours, burn-after-reading flag, envelope version) is stored in the database alongside the ciphertext. Without protection, a malicious server operator or attacker with database access could modify this metadata — for example, disabling the burn-after-reading flag to read a message multiple times, or extending the expiry of a message that should have been destroyed.

Encrypt & Share protects against this with an HMAC-SHA-256 signature over the metadata, using a 32-byte key derived from the wrap key via a key derivation step. This MAC travels in the URL fragment alongside the wrap key. On decryption, the browser recomputes the MAC and compares it against the metadata in the retrieved envelope before proceeding with decryption. Any mismatch aborts the operation.

Threat Model

Cross-Verification

Cross-verification is the final layer of integrity checking. After both ciphertexts are decrypted independently by their respective algorithms, the resulting plaintexts are compared byte-for-byte. Correct dual encryption of the same plaintext under two independent algorithms must produce identical plaintexts on decryption.

If the plaintexts differ, one of the following has occurred: (1) the server has replaced or corrupted one ciphertext; (2) the private keys have been tampered with such that only one decryption path succeeds; or (3) an implementation bug exists. In all cases, the mismatch is surfaced to the user and decryption is aborted. This provides an active tamper detection mechanism beyond what AES-GCM authentication tags alone provide.

Passphrase Layer

The passphrase layer is an optional second encryption pass applied to the plaintext before it enters the dual-KEM envelope. It addresses a specific threat: URL channel compromise. If the share URL is observed by an attacker — through URL shortener logs, browser history, or a compromised communication channel — the wrap key in the fragment is exposed. Without the passphrase layer, the wrap key is sufficient to decrypt. With it, the attacker still needs a second credential.

On decryption, the browser checks for the pp1: prefix after dual-KEM unwrap and before displaying the message. If found, it prompts the recipient for the passphrase. The passphrase layer is transparent to the dual-KEM — it operates on a layer above it. A recipient without the passphrase sees a prompt, not an error, and cannot proceed.

Preview Hash Fingerprint

Before encryption, the browser computes SHA-256(UTF-8(plaintext)) and takes the first 8 hex characters. This fingerprint is embedded in the URL fragment as the fourth colon-separated component, alongside the wrap key, HMAC signature, and is signed implicitly by the HMAC sub-key derivation. On decryption, the browser recomputes it from the decrypted plaintext and compares against the URL value.

The preview hash protects against a specific attack not covered by cross-verification: a malicious server returning a completely different, validly-structured envelope to the recipient. Cross-verification detects tampering within one pair of ciphertexts. The preview hash detects substitution of the entire envelope. The sender can also communicate the fingerprint out-of-band (“expect fingerprint a3f9c2b1”) as an additional assurance channel.

Integrity Badge

After every successful decryption, the browser renders an integrity badge displaying the outcome of each verification step performed during that session. The badge is constructed entirely from local verification results — no server input. Each item is one of three states: passed (green), failed (red, decryption aborted), or not applicable (grey, feature absent in this link version).

Client-Side Cryptography

All cryptographic operations are performed client-side in the browser via the PQ Crypta API. The JavaScript client (/share/js/share.js) is a self-contained IIFE with no external dependencies beyond the platform’s Web Crypto API and the PQ Crypta REST API. An API key is loaded at startup from /api_config.php (same-origin) and attached to every PQC API request via the X-API-Key header.

The wrap key and all decrypted key material exist only in JavaScript variables for the duration of the operation. They are not stored in localStorage, sessionStorage, cookies, or any persistent browser storage.

API Layer

The PQ Crypta API runs at api.pqcrypta.com on port 3003. It is a Rust-based HTTP server providing key generation, encryption, and decryption endpoints for all 31 supported post-quantum algorithms. The max-secure-pure-pq engine handles ML-KEM-1024; ML-DSA-87 and SLH-DSA-SHA2-256s authenticate the API response envelope — they prove the encryption came from a valid PQ Crypta API instance, not a tampered intermediary. They do not sign the user’s plaintext. hqc-256 handles the code-based KEM.

The share page uses API key authentication via the X-API-Key header, loaded from /api_config.php at runtime. The API enforces granular permissions per endpoint per key.

Server-Side Storage

/share/api.php handles four actions over a PostgreSQL database:

Short Links

Every encrypted message receives a 6-character base-58 short code in addition to its full UUID URL. The alphabet excludes visually ambiguous characters (0, O, I, l) to minimise transcription errors: 23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghjkmnpqrstuvwxyz.

The short link form is pqcrypta.com/share/?s=Ab3Xk9#wrapKey:metaMac. The server resolves the short code to a UUID internally. The wrap key fragment is never included in the short code and never sent to the server as part of the short-code lookup. It is always appended to the full resolved URL by the browser.

Expiry, Burn-After-Reading, and Client-Side Timers

Server-Side Expiry

Expiry is set using three independent dropdowns — days (0–7), hours (0–23), and minutes (0–59) — giving granular control over any duration from 1 minute to 7 days. When days is set to 7 (the maximum), hours and minutes are automatically zeroed and locked. The default is 1 hour. The server validates that the computed total falls within the allowed range before storing the message.

Expiry is enforced at two independent levels: the expires_at column is checked on every retrieve attempt and returns an error immediately on any expired message, and a cleanup sweep runs on every API call to set destroyed=true and clear blob='' on all rows where expires_at < NOW(). Expiry hours are stored in the envelope and signed by the metadata HMAC — the server cannot silently extend a link’s lifetime without breaking the MAC.

Burn-After-Reading

Burn-after-reading is implemented atomically within the retrieve operation: the destroyed flag is set and blob is cleared in the same database update that returns the row to the client. A race condition between two simultaneous retrieve requests for the same burn-message is resolved by the PostgreSQL row-level update: only the first succeeds; the second receives an empty blob and an error response.

Client-Side Security Timers

Two independent JavaScript timers run in the browser to minimise the window during which sensitive content is visible on screen. Neither timer is negotiable or bypassable through the URL — they are hardcoded security constants.

CSP and No-Leak Design

The share page enforces a strict Content Security Policy that blocks inline scripts, inline styles, and event handler attributes. All scripts are loaded as external files with nonces. The connect-src directive limits API calls to api.pqcrypta.com. The frame-ancestors 'none' directive prevents the page from being loaded inside an iframe, protecting against clickjacking. A Referrer-Policy: no-referrer header ensures the share URL (including any cached URL that might contain the fragment) is not sent as a Referer to any external resource.

The decrypted message content is inserted into the DOM using textContent, not innerHTML — eliminating any XSS vector from the message payload. No user-supplied content ever reaches innerHTML, eval(), or any equivalent execution sink.

Link Health Check

After step 10 of the encrypt flow, and before the share URL is shown to the sender, the browser runs a full in-memory roundtrip verification using only key material already held in JavaScript variables from the encryption just completed.

Self-Audit Mode

Self-audit mode is accessible on the decrypt view via a “Show audit data” toggle. It surfaces the full cryptographic configuration used for that specific message, rendered from data held in the browser during decryption. It requires no additional API calls and exposes no secrets.

// Audit panel fields (rendered client-side only)
Envelope:          v3
KEM 1:             max-secure-pure-pq   // ML-KEM-1024 + ML-DSA-87 + SLH-DSA
KEM 2:             hqc-256
AES HKDF context:  pqcrypta-share-v3-aes-wrap
HMAC HKDF context: pqcrypta-share-v3-meta-sig
Destroy HKDF ctx:  pqcrypta-share-v3-destroy
Padding block:     4096 bytes
Passphrase layer:  none | yes — verified | yes — failed
Fingerprint:       a3f9c2b1  (or — if absent)
Metadata MAC:      a1b2c3d4e5f6a1b2…   // first 16 chars + ellipsis

The audit panel is intended for developers and security-conscious users who want to verify the exact parameters used without reading the source code. All values are read from the JavaScript runtime during decryption — they reflect what actually ran, not what the documentation claims.