The one-sentence version
Your files and clipboard are encrypted on your device with keys that only your devices ever hold; our relay only stores ciphertext it has no way to open — even if the relay itself were seized or compromised.
What “end-to-end” means here, concretely
Encryption and decryption happen on the endpoints — your devices. The server in the middle (we call it the relay) receives bytes that are already encrypted and forwards or briefly stores them. It is never given a key, so it cannot read your data, and neither can anyone who later gets hold of the relay or its disks.
What is — and isn’t — end-to-end encrypted
We’d rather you trust us because we’re precise than because we wave the word “encrypted” around. So, plainly:
| Path | End-to-end? | How |
|---|---|---|
| Synced folders | Yes | File contents encrypted on-device before upload (AES-256-GCM, framed streaming). |
| Clipboard sync | Yes | Each clipboard item sealed on-device under your account key. |
| Browser share-links | No* | The recipient opens the file in a browser with no app and no key, so the relay must serve something the browser can read. Encrypted in transit (TLS) and at rest on the relay, then deleted after download — but not end-to-end. |
* If you need true end-to-end for something, send it through a synced folder to a device, not as a browser link. We label this honestly in the app and here.
The building blocks
Everything below is built on standard, vetted platform cryptography (.NET’s AesGcm, ECDiffieHellman, and HKDF). There is no home-grown cipher, no custom curve, no hand-rolled key schedule. The raw key-agreement secret is never used as a key directly — it always passes through HKDF first.
| Purpose | Primitive |
|---|---|
| Bulk content encryption | AES-256-GCM (256-bit keys, 96-bit nonces, 128-bit auth tags) |
| Large files | Framed streaming AEAD (STREAM construction, in the spirit of age / libsodium secretstream) |
| Device identity | Static ECDH key pair on NIST P-256 |
| Key distribution | Static-ephemeral ECDH → HKDF-SHA256 → AES-256-GCM key-wrap (a “sealed envelope”) |
| Key storage | OS secure store — Windows DPAPI, macOS Keychain, Linux Secret Service |
How a file is encrypted
A multi-gigabyte file can’t be safely encrypted as one giant block — you’d have to hold all of it in memory and you couldn’t verify integrity until the very last byte. So TetherBay encrypts a file as a sequence of independent 1 MiB frames, each with its own fresh random nonce and authentication tag:
[magic "TBE1"][version][alg][frame size]
per frame: [nonce 12B][isLast][len][ciphertext][tag 16B]- Every frame gets a fresh random nonce, so a key+nonce pair is never reused.
- Each frame’s authenticated data binds it to its folder, object, position in the file, and whether it’s the last frame. That means tampering, truncating, reordering, or splicing frames — or moving an encrypted blob to a different file or folder — fails the integrity check on decryption rather than silently producing wrong data.
- The
TBE1marker lets a device tell an encrypted object from a legacy plaintext one during a rollout, so reading never breaks.
Clipboard items are small, so they use the same cipher in a single-shot form (marker TBC1), each sealed under your account key and bound to its account and event id.
How the keys reach your devices — without the server seeing them
Encryption is only as good as key handling. The hard part is getting the symmetric content key from a device that has it to your other device, through a server you don’t want to trust. TetherBay does this with sealed envelopes:
- Every device generates a P-256 key pair on first run. The private half is written to the OS secure store and never leaves the device — not to the server, not to logs, not to an environment variable. Only the public half is registered with the relay.
- To share a folder key with another of your devices, the sending device does an ephemeral ECDH against that device’s public key, runs the result through HKDF-SHA256 to derive a one-time wrapping key, and AES-256-GCM-wraps the content key under it.
- The relay stores this sealed envelope and hands it to the recipient device. Only the device holding the matching private key can re-derive the wrapping key and open it. The relay sees an opaque blob.
shared = ECDH(ephemeral_private, recipient_public)
wrapKey = HKDF-SHA256(shared, salt = folderId, info = "tetherbay-folder-key-e2e-v1")
envelope = AES-256-GCM(wrapKey).seal(folderKey,
bound to: folderId, key version, ephemeral pubkey, recipient device id)Each wrap uses a fresh ephemeral key pair (so wrapping keys never repeat), folder and account channels use different HKDF labels so their envelopes can never be confused, and the recipient device id is bound in — so if the server ever misrouted an envelope to the wrong device, it would fail to open rather than leak.
Fail-closed by design
Encryption never silently downgrades
Once a folder is end-to-end encrypted, a device will encrypt the upload or hold it — it will never fall back to sending plaintext. If for any reason a device couldn’t encrypt (say it didn’t yet hold the folder key), the file waits rather than leaking to the relay in the clear. The only way you get a plaintext blob is a folder that was never encrypted to begin with.
What the relay can — and can’t — see
End-to-end encryption protects contents. It does not make a relay omniscient-proof about metadata. Being honest about that is part of the point:
The relay never sees
- × Your file contents
- × Your clipboard contents
- × Your encryption keys
- × File names or folder contents (inside the encrypted blob)
The relay does see (metadata)
- · Approximate size of each transfer (ciphertext length)
- · Which account/folder/device, and when
- · Delivery status and device presence
- · Each device’s public key
If hiding the existence and timing of a transfer from the infrastructure is part of your threat model, no relay-based tool — ours included — fully solves that. What we guarantee is that the content stays yours.
Honest limitations
Browser share-links are not end-to-end (explained above). Metadata is visible to the relay. And like any client software, end-to-end encryption protects you in transit and at rest on our infrastructure — it does not protect a device that is itself compromised. We’ll keep this page updated as the design evolves, and we welcome scrutiny.
Want to verify, not trust?
Good instinct. The format markers (TBE1 for files, TBC1 for clipboard), the AES-256-GCM / P-256 / HKDF-SHA256 choices, and the sealed-envelope construction above are the whole story — there is no secret second channel. If you’re evaluating TetherBay for sensitive use and want the deeper design notes or to discuss a security review, get in touch.