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
Two modes
Paramant has two transfer modes. Anonymous one-shot sending requires no account. Verified ParaShare adds identity, post-quantum key exchange, and cryptographic proof of origin.
| Feature | Anonymous Send a file |
Verified ParaShare |
|---|---|---|
| Account needed | No | Yes |
| Encryption | AES-256-GCM, browser-generated key in URL fragment | Hybrid ML-KEM-768 + ECDH P-256, then AES-256-GCM |
| Sender signature | None | ML-DSA-65 — mathematically tied to sender identity |
| Reads allowed | One — burned on first open | One — burned on first open |
| Proof of origin | None | Yes — CT log entry, verifiable by recipient |
| Post-quantum safe | No (classical AES key exchange) | Yes — ML-KEM-768 defeats HNDL attacks |
| Good for | Quick one-off shares, no signup friction | Legal, healthcare, financial, compliance workflows |
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 →