Last updated: 2026-07-09
"Is Relayium secure?" is a fair question — every file-transfer tool claims to be private. This page walks through exactly how Relayium keeps files private, in plain language, so you can judge the claim instead of taking it on faith.
There are two different encryption schemes at work, because there are two different situations: sending a file live to someone who is online right now, and leaving a download link for someone to pick up later. Both keep the server locked out of your file, but they get there in different ways — and it's worth knowing which one applies when.
When you send a file in realtime — both people online, browser to browser — Relayium starts by having each device generate a fresh key pair using X25519, the same elliptic-curve key exchange used across modern secure messaging (technically, libsodium's crypto_kx). Each device keeps its private key to itself and sends only its public key to the other side.
From those two public keys, each device independently computes the same shared secret — a process that works precisely because of how elliptic-curve key exchange is built, not because the secret was sent anywhere. That shared secret becomes an AES-256-GCM key that exists only inside the two browsers. Every chunk of the file is sealed with that key and a unique nonce before it ever leaves the sender's device, so anything crossing the network — including the signaling server that helped the two browsers find each other — sees only ciphertext.
There's a subtlety worth being honest about. WebRTC's own built-in encryption (DTLS) exchanges key fingerprints through the signaling server that introduces the two devices to each other. If that server were dishonest, it could in theory sit in the middle and swap in its own keys — a classic man-in-the-middle attack — without either browser immediately noticing.
Relayium closes that gap with a short verification code. Both devices derive the same 6-digit Short Authentication String (SAS) from their two public keys and display it on screen. If the codes match, the keys weren't swapped, and no one is in the middle. But a plain 6-digit code is only about 20 bits, which in principle a well-positioned attacker could try to brute-force into matching after seeing both real keys. To prevent that, Relayium uses a commit-then-reveal handshake: each side first sends a hash committing to its key, and only reveals the real key after receiving the other side's commitment. That ordering means a malicious server has to commit to a fake key blind, before it has seen the real one — it cannot pick a colliding key after the fact, so the short code stays trustworthy.
Encryption protects secrecy, but it doesn't automatically prove nothing got corrupted or tampered with along the way. Relayium checks that separately: each chunk carries its own AES-GCM authentication tag, so a modified chunk fails to decrypt outright. On top of that, as each file is sent, both sides compute a running SHA-256 hash over its plaintext contents; when the file finishes, the sender's hash is compared against the receiver's. If they match, what landed on disk is byte-for-byte what was sent — if they don't, the file is flagged rather than silently accepted.
Realtime transfer needs both people online at the same time. When that's not possible, Relayium offers a stored download link instead — and this uses a genuinely different mechanism, worth not confusing with the realtime one above.
There's no key exchange here, because there's no second device to exchange with yet. Instead, your browser generates a single random AES-256-GCM key and uses it to encrypt the files before anything is uploaded. That key is never sent to the server at all — it's appended to the download link after a # character, in what's called the URL fragment, a part of the address that browsers deliberately never transmit to a server. The server ends up storing only ciphertext it has no way to decrypt, plus bookkeeping like the ciphertext's size and an expiry timestamp. Anyone who opens the full link — fragment included — can decrypt the file locally in their browser; anyone without it just sees an opaque blob on the server. That's the zero-knowledge part: the server holds the encrypted file without ever holding the means to read it.
It's worth spelling out exactly where the server sits in all of this, because "end-to-end encrypted" is a claim that's easy to make and harder to make precisely. In realtime mode, the file itself never touches Relayium's servers at all — it streams directly between the two browsers. The signaling server's job is limited to relaying connection-setup messages (the technical SDP/ICE information WebRTC needs to establish a direct link) so the two devices can find each other; it never sees file contents, filenames, or keys.
When a direct connection isn't possible — both sides behind restrictive NATs or firewalls — the encrypted stream falls back to a TURN relay server instead of failing outright. The relay only ever forwards ciphertext; it has no key and cannot decrypt what passes through it. What it does do is count the bytes it relays against the sending account's monthly relay allowance, purely for metering and abuse prevention — never inspecting what's inside.
No. In realtime mode, the encryption key is derived independently on both devices and never leaves them — Relayium's servers never see it or the file contents. For stored links, the key lives only in the URL fragment, which browsers never send to any server, so the server only ever holds ciphertext it cannot decrypt.
In realtime mode, only the connection-setup information needed to introduce two devices to each other — never file bytes. For stored links, it sees ciphertext plus bookkeeping like size and expiry time — never the plaintext, filenames, or the decryption key.
It's a fallback used only when a direct connection isn't possible, and it only ever handles ciphertext — it has no key, so it can't read what it's relaying. Relayium counts the bytes it relays against your account's monthly allowance, but never inspects their contents.
Yes. The protocol design and all client and server code are public on GitHub under the MIT license, so the cryptography described here can be independently audited rather than taken on trust.
Stop the transfer. A mismatch means the commit-then-reveal check failed, which points to a possible man-in-the-middle rather than a benign glitch — don't proceed until you understand why.
Curious what it looks like in practice? Start a transfer and watch the verification code appear for yourself.
Try Relayium now