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).

Srift's file transfers and chat messages are encrypted with AES-256-GCM, an authenticated cipher that both scrambles the content and lets the recipient detect if it was altered in transit. Keys are derived on-device using PBKDF2-SHA256 with a high iteration count from the session credentials — they are never transmitted to Srift's infrastructure in a usable form.

When a transfer happens over a direct WebRTC data channel, encryption/decryption happens purely on the two participating devices — there's no server in the data path at all. When a direct connection isn't possible and Srift falls back to a WebSocket relay or WebTorrent-style transfer, the payload is still encrypted before it leaves the sender's device. The relay forwards ciphertext it cannot read; it has no key material.

Quick-share links

The same principle applies to asynchronous quick-share links (https://srift.app/d/<token>). The token authorizes access to a specific ciphertext blob; it is not itself the decryption key embedded in plaintext form on a public server.

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 had the keys to decrypt in the first place.

It is nota 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.

Rather than transmitting a raw encryption key over the network — which would create an obvious interception point — Srift derives the session key locally on each device using PBKDF2-SHA256 with a high iteration count, based on shared session credentials established when the session is created and joined. Both sides independently compute the same key from the same inputs; the key itself never needs to cross the network in a usable form.

Iterated key derivation functions like PBKDF2 exist specifically to make brute-force guessing computationally expensive: an attacker who intercepts the ciphertext still has to run the same expensive derivation for every guess at the underlying credential, which is deliberately slow by design.

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 mathematically not being able to read the payload.