Single-use links
You sign in through a signed link, valid for a few minutes and usable once. Only the SHA-256 digest of the token is stored: the link itself exists nowhere on the server.
A private journal is only worth what it refuses to give up.
Patinae is built on a simple assumption: you must expect the database to end up in the wrong hands one day, and make sure that is not enough. Here is how, without metaphors.
Every entry has its own key.
Patinae uses versioned envelope encryption. A data key is drawn at random for each journal entry, encrypts that entry alone, then is itself encrypted by a separate content key. Only the ciphertext, the wrapped key, its reference and its version are stored.
- Text XChaCha20-Poly1305, authenticated encryption: any tampering is detected
- Photos and audio XChaCha20 secret streams split into frames, suited to large files
- Key per entry One random data key per entry, never reused from one entry to the next
- Envelope Replaceable adapter: the local key can give way to a key vault or a managed KMS without touching the journal
- Rotation A new key reference re-wraps the existing data keys: the ciphertext is not rewritten
- Production The application refuses to start without a dedicated content key: no silent fallback
One practical consequence: compromising one entry yields nothing about the others. And the application itself never handles plaintext content in its templates: views receive data that is already prepared.
No password, so no password to steal.
An explicit confirmation
Opening the link does not sign you in: you have to confirm with an action. This step stops the link scanners built into email clients from consuming it before you do.
Recent re-authentication
Viewing sensitive information, managing access or transferring an object requires a recent confirmation through a fresh personal link, valid for a limited time.
No secret in a page
Invitation links only place their secret in the encrypted session, then redirect immediately to a token-free address. No token is ever rendered in HTML.
An access log that says nothing extra.
Invitations, responses, revocations and views are recorded in an append-only log. That log exists so you can see what happened to an object, not to build a file on anyone.
-
Never recorded
Message contents, serial numbers, invitation tokens, raw IP addresses, media contents. Neither in the log, nor in the technical logs.
-
Encrypted sessions
Sessions are encrypted at rest, because they briefly carry invitation secrets between two steps.
-
Uncached responses
Sensitive pages disable caching and referrer propagation, so no copy is left in a proxy or a neighbouring address bar.
-
Encrypted notifications
Notifications carrying a secret link are encrypted in the queue, between the moment they are created and the moment they are sent.
What encryption does not do.
No serious product should let you believe otherwise. Here are the real limits, so you can decide knowing them.
-
Your email matters
Since signing in goes through your inbox, whoever controls your email can request a link. Protect that inbox at least as well as the rest.
-
Members see the journal
Encryption protects you from third parties, not from the people you invited. Grant access only to people you trust, and revoke it when that is no longer true.
-
The service holds the keys
Content keys are managed server-side, outside the database and the backups. This is not end-to-end encryption: it is a deliberate trade-off, so that transferring an object stays possible, and so a journal does not become unreadable because a device was lost.
-
A transfer is final
Accepting a transfer removes the former owner's access. There is no undo: that is what makes ownership credible.
Write to us before writing elsewhere.
If you believe you have found a vulnerability, contact us directly and give us a reasonable window to fix it. Never include journal content, invitation links or serial numbers in your message.