Security

We treat security as infrastructure, not a feature. Every component is designed assuming the relay is compromised. This page documents how, what was audited, and how to report issues.

Core principle

The relay is an untrusted intermediary. It stores only ciphertext and has no access to keys or plaintext. A fully compromised relay cannot read, forge, or retroactively recover any transfer. This is not a policy — it is a cryptographic guarantee.

Independent security audit — April 2026

Ryan Williams · Smart Cyber Solutions Pty Ltd (AU)

Uncompensated · voluntary · completed April 8, 2026

Full audit on GitHub →

Critical — patched

High — patched

Medium — patched

Low — patched

All critical, high, and medium findings were patched before the v2.4.1 public release. The full report, including finding descriptions and patch evidence, is available on GitHub.

Patch timeline

2026-04-08

Pentest completed

Ryan Williams delivers findings report. All critical + high confirmed.

2026-04-09

v2.4.1 — All critical/high/medium patched

Key zeroization (C3), plaintext filename in metadata (C4), ML-DSA-65 relay identity, CT log tamper protection.

2026-04-11

v2.4.2 — Relay registry + ParamantOS installer

ML-DSA-65 signed relay registration, CT log relay entries, verified_since continuity proof. ParamantOS disk installer with pre-flight checks.

Ongoing

Next audit planned

We aim for an annual external review. Contact privacy@paramant.app to discuss.

Cryptography

All algorithms are from NIST post-quantum standards (FIPS 203/204) or established symmetric primitives. Nothing custom. No proprietary key exchange.

Algorithm	Role	Standard
ML-KEM-768	Key encapsulation — post-quantum KEM	NIST FIPS 203
ECDH P-256	Classical key exchange (hybrid)	NIST SP 800-56A
HKDF-SHA256	Key derivation from shared secrets	RFC 5869
AES-256-GCM	Symmetric encryption + authentication	NIST SP 800-38D
ML-DSA-65	Digital signatures — relay identity	NIST FIPS 204
Argon2id	Password-based blob encryption	RFC 9106
SHA3-256	CT log Merkle hashing	NIST FIPS 202

Hybrid key exchange

Every transfer uses ML-KEM-768 and ECDH P-256 simultaneously. The shared secret is the concatenation of both — breaking one provides no advantage. This protects against store-now-decrypt-later attacks while maintaining compatibility with classical infrastructure.

Pre-shared secret (PSS)

An optional out-of-band password added to HKDF input. Even a fully compromised relay cannot decrypt PSS-protected transfers — the relay would need to serve the correct ciphertext and know the PSS. Recommended for healthcare and legal workflows.

Relay architecture

RAM-only storage

Encrypted blobs are stored in process memory, never written to disk. A relay restart destroys all blobs. No database, no filesystem writes.

Burn-on-read

Each blob is destroyed after the first successful download. Memory is zeroed immediately. There is no second chance to retrieve it.

5 MB padding

All uploads are padded to a fixed 5 MB block. A passive observer sees identical-size ciphertext for every transfer — no size inference, no DPI correlation.

ML-DSA-65 relay identity

Each relay generates a post-quantum signing keypair on first boot. Registrations are signed and logged in the CT chain — verified_since proves continuous identity.

What a compromised relay cannot do

✓Read file contents — relay holds only ciphertext, never keys

✓Substitute a registered public key (after TOFU or PSS is used)

✓Decrypt any stored ciphertext — no key access

✓Identify file size — all transfers look identical (5 MB padding)

✓Recover burned blobs — memory is zeroed immediately on download

✓Forge CT log entries — Merkle chain is append-only and tamper-evident

✓Break ML-KEM-768 — NIST FIPS 203, post-quantum secure

Four-layer key verification

The relay distributes public keys. An attacker who controls the relay could serve wrong keys. These four layers prevent that:

Layer	Mechanism	Protects against
1 — TOFU	First-use fingerprint stored locally. Every subsequent fetch must match.	Key swap after first contact
2 — Out-of-band	Both parties compute the same SHA-256 fingerprint and compare via phone/Signal/QR.	Relay MITM on first contact
3 — PSS	Pre-shared secret mixed into HKDF. Wrong key = undecryptable ciphertext.	Relay MITM at any time
4 — CT log + ML-DSA-65	Key registrations are signed and logged in Merkle chain. Retroactive injection is impossible.	Key injection, timestamp fraud

Jurisdiction & privacy

Server location	Hetzner Frankfurt, Germany
Legal jurisdiction	EU / Germany (GDPR)
US CLOUD Act	Not applicable — no US infrastructure, no US company
Data retained	No plaintext, no keys. Only: transfer hash, creation timestamp, approximate encrypted size (always 5 MB), view count. Deleted on burn.
IP logging	Nginx access logs. Not linked to transfer content. Retention: 7 days.
Analytics	None. No third-party scripts on the relay or API.

Responsible disclosure

We take vulnerability reports seriously. If you find a security issue, please do not open a public GitHub issue.

Email: privacy@paramant.app

AcknowledgementWithin 48 hours

Status updateWithin 7 days

Disclosure window90 days (coordinated)

Scoperelay.js, SDK, frontend, ParamantOS, CT log

ParamantOS

The official installer image for self-hosted relay deployments. Hardened NixOS with the relay pre-installed.

Component	Configuration
SSH KEX	mlkem768x25519-sha256 + curve25519 — ML-KEM FIPS 203
SSH host key	Ed25519 only — no RSA, no ECDSA
SSH auth	Public key only — no passwords, no GSSAPI, no forwarding
Kernel	unprivileged_bpf_disabled=1, kptr_restrict=2, bpf_jit_harden=2
Firewall	Ports 22 + 3000–3004 only
Service isolation	Dedicated system user, systemd NoNewPrivileges, ProtectSystem=strict
CVEs mitigated	CVE-2023-51767, CVE-2025-26465, CVE-2025-26466, CVE-2025-32728

ParamantOS on GitHub →