Security & Threat Model

Last updated: 2026-07-01

Relayium is built so that the people transferring files — not the server — hold the keys. This page describes exactly what is protected, how it works, and the limits of that protection.

The short version: in realtime mode your files never touch our servers; the encryption keys are generated fresh on each device and never leave it; and a short verification code lets two people detect a malicious server. The detail follows.

End-to-end encryption (X25519 + AES-256-GCM)

Each transfer generates a fresh, ephemeral X25519 key pair on each device. The two devices perform a key exchange to derive a shared AES-256-GCM key that exists only inside the two browsers. Every chunk is encrypted under that key with a unique nonce, so the signaling server — and any relay — only ever sees ciphertext.

Keys are ephemeral and per-transfer — nothing is reused across sessions.
The shared key is derived on the two devices; it is never sent to, or stored on, any server.
Encryption is applied at the application layer, on top of WebRTC's own transport security, so it holds even if the transport layer is compromised.

The verification code (SAS) — detecting a malicious server

WebRTC's built-in encryption (DTLS) exchanges key fingerprints through the signaling server, so a dishonest server could sit in the middle and swap keys. To catch this, Relayium derives a 6-digit Short Authentication String (SAS) from both sides' public keys and shows it on both screens. If the two codes match, no one is in the middle.

A plain 6-digit code (about 20 bits) could in principle be brute-forced by a relay racing to force a matching code. Relayium closes that gap with a commit-then-reveal handshake: each side first commits to its key by sending a hash, and only reveals the key after receiving the other side's commitment. A server therefore cannot pick a colliding key after the fact, so the short code stays trustworthy.

For the strongest guarantee, compare the code out of band — in person or over a voice call.
If the two codes differ, stop the transfer: someone may be intercepting the connection.

What the server never sees

The service is designed so that the following never reach our servers, in any mode:

In realtime mode the file bytes never touch the server at all — they flow directly between the two devices. The signaling server only relays connection-setup messages and sees room membership (your public IP), a device nickname you choose, and presence.

The contents of your files.
The names of your files.
Your encryption keys.

When your files are relayed (TURN)

When two devices cannot open a direct connection across networks (restrictive NATs or firewalls), the encrypted stream is relayed through a TURN server so the transfer can still complete. Direct peer-to-peer is always tried first; the relay is a fallback, and only pairing-code and share-link sessions are issued relay credentials.

The relay forwards only ciphertext — it cannot read your files, which stay end-to-end encrypted.
For operating the service we record only the number of relayed bytes per transfer, attributed to the signed-in user who created it.
We never inspect relayed content.

Stored download links — the key never leaves your browser

The optional download-link mode is for when the recipient is not online. Your browser encrypts the files with AES-256-GCM before anything is uploaded, and the decryption key is placed only in the URL fragment — the part after the # — which browsers never send to the server.

The server stores only ciphertext, plus the ciphertext size and timestamps for quota and cleanup — never plaintext, filenames, or keys.
Anyone with the full link can decrypt, so treat the link like the file itself and share it over a trusted channel.
Links can be set to expire (1, 3, or 7 days) or to burn after the first complete download.

File integrity (SHA-256)

Beyond confidentiality, each file's integrity is verified. Every chunk carries an AES-GCM authentication tag, and a per-file SHA-256 hash is checked end-to-end on the receiving side, so a corrupted or tampered file is detected rather than silently accepted.

What Relayium does not protect against

End-to-end encryption protects data in transit between two honest endpoints. It cannot, by design, protect against:

A compromised device or browser on either end — malware, a hostile browser extension, or someone reading the screen.
Metadata the server necessarily handles: that a transfer happened, its size and timing, and — if you signed in — the account that created it.
A recipient choosing to keep or forward the files after they have received them.
Sharing a download link over an untrusted channel, since the decryption key travels inside the link.

Browser support and its limits

Relayium runs in any modern browser with WebRTC over HTTPS. A few capabilities differ by browser:

Chrome and Edge stream large files straight to disk, with no practical memory ceiling.
Firefox and Safari buffer files in memory, so very large files (over roughly 200 MB) may fail — prefer Chrome/Edge, or use the download-link mode for those.
WebRTC requires a secure context (HTTPS); the app will not connect over plain HTTP.

Open source and reporting issues

The protocol design and all client and server code are public on GitHub, so anyone can audit the cryptography, run their own server, or contribute. If you find a security issue, please report it privately through GitHub's vulnerability reporting on the repository, rather than opening a public issue.