How Encrypted Sync Works Between Devices, Step by Step

2026-09-29 · Yesterself

Here is the suspicion, and it is a reasonable one. Your phone and your tablet both show the same journal entry. That entry got from one to the other through a company's servers. So at some point, surely, the company had it. Encryption sounds like a claim that stops being true the moment two devices need to agree on something.

It does not, and the shape of the answer lets you ask far better questions of any app that offers sync.

The whole idea in one sentence

The data and the keys travel on different roads, and the server is only ever on one of them.

Picture a courier who moves locked strongboxes. The courier needs to know which box goes where and how heavy it is. The courier does not need to know what is inside, and in a well-designed system has no way to find out. The interesting question was never how the box traveled. It was how the person at the other end came to have a key.

Everything below is either the mechanics of moving boxes, or the mechanics of getting a key onto the second device without the courier holding a usable copy. Where that boundary sits in the first place is a separate question, covered in what an end-to-end encrypted journal app actually means.

What actually happens when you write an entry

On the device you are typing on:

1. You finish a paragraph. It exists as readable text in the app's memory and, in most designs, in the app's local storage.
2. The app encrypts it with a key derived from your key material, producing ciphertext plus a small amount of routing information: an identifier, a version number, a timestamp.
3. That bundle is uploaded. What leaves the device is already unreadable.

On the server:

1. The blob is stored under its identifier and added to an ordered log of changes for your archive.

On your second device:

1. It asks the server what is new since the last change it saw, downloads the blobs, and decrypts them locally with the key it already holds.

Step 5 is the one people skip past. "The key it already holds" is doing enormous work in that sentence. Getting the key there is the only genuinely hard problem in encrypted sync, and it happens exactly once per device, during setup.

What "add a device" really does

There are three families of answer. Most products use one, or a combination.

One: you carry the secret yourself. You type a recovery phrase into the new device, or you scan a QR code shown on the old one. The key material either moves directly between the two devices, or is re-derived on the new device from the words you entered. Nothing that passes through the server helps anyone. This is the simplest to reason about and the most demanding of you, because the secret is yours to keep.

Two: a wrapped key on the server. The key that opens your archive is itself encrypted, using a key derived from a passphrase only you know, and the resulting wrapped blob is stored on the server. A new device downloads the blob and unwraps it locally after you type the passphrase. The server holds a locked box containing the key to all the other boxes, and no way to open it. This is convenient, and it moves the entire weight of your security onto that one passphrase. Ask what protects the wrapping: a slow key derivation function makes guessing expensive, and a passphrase you invented in ten seconds does not.

Three: device-to-device key exchange. Every device generates its own key pair on first run and publishes only the public half. When you add a new device, an existing device encrypts the archive key specifically to that new public key and uploads the small result. Only the private key sitting on the new device can open it. The server relays an envelope it cannot read.

This third pattern is why so many encrypted apps ask you to approve the new device on an old one. That prompt looks like a permissions dialog. It is not. It is the cryptographic step itself — your old device is the only thing that can perform it.

The gap worth knowing about

If the server hands out public keys, a dishonest server could hand out its own and quietly add itself as a device. This is the reason apps show a short verification code or a string of numbers on both screens and ask you to check that they match. Comparing them takes four seconds and closes the one door this design leaves open.

What the server sees during ongoing sync

A server is not blind, so be precise about it rather than reassuring.

It sees that an archive exists and roughly how many devices are attached to it. It sees blobs arriving and being fetched: how many, how large, at what times, from which IP addresses, on which platforms. It sees the shape of your habits — that you write most evenings, that you went quiet for eleven days in March.

What it does not have, in an end-to-end encrypted design, is any of the words. Which is also why it cannot do certain things for you, and those absences are the most honest evidence that the encryption is real.

The awkward parts, which are how you can tell it is genuine

Conflicts get resolved on your device. Two devices edit the same entry while both are offline. A normal server merges the versions; an encrypted server cannot, because merging requires reading. So the resolution happens on a device once both copies arrive. Last writer wins is easy and quietly destructive. Keeping both versions is untidy and much kinder to a diary. Ask which one an app does.

The first sync on a new device is slow. It pulls down everything, decrypts it locally, then builds a search index on the device, because a server that cannot read your entries cannot index them either. A large archive takes a while and uses real storage. That wait is a good sign.

Removing a device, honestly

Revoking a device stops it from receiving anything new, and in better designs rotates the key so future entries are encrypted to a set that no longer includes it. What revocation cannot do is reach into a phone you no longer control and scrub what it already downloaded.

If a device is lost rather than retired, treat it as two jobs: revoke it in the app, and use the platform's remote lock or wipe on the device itself. Rotating a key protects what comes next, not what was already copied.

Five questions to ask before you trust a sync feature

1. When I add a device, what exactly do I enter or scan, and could anything the server stores let it in on its own?
2. If a key is stored on the server, what protects it, and how strong is the passphrase you expect me to choose?
3. Can I see a list of my devices, and remove one?
4. What happens to an entry that two devices edited offline?
5. If I lose every device I own, what can support do? A company that can restore your readable archive is a company that could read it.

That last one is the subject compressed into a line. Convenient recovery and end-to-end encryption pull against each other, and every product picks a point between them. You are not looking for a magic answer, only a stated one.

Yesterself sits at the strict end. There is no account, no email address, and no password to reset; the identity is twelve BIP39 words held by you, the server stores ciphertext it cannot read, and nothing is used to train anything. Sync across devices is part of premium, and it carries the honest half of the bargain: if those twelve words are gone, we cannot open the archive either. Export is free forever, in open formats, on the free tier too. The app is not released yet, so the waiting list is the only place to stand.

Whatever you end up using, the five questions travel with you. They work on anything that offers to keep two devices in step.

Common questions

Does a server have to decrypt my entries in order to sync them?

No. In a properly built end-to-end encrypted system the server moves sealed blobs between devices and stores them. It needs the address and the size, not the contents, in the same way a courier needs an address and not the letter.

How does a second device get the key if the server does not have it?

By one of three routes: you enter or scan the same secret on the new device, you unlock a key that was stored on the server already encrypted with a passphrase only you know, or an existing device encrypts the key specifically to the new device's public key.

Why do I have to approve a new device on my old phone?

Because in most designs the old device is the only thing that can hand over the key. That approval screen is not a permission checkbox on a server. It is the moment your existing device performs the encryption that lets the new one in.

What happens if I edit the same entry on two devices while both are offline?

The server cannot merge text it cannot read, so the resolution happens on your devices. Some apps keep the last version written, some keep both and let you choose. For a journal, keeping both is the safer behavior.

Does removing a device from my account erase the entries already on it?

Usually not. Revoking a device stops it receiving anything new. Data it already downloaded and decrypted sits in its local storage until that device is wiped or the app is removed.