How Paramant works.
Shown, not told.
A plain-language walkthrough of every step: how your file is encrypted, how it travels, why the relay cannot read it, and what happens when the link is opened. For the cryptographic specification, see the security page.
The flow
Four stages. The key never leaves the browsers. The relay only ever sees ciphertext it cannot read.
The key only exists in browsers. The relay receives ciphertext, holds it in RAM, and forwards it. It has no key and cannot read the file. A fully compromised relay sees nothing useful.
What we see
Many cloud services store your file, index it and make previews of it. Paramant's relay sits in the middle and sees almost nothing. Here is the difference.
Typical cloud storage
- Readable file contents (stored in plaintext or decryptable by the provider)
- Filename and metadata logged
- Preview thumbnail generated server-side
- Written to disk: survives restarts, subpoenas, breaches
- Access logs tied to content
- Subject to legal disclosure orders
Paramant relay
- Ciphertext only: we cannot read it
- No filename, no metadata
- No preview possible: opaque bytes
- RAM only: a relay restart destroys everything
- Nothing to disclose: we hold no plaintext
- GDPR jurisdiction, no US CLOUD Act
Legal disclosure is structurally impossible. We cannot hand over what we do not have. A court order served on the relay gets encrypted bytes, no key, no plaintext and no filename.
The # in the link
Every Paramant link is split in two. The left half goes to the relay. The right half (the part after #) never leaves your browser. This is not a Paramant policy. It is how browsers work.
The path /r/a8f3c92d identifies which blob to retrieve. The relay sees this and serves the matching ciphertext.
The fragment #key=… is the decryption key. Browsers strip the fragment before making any network request. It is never sent to any server, including ours.
This is a browser standard, not a trust promise. RFC 3986 specifies that URL fragments are client-only. Even if Paramant wanted to log the key, the browser would never send it. The relay structurally cannot intercept it.
Burn on read
The ciphertext exists exactly once, and the relay zeroes the memory slot after the last read the link allows: one on Community, up to 10 on Firm and 100 on Enterprise. There is no second copy to retrieve.
#key=…. The file appears in the browser.If you forward a link that still works, you forwarded the secret. On the Community plan burn-on-read is a single-use guarantee: once the link is opened it is gone, for the recipient and for anyone who intercepts a copy of the URL. A paid link is gone after the last read it allows, up to 10 reads on Firm.
Verifiable history
Every transfer event is appended to a Merkle tree. The root fingerprint is published. Changing any historical entry would change the root, and that change is publicly visible.
The root fingerprints the whole tree. Edit any leaf event, even by one byte, and the root hash changes. Because the root is published in the CT log, any retroactive tampering is immediately detectable. This is the same principle used by certificate transparency in TLS.
Where it runs
One jurisdiction. One data centre. No CDN caching your files. No US entity stores ciphertext. The one American sub-processor, Resend, sends the email under Standard Contractual Clauses, and that email sometimes carries key material: for a send to named recipients the link with the token and, in a second email, the pickup code, which together open the file; for a signing invite half of the document key. The CLOUD Act can reach that.
GDPR · DSGVO
it does reach email via Resend (US)
no disk, no CDN
Verified transfer
Every Paramant transfer is account-bound and encrypted in the browser. It is end-to-end, with no way for the relay to see a key, for a one-time link and for Together; in a send to named recipients the token that unwraps the key passes through the relay once so it can be emailed (the exception). The ParaSend web app adds post-quantum key exchange, ML-DSA-65 sender signatures, and CT-log proof of origin. There is no anonymous or lower-assurance tier.
| Property | Verified web app |
|---|---|
| Account needed | Yes |
| Encryption | Hybrid ML-KEM-768 + ECDH P-256, then AES-256-GCM |
| Sender signature | ML-DSA-65, mathematically tied to sender identity |
| Reads allowed | One, burned on first open (the web app never asks for more) |
| Proof of origin | CT log entry, verifiable by recipient |
| Post-quantum safe | Yes, ML-KEM-768 protects against harvest-now-decrypt-later (HNDL) attacks |
| Good for | Legal, healthcare, financial, compliance workflows |
Components
The relay is one piece. Around it sit official SDKs, two browser extensions, and the ParaSend web app. Each surface is at a different stage of the wire-format-v1 migration. This is where each one stands today.
| Component | What it does | Crypto today |
|---|---|---|
| Relay | Node.js, Hetzner Nuremberg. Validates inbound v1 blobs, advertises through /v2/capabilities the algorithms it has actually loaded, and rejects every other algorithm ID with HTTP 415. |
Wire format v1. 3 KEMs and 17 signatures ship in the image; the default core mode loads two of them, ML-KEM-768 and ML-DSA-65, and those are the two the endpoint answers. |
| sdk-py 3.0.0 | Python SDK. Default ML-KEM-768 + ML-DSA-65. Negotiates via the capabilities endpoint. Live on PyPI: pip install paramant-sdk. |
Real post-quantum (pqcrypto). Produces v1 blobs. |
| sdk-js 3.0.0 | JavaScript / Node SDK. Same defaults and negotiation as the Python SDK. Live on npm: npm install paramant-sdk. |
Real post-quantum (@noble/post-quantum). Produces v1 blobs. |
| ParaSend web app | Verified, authenticated transfers from the browser. | Hybrid ML-KEM-768 + ECDH P-256 + AES-256-GCM via WASM, client-side. Pre-v1 blob layout. Migration to v1 in progress. |
| Chromium extension | Right-click upload from any tab. | Encrypts on your own machine, but with AES-256-GCM from Web Crypto and the key in the URL fragment, not with the ML-KEM hybrid. No key exchange, so no binding to a named recipient. A staged ML-KEM module sits in the codebase unused. |
| Outlook add-in | Encrypts attachments inside Outlook before send. | Same path as the Chromium extension: AES-256-GCM in the add-in, key in the URL fragment, no key exchange. Migration to the ML-KEM hybrid is not done. |
The relay never sees plaintext, except in the hosted signing ceremony on the /v1 API. Every client on this table encrypts before it uploads, the two extensions included. The ceremony is not a client on this table: there the relay is handed the PDF itself, because running the ceremony is what that request asked it to do. What differs is the key exchange: the SDKs and the web app bind the file to a recipient's public key, while the extensions and the browser-encrypted link put a symmetric key in the URL fragment and bind it to nobody. Anyone holding that link can open the file, so the channel you send it over is the security. See crypto-agility § 06 for the per-client wire format and migration table.
The full cryptographic specification
The security page covers every algorithm, the independent audit results, key verification layers, authentication model, and responsible disclosure. Written for cryptographers and security engineers.
Read the security spec →