Private Journal Apps: How End-to-End Encrypted Backup Works

End-to-end encrypted backup means your journal is encrypted on your own device, with a key derived from a passphrase only you know, before it's uploaded. The server stores the encrypted bytes but has no way to read them. To restore, your device downloads the bytes and decrypts them locally. Nobody in between — not the app company, not the hosting provider — can open your entries.

This article explains how that works under the hood, in plain language. If you just want a checklist for choosing an app, see offline journal app with encryption: what to look for.

The big picture

A typical end-to-end encrypted backup has five steps:

1. You choose a passphrase.
2. Your device turns it into an encryption key using a key derivation function, a salt, and many iterations.
3. Your device encrypts the journal with an authenticated cipher (such as AES-256-GCM) and a fresh nonce.
4. The app uploads one file: a small header plus the encrypted data.
5. On restore, your device reverses the process with the same passphrase.

Let's look at each piece.

Passphrase vs key

Encryption algorithms don't use your passphrase directly. They need a key of an exact size — for AES-256, that's 256 bits of data that looks completely random.

Human passphrases are nothing like that: they're shorter and far more predictable. So the app needs a way to turn "my-quiet-snowy-morning" into a strong key, and to make guessing passphrases expensive for an attacker. That's the job of a key derivation function (KDF).

Key derivation: PBKDF2, salts and iterations

PBKDF2 (Password-Based Key Derivation Function 2) is a long-established, widely supported KDF. It works by running a hash function many times over your passphrase.

Two inputs matter:

• Salt: a random value (for example, 16 bytes) generated for each backup. The salt isn't secret — it's stored next to the encrypted data — but it makes sure the same passphrase produces a different key in every backup. That stops attackers from using precomputed tables and from testing one guess against many users at once.
• Iterations: how many times the hash runs. More iterations make each guess slower. For you, that's a short delay once per backup or restore; for an attacker trying millions of guesses, it multiplies their cost.

The iteration count is a trade-off between speed on your phone and brute-force cost for an attacker. Apps typically store the iteration count in the backup header so it can be raised in future versions without breaking older backups.

Newer KDFs such as scrypt and Argon2 are also designed to be expensive in memory, not just time, which can make large-scale guessing even harder. PBKDF2 remains a common, well-understood choice, especially where it's built into the platform.

Encryption: what AES-256-GCM does

Once there's a key, the journal is encrypted with AES-256-GCM:

• AES-256 is the cipher: it scrambles data using the 256-bit key.
• GCM (Galois/Counter Mode) adds authentication. Along with the ciphertext, it produces a short tag that acts like a tamper seal. If even one bit of the backup is changed — by corruption or by an attacker — decryption fails instead of silently returning garbage.

This "authenticated encryption" matters for backups: you want to know that what you restore is exactly what you saved.

Nonces: never reuse them

GCM also needs a nonce ("number used once"), usually 12 bytes. It must be unique for every encryption with the same key. Reusing a nonce with the same key in GCM can seriously weaken security, so a well-built app generates a fresh random nonce every time it creates a backup. Like the salt, the nonce isn't secret and is stored with the data.

What's inside an encrypted backup file

Put together, a backup file is usually:

Part	Secret?	Purpose
Format marker / version	No	Tells the app how to read the file
KDF iteration count	No	So the same key can be derived again
Salt	No	Makes the derived key unique to this backup
Nonce	No	Unique value for this encryption
Ciphertext + authentication tag	Encrypted	Your journal, plus the tamper seal

Notice what's not in the file: your passphrase and the key. Without the passphrase, the file is just random-looking bytes.

What end-to-end encryption protects against

• A breach of the backup server. Stolen backups are unreadable without passphrases.
• The app company or hosting provider. They store your data but can't read it.
• Interception in transit. Even if traffic were captured, the content is already encrypted (and normally also sent over HTTPS).
• Silent tampering. Authenticated encryption detects changes to the backup.

What it does not protect against

Being honest about limits is part of good security:

• A compromised or unlocked device. Your journal has to be decrypted on your phone so you can read it. If someone has your unlocked phone or malware on it, encryption of the backup doesn't help. Use a device passcode and keep your OS updated.
• Weak passphrases. Iterations slow attackers down, but a very short or common passphrase can still be guessed. Longer is better; a few random words work well.
• A forgotten passphrase. With true end-to-end encryption, nobody can reset it for you. If it's lost, the backup can't be decrypted — by anyone. A password manager is the safest place to keep it.
• Metadata. The server may still know that a backup exists, roughly how large it is, and when it was uploaded — even though it can't read the contents.

How to tell if a journal app really uses end-to-end encryption

Look for these signs:

• The app asks you to create a backup passphrase, separate from any account password.
• It warns that a forgotten passphrase can't be recovered. (If the company can restore your entries after a password reset, it likely holds a key.)
• It names established algorithms such as AES-256-GCM and a proper KDF.
• It says encryption happens on your device, before upload.

For goal journals, this privacy makes a real difference: you'll write more honestly in daily reflections when you know nobody else can read them.

FAQ

Is AES-256 "unbreakable"?

No practical attack is known against AES-256 when it's used correctly. In real life, the weak points are usually the passphrase, the device, or implementation mistakes — not the cipher itself.

Why are the salt and nonce stored in plain view?

They don't need to be secret. Their job is to make each key and each encryption unique. Security comes from the passphrase, which is never stored.

Can I change my passphrase later?

Usually yes: the app decrypts on your device with the old passphrase and creates a new backup with a new salt, nonce and key from the new passphrase. Check how your app handles it.

---

WholeLifeLog backs up this way: entries stay on your device, and backups are encrypted on the device with a PBKDF2-derived key and AES-256-GCM before upload. The server only ever stores the encrypted file.