Security & cryptography
Built so you don't have to trust us.
Documented where you still do.
Most security pages are a list of comforting words. This one is our actual threat model — including what a malicious or compromised LeoLog could and could not do to you. We publish it because an inventor's first question about any notebook service should be adversarial, and we would rather answer it before you ask.
What never leaves your device
- Your content, in readable form. Entries, sketches, and attachments are encrypted in your browser with AES-256-GCM before anything is transmitted or stored.
- Your notebook key. Content keys derive from a 24-word BIP-39 recovery phrase generated on your device. The derived master key exists only in your browser's memory while the notebook is unlocked.
- Your password, as key material. Password unlock works by deriving a key-encryption key on your device (Argon2id, 64 MiB memory-hard) that unwraps an encrypted copy of your master key. The server stores only that encrypted wrap — never the password-derived key, never the master key, never the phrase.
- Unsaved drafts. Even local draft autosaves are encrypted at rest in your browser, and nothing is written while the notebook is locked.
What our servers hold
Ciphertext envelopes, encrypted per-entry keys, encrypted attachments in object storage, public salts and key-derivation parameters, the encrypted master-key wrap, and SHA-256 fingerprints of your sealed entries. Every row is tenant-isolated with database-enforced row-level security — the application's database role cannot bypass it, and our test suite proves that with planted cross-tenant reads that must fail. Backups inherit the same property: a stolen backup is a pile of ciphertext.
What touches the blockchain
A 32-byte SHA-256 fingerprint, batched into a Merkle tree and anchored to Base and, via OpenTimestamps, to Bitcoin. A hash is a one-way function: it proves your exact content existed at a moment in time, and reveals nothing about the content. Your work is never on any chain, and cannot be put there retroactively by anyone, including us.
| Content encryption | AES-256-GCM, per-entry keys, client-side |
| Key root | 24-word BIP-39 phrase, 256-bit entropy, generated on-device |
| Key derivation | Argon2id, 64 MiB / 3 iterations, distinct salts per purpose |
| Password unlock | Argon2id-derived KEK unwraps an AES-256-GCM master-key wrap; wrap stored server-side, keys never |
| Fingerprints | SHA-256, Merkle-batched |
| Anchors | Base L2 (~minutes) + Bitcoin via OpenTimestamps (~hours) |
The honest part: what you still trust us with
LeoLog runs in your browser, and we serve the code. This is the residual trust in every web-delivered encryption product, and we would rather name it than hide it: if LeoLog the company turned malicious, or our servers were deeply compromised, the attacker's move would not be reading our database — that yields ciphertext. It would be shipping modified client code that captures your password or content from that moment forward. Your previously stored entries stay unreadable unless and until you unlock with the poisoned code.
Here is what we do about the trust that remains:
- What runs is what you can inspect. The client is delivered to your browser, where its behavior is observable: what it transmits, and to where, is visible in your own developer tools. In particular, you can watch for yourself that unlock and entry-sealing produce no request carrying anything but ciphertext and public parameters.
- Our CI forbids the crypto from talking to the network. The encryption package is fenced by an automated rule that fails the build if any network capability appears in it — and the check itself is tested against a deliberately planted violation.
- An independent review is the plan of record. Before public launch we intend to put the cryptographic design and implementation in front of an independent security firm and publish their report in full — so the code's soundness rests on named outside experts, not on our say-so.
- Proof verification doesn't involve us. See below — the property you're actually buying survives even a fully malicious LeoLog.
Proof that outlives us
Every entry exports a certificate and a JSON proof bundle. The public verifier at verify.leolog.io recomputes the Merkle root client-side and checks the on-chain anchor against public JSON-RPC data — it does not consult a LeoLog backend, and its build is published with a reproducibility manifest. Any OpenTimestamps client can independently verify the Bitcoin anchor. If LeoLog disappears tomorrow — or turns evil today — every proof you've already anchored remains independently checkable, forever, by anyone.
Deletion means destruction
Deleting an entry requires a typed confirmation and then destroys the decryption material for the entry and its attachments — a crypto-shred. The anchored fingerprint may remain publicly observable on-chain, as the Terms explain, but there is no recoverable content behind it.
What we don't have yet
No third-party audit has reviewed LeoLog yet. Before public launch we intend to commission a focused cryptographic design and implementation review from an independent security firm and publish the report in full, findings included. Broader organizational certifications (SOC 2) are planned for when we serve teams and enterprises. Until then, the honest summary of our security posture is: a published threat model, automated in-repo enforcement, observable client behavior, and proofs you can check without believing a word we say.
Reporting a vulnerability
Found something? Write to security@leolog.io. We commit to acknowledging reports within 72 hours, and we will not pursue or threaten legal action against good-faith security research conducted against your own account and data.