Encryption that we can't break either.

MyLifePapers is a local-first, end-to-end encrypted household record manager. Your passphrase derives a key on your device. That key wraps a data key, and the data key is what actually decrypts your records. The data key never leaves your device unencrypted.

Sync providers (Google Drive, Dropbox, OneDrive, iCloud, or our optional cloud) store opaque encrypted blobs. The encryption happens before anything crosses the network. If our servers are breached, the attacker sees ciphertext they cannot open. If your sync provider is breached, same. The key that opens these blobs exists in two places: your device's memory, and the recovery code we asked you to write down at setup.

Three layers, each protecting what the layer below carries. The interesting line is the dashed one: that's where ciphertext crosses into systems we don't control.

┌─ on your device, never leaves ──────────────────────────┐
│
│   "my-passphrase"
│          │
│          ↓  Argon2id  (m=64MiB, t=3, p=1, salt=16B)
│
│   [ KEK ]  32 bytes  ─ key-encryption-key, in memory only
│          │
│          ↓  XSalsa20-Poly1305 unwrap
│
│   [ DK  ]  32 bytes  ─ data key, zeroed on lock
│          │
│          ↓  XSalsa20-Poly1305 encrypt
│
│   ┌─────────────────────────────────────┐
│   │ mlp-vault-v6                       │  envelope
│   │ ciphertext  ‖  24-byte nonce        │
│   └─────────────────────────────────────┘
│                       │
└─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─  trust boundary
                            │
                            ↓  HTTPS
┌─ untrusted: sync provider ──────────────────────────────┐
│
│   Google Drive  /  Dropbox  /  OneDrive  /  iCloud
│   or MyLifePapers Cloud  (Cloudflare R2)
│
│   sees:     opaque bytes · file size · mtime
│   does not: passphrase · KEK · DK · records
│
└──────────────────────────────────────────────────────────┘
          

We have built the system so that the following are inaccessible to us, not by policy but by construction. A subpoena could not compel us to produce them; we don't have them.

Your passphrase

Used on your device to derive a key, then dropped from memory. Never transmitted, never persisted in plaintext, never reaches our servers in any form.

The data key

Held only in memory while the app is unlocked. Wrapped on disk with your passphrase. Zeroed from memory when the app locks (idle timeout, system suspend, screen lock).

Your records

Encrypted on your device before they leave. We receive opaque bytes: ciphertext indistinguishable from random.

What you store, how you use it, when you open it

No analytics SDKs. No telemetry pings. No feature-usage tracking. We see what's necessary to validate your license and route encrypted sync traffic, nothing more.

The working copy is on your device. Encrypted backups exist in two other places. You control both.

1. i.

   On your device, decryptable.

   A local SQLite database, protected by your operating system's file encryption: FileVault on macOS, BitLocker on Windows, Data Protection on iOS, file-based encryption on Android. Accessible only when the device is unlocked. The working set you actually use day to day.

2. ii.

   On your sync provider, encrypted.

   One encrypted blob per household member, written to a folder you choose in your cloud storage. We never have access to your Google, Dropbox, Microsoft, or iCloud account. You can revoke our sync app's access at any time from your provider's settings without telling us.

3. iii.

   On our cloud, optional, also encrypted.

   For cross-account family setups (where members use different Google accounts, or who prefer not to use a third-party cloud), we offer paid sync via our Cloudflare R2 bucket. Same encryption applies: we hold ciphertext we cannot read. Authenticated by your license key alone; no email, no password, no account on our side.

A household with more than one member shares a single data key without sharing passphrases. Each member's device holds the data key wrapped by their own passphrase. When a member is added, the admin's device encrypts a copy of the data key for the new member's public key: a libsodium crypto_box_seal operation against X25519. Neither member ever sees the other's passphrase. The data key itself remains the same; what differs is how it's wrapped for each person who has access to it.

Records are creator-owned by default. To share a record with another member, the creator explicitly grants access via the sharing UI. The recipient gets read access; they cannot edit or delete. The record itself stays encrypted under the same data key. The share decision is metadata describing who's allowed to read which row.

One household, one data key, many wrappers. The key never grows. The trust graph does.

