POST-QUANTUM·EU SOVEREIGN·ZERO-KNOWLEDGE

File transfer without the file storage.

Files burn after one read. Use the relay, or run your own.

SENDMove a file securely.

A free account tracks your sends, keeps them longer, and lets you send more per month. Or drop one file anonymously in 30 seconds.

▸No password — TOTP only
▸Burns after read, or on timer
▸AES-256-GCM in-browser

BUILDRun the relay yourself, or build on the API.

Self-hosters on Raspberry Pi. OT teams deploying sector-isolated relays. Blockchain nodes needing ciphertext passthrough. Developers integrating encrypted transfer into their own products.

▸BUSL-1.1 source
▸docker compose up -d
▸NIS2, IEC 62443, NEN 7510

01How it works

Four steps. Nothing stored.

Encrypt client-side

In your browser. Relay never sees plaintext.

Transit via Ghost Pipe

Padded to 5 MB, hashed into the CT log.

One-time download

Recipient decrypts locally. Blob erased from RAM.

Cryptographic proof

Merkle root updated. Delivery proven.

Sender → Ghost Pipe Relay → Receiver

  ┌───────────────────┐        ┌───────────────────────────┐        ┌───────────────────┐
  │ file.pdf          │        │ RAM only — no disk writes │        │ file.pdf          │
  │                   │        │ burn-on-read              │        │       ▲           │
  │         │         │        │ 5 MB fixed padding        │        │       │           │
  │         ▼         │        │ hash → Merkle CT log      │        │       │           │
  │ encrypt(ML-KEM)   │  ───►  │     blob destroyed        │  ────► │ decrypt(ML-KEM)   │
  │ X-Api-Key header  │        │     on read               │        │ X-Api-Key header  │
  └───────────────────┘        └───────────────────────────┘        └───────────────────┘

What the relay never sees

plaintext · encryption keys · filenames · recipient identity

What the relay does see

fixed-size 5 MB ciphertext blobs · blob hashes · API key identifiers

02Cryptography

Under the hood.

Anonymous one-off

AES-256-GCM

Browser-generated key in URL fragment — never sent to relay. Prove-by-design that we cannot decrypt what we relay.

· key in URL fragment (never sent)

· 12-word mnemonic as fallback verifier

· NIST SP 800-38D compliant AEAD

Verified end-to-end

ML-KEM-768 + ECDH P-256

Post-quantum hybrid key exchange. FIPS 203. ML-DSA-65 signed receipts (FIPS 204). All math client-side.

· FIPS 203 — ML-KEM-768 (Kyber)

· FIPS 204 — ML-DSA-65 (Dilithium)

· HKDF-SHA256 · AAD-bound algorithm IDs

The relay loads 3 KEMs and 18 signatures from FIPS 203, 204, 205, and 206. Clients pick, the relay validates against the live registry, unsupported algorithms get HTTP 415. The official SDKs produce wire format v1 today.

Full cryptography spec →

03CT log

Verifiable.

LiveView all →

CT log unavailable — relay offline or starting

Every transfer hashed into a Merkle tree. Content never stored.

03.5Authentication

No passwords. Ever.

Paramant has no login form. No username. No password to phish, steal, or breach. Authentication is a cryptographic key and an optional TOTP code — nothing else.

01 — API key

64-char hex secret

Generated once on account creation. Shown once. Store it in your password manager or secret vault. Rotate instantly if compromised.

02 — TOTP

Authenticator app

RFC 6238, SHA-256, 30-second codes. Works with Aegis, Authy, 1Password. Each code is single-use — replay attacks have no window.

03 — No password

Zero credential surface

Credential stuffing, dictionary attacks, and phishing require a password to target. With no password those attack vectors don't exist.

04Self-host

Run your own relay.

Source-available under BUSL-1.1. Free for up to 5 users. Works on a Raspberry Pi. If the managed service ever closes, every self-hosted relay keeps running indefinitely.

$ curl -fsSL https://paramant.yoursafetynet.tech/install.sh | bash

$ docker compose up -d

05Overview