End-to-end encryption

How Terashare protects your files — and why it stays safe even when we don't.

What we mean by end-to-end encrypted

Every file you share through Terashare is encrypted on your device before it leaves the browser. The server, our cloud-storage tier, and the peer-to-peer swarm only ever see scrambled bytes. The decryption key never reaches our servers — it travels in the URL fragment of the share link, which browsers never send over the network.

This is not a marketing claim layered on top of a normal upload. It is the design. There is no path in the codebase that lets the server look at a plaintext file or a plaintext key. If we wanted to read your files, we would have to ship new code — and you would have to download it — and a third-party audit could spot it. That is a different threat model from "the server promises not to look."

What we encrypt with

Primitive	Purpose	Why this one
`AES-256-GCM`	File contents + every wrapped key	Authenticated symmetric cipher: tampering with any byte makes decryption fail loudly. Same cipher used by HTTPS, banks, and disk encryption.
`Argon2id` (opslimit=2, memlimit=64 MiB — libsodium INTERACTIVE)	Turn your login password into a key-encryption key	Memory-hard password hashing — the same profile Bitwarden's web vault uses. Roughly 1000× more expensive per guess on GPU/ASIC offline attacks than a comparable PBKDF2 setup. The algorithm + parameters are recorded alongside your vault so we can tune the cost (or swap the KDF entirely) without breaking existing vaults.
`crypto.getRandomValues`	Every key, every nonce, every salt	The browser's CSPRNG, audited and FIPS-aligned. We never generate keys server-side.
`TSE2` container	File-level wire format	A small, versioned binary format that aligns each encrypted piece with the WebTorrent piece boundary. Piece 0 holds an encrypted header slot (filename, size, base nonce); every other piece is decryptable independently as soon as it arrives over the swarm — so the recipient can start writing plaintext to disk while the rest of the file is still downloading. The piece index is bound into the GCM AAD, so reordering or splicing pieces fails authentication.

What we don't use: RSA, ECDH, Diffie-Hellman, or any other public-key crypto for key exchange. Every encryption operation in Terashare is symmetric. That matters in the next section.

Why this stays safe in a post-quantum world

Most "end-to-end encrypted" file-sharing tools rely on RSA or elliptic curves to exchange a key between sender and recipient. The day a large quantum computer arrives, Shor's algorithm breaks both — retroactively. Ciphertext recorded today decrypts then.

Terashare does no asymmetric key exchange. The key travels in the URL fragment itself; the sender and recipient share it over whatever channel they already trust (email, chat, SMS). The only quantum attack on AES-256 is Grover's algorithm, which only halves the effective key size — 256 bits becomes ~128 bits of post-quantum security, which is still beyond reach of any plausible attacker for the foreseeable future.

So files you share through Terashare today stay confidential even decades from now, regardless of what quantum computers eventually do.

Your personal key vault

One question every E2EE file-sharing tool eventually faces: "If only the recipient and I have the key, what happens when I want to re-share a file later and I've lost the link?" The naive answer is "you can't." Our answer is a per-user key vault.

The vault uses a three-tier envelope encryption hierarchy:

your login password
   │ Argon2id(opslimit=2, 64 MiB, per-user salt)
   ▼
   KEK ──── wraps ────▶ MK (random master secret)
                          │
                          │ wraps every per-file DEK
                          ▼
                       DEK_1, DEK_2, DEK_3, ...
   ▲
   │ also wraps MK ◀──── recovery key (one-time, shown once at signup)

Your password is stretched into a Key-Encryption Key (KEK) — entirely in your browser, never sent anywhere.
A random master secret (MK) is wrapped by the KEK and independently by a one-time recovery key. The server stores both ciphertexts. It has no way to unwrap either without your password or the recovery key.
Each file's key (DEK) is wrapped by MK and stored alongside the share. The recipient's copy still rides in the URL fragment — but yours lives in your vault, so you can rebuild the link any time you log in.

Why three tiers?

Password rotation is O(1). If you change your login password we only re-wrap MK under a new KEK. Per-file keys and file ciphertext are untouched, no matter how many files you've shared.
The recovery key is a separate envelope, not the same secret as MK. We never see it — it's generated in your browser, shown to you once at signup, and discarded. You can copy it, download it as a text file, store it in a password manager, or print it on paper. If you lose your login password, the recovery key reconstructs MK; without it, the vault is genuinely unrecoverable (so don't lose both).
Lose everything? Files are still recoverable. Anyone who saved a share link — including you — can still decrypt the file via the key in the URL. Vault access ≠ file access.

Where you've seen this pattern before

This is the same envelope-encryption hierarchy used by the major end-to-end-encrypted password managers and backup systems. The closest written-down reference for the model we use is Bitwarden's security whitepaper , which walks through password → stretched key → wraps a long-lived User Key → wraps per-item keys. 1Password, Proton, WhatsApp E2E backups, and iCloud Advanced Data Protection all use the same shape.

If you trust those products to protect your passwords or your iCloud backups, you can trust the same cryptographic structure to protect your file shares.

What a Terashare breach would actually leak

A useful test for any privacy claim: ask what an attacker who fully compromised the company would see.

An attacker who steals our database sees…	…and can do what with it?
Filename, size, share URL, magnet link, owner	Metadata only. Useful for routing the share, useless for reading it.
Wrapped DEK (per share) + wrapped MK (per user)	Both are ciphertext. Without your password or your recovery key, neither one is decryptable.
File ciphertext on cloud / WebTorrent swarm	Looks like uniform random noise. Without the DEK there is no faster-than-brute-force way to read it.
Your password, recovery key, MK, DEKs	None of these ever reach the server, so they are not in the breach.

How to verify all of this yourself

Read the code that runs in your browser. The cryptography lives in two short, standalone JavaScript modules — file format and vault — built on the browser's WebCrypto API plus the well-audited libsodium.js (sumo build, vendored verbatim) for Argon2id. They are served to every visitor — open DevTools → Sources to read them:
- js/services/e2ee.js — file format, encrypt, decrypt, piece handling
- js/services/e2ee-vault.js — vault: Argon2id, wrap, unwrap, rotation, recovery
Watch the network tab. Open DevTools, share an encrypted file, and confirm that the bytes hitting the wire do not match your file's content — and that the URL fragment (the part after #) is never sent in a request.
Look at the tests. The browser-side crypto round trips and the vault unlock paths are covered by Selenium tests that run real WebCrypto in a real Chrome.

Share something encrypted How sharing works