There are two paths back into your vault. Neither involves us.

Every encryption product makes choices about what it protects against. The honest version is to list both sides. Here is ours.

What we defend

1. 7.1

   Server breach. If Google, Dropbox, Microsoft, iCloud, or our own R2 bucket is compromised, attackers see encrypted blobs they cannot decrypt without your passphrase or recovery code.

2. 7.2

   Network attackers. All traffic is TLS in transit. Sync requests authenticate via license key in a custom request header, not a cookie, which closes off CSRF by construction.

3. 7.3

   Lost or stolen device. Auto-lock triggers after five minutes of inactivity, on system suspend, and on OS screen lock. The data key is zeroed from memory at each event. The vault is unreadable while the device is locked.

4. 7.4

   Other apps on your phone. The mobile app uses the iOS Keychain or Android Keystore with access groups scoped to our signing identity. Other installed apps cannot read our keys, even with system-level access in their own sandbox.

5. 7.5

   Compromised sync metadata. The folder structure on your sync provider exposes file sizes and modification times, not content, names, or types. Record filenames are opaque hashes.

What we honestly do not defend

1. 7.6

   Malware on a device you are actively using. If your laptop is keylogged, no encryption product can help: we are decrypting your records for you in memory by design. This is the irreducible cost of being usable.

2. 7.7

   A weak passphrase combined with a leaked vault blob. Argon2id makes brute force expensive (roughly half a second per attempt on modern hardware), but a six-character common password is still attackable. Use a passphrase, not a password. Three random words beats one clever word.

3. 7.8

   A household member you've shared with going rogue. Once you share a record with someone, they have a decryption-capable copy on their device. Removing them from the household stops new shares from reaching them, but you cannot reach into their device after the fact.

4. 7.9

   Targeted nation-state attacks. If a nation-state targets you specifically with on-device exploits, our threat model does not cover you. Use a hardware-backed key store, an air-gapped device, and trained opsec, and probably not us.

For the security-curious and for OAuth or integration reviewers. Every value here is traceable to the code under apps/desktop/src/main/ and apps/mobile/src/lib/; this section reads as a spec, not as marketing.

Encryption primitive

libsodium crypto_secretbox_easy (XSalsa20 + Poly1305). Authenticated encryption: ciphertext carries an integrity tag; verification fails on tamper.

Key derivation

Argon2id. Memory 64 MiB, time 3, parallelism 1, 16-byte random salt. OWASP's recommended profile for sensitive applications.

Data key (DK)

256-bit symmetric key from libsodium crypto_secretbox_keygen. Generated locally per household. Wrapped per-member with each member's passphrase-derived KEK.

Member sharing

crypto_box_seal (X25519 + XSalsa20-Poly1305 + BLAKE2b) to a recipient member's public key. New members never need the admin's passphrase, only their own.

Vault envelope

Versioned wire format, currently mlp-vault-v6. Backwards-compatible by design: older versions remain readable indefinitely; version bumps pair with read paths that handle both.

At-rest on iOS

Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly, app-group restricted to our signing team ID. SQLite database file pinned to FileProtectionType.complete.

At-rest on Android

Keystore-backed key material. allowBackup="false" with explicit data_extraction_rules excluding every domain from cloud backup and device transfer.

Auto-lock

Five-minute idle timeout, lock on system suspend, lock on OS screen lock. The data key is zeroed from memory on each event.

Trusted Access & Send

Per-share encryption with PBKDF2-SHA256 → AES-256-GCM via WebCrypto. The access code lives in the link and never reaches our servers; the blob is unreadable to anyone who intercepts the link without the code.

Random sources

randombytes_buf in libsodium paths, crypto.getRandomValues in the renderer, crypto.randomBytes in the Node main process. Math.random is not used for any key, nonce, or token in this codebase.

On-device AI

Document classification and embedding for search run entirely on your device. Records are never sent to a third-party model. Optional summarization runs a small on-device model, Gemma 4, falling back to the platform's native model where available: Apple Foundation Models (iOS 26+), Gemini Nano (Android), or Phi Silica (Windows). All on-device.