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
Most cloud services store your file, index it, preview 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 — 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 to the relay returns: encrypted bytes, no key, no plaintext, 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 transmitted 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, for exactly one opening. Once the recipient downloads it, the relay zeroes the memory slot. There is no second copy to retrieve.
#key=…. File appears in the browser.If you forward a link that still works, you forwarded the secret. 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.
Verifiable history
Every transfer event is appended to a Merkle tree. The root fingerprint is published. Changing any historical entry would change the root — which is publicly visible and tamper-evident.
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 center. No CDN caching your files. No US entity in the chain.
GDPR · DSGVO
no US entity
no disk, no CDN
Verified transfer
Every Paramant transfer is account-bound and end-to-end encrypted in the browser. ParaShare 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 ParaShare |
|---|---|
| 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 |
| Proof of origin | CT log entry, verifiable by recipient |
| Post-quantum safe | Yes, ML-KEM-768 defeats 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 WebApp tools (ParaShare). Each surface is at a different stage of the wire-format-v1 migration. Here is the honest state today.
| Component | What it does | Crypto today |
|---|---|---|
| Relay | Node.js, Hetzner Nuremberg. Validates inbound v1 blobs, advertises 3 KEMs and 18 signatures via /v2/capabilities, rejects unsupported algorithm IDs with HTTP 415. |
Wire format v1. Full NIST suite (FIPS 203, 204, 205, 206) loaded. |
| 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. |
| ParaShare (webapp) | 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. | Currently uses a server-side encryption path: the relay performs encryption with a per-blob key. Client-side ML-KEM crypto is staged in the codebase but not yet wired up. |
| Outlook add-in | Encrypts attachments inside Outlook before send. | Uploads attachment bytes to the relay, which performs encryption server-side. Migration to client-side hybrid crypto is in progress. |
The relay never sees plaintext for SDK and WebApp transfers. The two extensions currently take a server-side path while their client-side crypto is finished — that is called out openly here rather than papered over. See crypto-agility § 06 for the per-client wire format and migration table.
Want the 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 →