End-to-End Encryption vs TLS for File Transfer

A system is end-to-end encrypted when content is encrypted on the originating device under keys that only the intended recipients' devices hold, and stays encrypted through every intermediary until one of those devices decrypts it. “Intermediary” includes the operator of the service, its cloud provider, its CDN and anyone who later gains access to its servers.

Three conditions have to hold together, and marketing pages usually only talk about the first:

1. Strong encryption of the content, typically an authenticated cipher such as AES-256-GCM. This is the easy part; every competent service has it.
2. Keys generated and kept on the endpoints. If the server generates the key, stores it, or can recompute it from something it knows (a session code, a password it receives), the system is not end to end, however strong the cipher.
3. Endpoints that can authenticate each other's keys. If the server tells Alice which public key belongs to Bob and Alice cannot check, the server can hand her its own key instead and read everything. This is the hardest condition and the one most often left out.

E2EE is therefore a property of where keys live and who can vouch for them, not of an algorithm. “We use AES-256” says nothing about it.

TLS 1.3, specified in RFC 8446, is what puts the S in HTTPS. The client and server run an ephemeral (EC)DHE key exchange, the server proves its identity with a certificate for the domain name, and the records that follow are protected with an AEAD cipher (implementations must support TLS_AES_128_GCM_SHA256 and normally also offer AES-256-GCM and ChaCha20-Poly1305). Because the session keys are ephemeral, recorded traffic stays protected even if the server's certificate key leaks later (forward secrecy).

All of that protects one connection, and a connection has exactly two ends. The far end is whatever terminates TLS: often a CDN edge or load balancer, which then opens a second connection to the application. At each termination point the data exists in plaintext in memory. When you upload a file over HTTPS, TLS keeps it away from your Wi-Fi operator and ISP; it does nothing to keep it away from the service.

Why E2EE services still need TLS

End-to-end encryption protects the payload. TLS still does work that E2EE does not: it authenticates the server you are talking to, hides request paths, headers and protocol messages from the network, and stops anyone on the path from injecting content. For a web app it also protects the JavaScript that performs the encryption, which leads to an uncomfortable point covered below.

Cloud storage often adds encryption at rest on top of TLS, under keys the provider manages. That protects stolen disks, not the provider's own access; the difference is the subject of client-side vs server-side encryption.

There are two common ways two endpoints end up with a shared key that no server knows.

Key agreement between devices

Each device generates a key pair (X25519 or ECDH P-256), publishes the public half, and combines its private key with the other side's public key. Both arrive at the same secret, which a key derivation function such as HKDF-SHA256 turns into a symmetric key for AES-256-GCM. The server can carry the public keys, because public keys alone do not reveal the shared secret. Fresh key pairs per conversation or per transfer limit the damage of any single key leaking.

A random key carried out of band

The sender generates a random 256-bit key, encrypts the file, and gives the key to the recipient through a channel the server does not see. Link-sharing tools often put it in the URL fragment (the part after #), which browsers do not include in HTTP requests (RFC 3986, section 3.5). The catch is that the link itself becomes the secret: anyone who can read the message carrying it can decrypt.

Key agreement through a server has one structural weakness. If the server is malicious when two parties first exchange public keys, it can give each side a key of its own, decrypt everything in the middle and re-encrypt it for the other side. Neither side notices, because each sees a perfectly valid encrypted conversation. Every serious E2EE design answers this with one of a few techniques:

• Fingerprint comparison. Both devices display a short value derived from both public keys and the users compare it in person or over another channel. Signal calls this the safety number: 60 digits formed from two 30-digit fingerprints, also offered as a QR code. It works, and almost nobody does it.
• Trust on first use (TOFU). Accept the first key seen for a contact, remember it, and warn loudly if it changes later. SSH host keys work this way. RFC 7435 defines the term and notes the weakness: an attacker present at first contact is never detected.
• A shared secret known only to the people involved. A passphrase or code mixed into the key derivation, or used in a password-authenticated key exchange, means a server that substitutes keys cannot compute the final keys.
• Key transparency. Public, append-only logs of which key belongs to which account, so a substituted key leaves evidence that clients can audit.

E2EE removes the server's access to content. It does not make the server blind. To route anything, a service needs to know who is connected, from which IP address, and where to send the bytes. What commonly remains visible:

• Who talks to whom, and when. Accounts or session membership, connection times, IP addresses.
• Sizes. Ciphertext length tracks plaintext length closely; AES-GCM adds a fixed 16-byte tag per encrypted message. Padding can blur this, at a cost in bandwidth.
• File names and types, unless the protocol encrypts them as well. Many do not, because the recipient's interface wants to show a name before accepting.
• Everything on the endpoints. Malware on either device, a screenshot, or a recipient who forwards the file is outside the model entirely.

SRIFT is a concrete case: in a browser session the file offer carries the name, size and MIME type in plaintext to the server, while an encrypted quick-share link (--encrypt) puts the name inside the encrypted payload and leaves only the ciphertext size visible. The inventory is in what a file transfer relay can see.

The quickest test is behavioural: anything the server can do with your content tells you it can read your content. Then look for answers to the structural questions.

Questions to put to any service, including SRIFT:

1. Where is the key generated, and does it ever leave the device? A published protocol description should answer this in one sentence.
2. Can the provider recover your files if you forget your password? If yes, it holds a key or can derive one.
3. Does the server offer previews, full-text search, virus scanning or thumbnails? Those need plaintext on the server, unless they are computed on your device.
4. Can you verify the other side's key? Look for safety numbers, fingerprints, key-change warnings or a shared secret. Absence of all of them means you are trusting the server's introduction.
5. What happens on fallback? If an older client or blocked network silently downgrades to a mode the server can read, the guarantee is only as strong as that mode.
6. Is there a written threat model and readable source? A design that states what a malicious server can do is more trustworthy than one that claims it can do nothing.

For SRIFT's own answers to these questions, the encrypted file sharing page and the security architecture article list the schemes, the fallbacks and the limits.