Encrypted File Sharing With End-to-End AES-256-GCM

End-to-end encryption (E2EE) means data is encrypted on the sender's device and only decrypted on the recipient's device — nothing in between, including the service provider's own servers, holds a usable key. This is different from "encryption in transit" (which just means TLS between your browser and a server, after which the server can read the plaintext) and different again from "encryption at rest" (which means a provider encrypts files on their disks, but still controls the keys).

Every SRIFT channel is encrypted between the participants' devices. Files sent over a direct WebRTC connection are protected by WebRTC's mandatory DTLS encryption; files that go through the relay, and chat messages, are sealed with AES-256-GCM, an authenticated cipher that both hides the content and lets the recipient detect any change; audio uses DTLS-SRTP. Private keys are generated on each device (ECDH P-256 key agreement with HKDF-SHA256) and never leave it. SRIFT's servers handle public keys, ciphertext and metadata such as file names, sizes and timing; the full metadata inventory lists every item.

When a transfer happens over a direct WebRTC data channel, the DTLS encryption runs between the two participating devices and no server is in the data path. When a direct connection isn't possible and SRIFT falls back to its relay, the payload is sealed before it leaves the sender's device under a key the two devices agreed on for that one transfer, so the relay forwards ciphertext it has no key for. Chat and audio between browsers travel the same way: directly between participants, or sealed and carried by other participants or the relay when two people cannot connect. The server has no database and stores none of it.

Quick-share links

CLI quick-share links (https://srift.app/d/<token>) stream the file from the sender's machine through the relay on demand; nothing is stored on a server. Create them with --encrypt (or --password) and they are end-to-end encrypted with AES-256-GCM: the key travels in the link's #k= fragment, which browsers and HTTP clients never send to a server, and the browser (or srift get) decrypts locally. The token only routes the request. Without --encrypt, a link is protected by TLS in transit, so the relay could in principle see the bytes it forwards.

Encrypted file sharing like this is effective against a specific, well-defined set of threats: someone sniffing traffic on the network, a compromised or curious relay operator, and a service provider being compelled to hand over file contents it never received the key for.

It is not a defense against a compromised endpoint. If malware is already running on the sender's or recipient's machine, it can read the file before encryption or after decryption, regardless of how strong the transport encryption is. No file-sharing tool, encrypted or not, protects against that — it's a device security problem, not a transport problem.

It also doesn't protect against social engineering: if you send a file to the wrong session, or a recipient forwards a quick-share link to someone else, encryption does nothing to stop that, because both parties are trusted participants in the session by design. Encryption secures the pipe, not the judgment of who's allowed to be at either end of it.

Finally, the keys are introduced through SRIFT's server, and the app does not yet show a key fingerprint for participants to compare. The design therefore protects against a passive or curious server, but an actively malicious server operator could substitute keys when two devices first meet. From the CLI, a --room-secret shared out of band closes that gap. The SRIFT security architecture covers the full threat model.

Rather than transmitting a raw encryption key over the network — which would create an obvious interception point — each device generates its own key pair and shares only the public half. Two devices combine their own private key with the other's public key (ECDH on the P-256 curve) and arrive at the same shared secret without it ever crossing the network; HKDF-SHA256 turns that secret into the AES-256-GCM key. Relayed file transfers use a fresh key pair every time, so one transfer's key reveals nothing about any other.

An optional room secret (CLI/SDK --room-secret / roomSecret) is mixed into every key as a shared password: someone who is admitted to the session without knowing it still cannot read anything. Clients older than version 4.2 fall back to a key derived from the session code with PBKDF2-SHA256, which the server could reproduce, so keep every participant updated.

Plenty of cloud storage providers advertise "encryption" while retaining full ability to decrypt user files on their own servers — useful for features like search or preview, but it means the provider (and anyone who compels them) can read your files. Genuine end-to-end encryption trades away some of that convenience (no server-side preview generation, no server-side search inside files) in exchange for the provider not holding the key (fully true when a room secret is set).