Security model

What this app protects against — and what it does not

A security promise without its limits is advertising. This page states both.

What happens on the device

Every entry lives in a single encrypted file on the phone. Its key is derived afresh from your factors each time you unlock, then discarded. It is stored nowhere, uploaded nowhere, and does not exist outside that moment.

Key derivation

Your password, or your key files, produce the key through Argon2id — a memory-hard function. The practical difference from older schemes: guessing a password costs not only processing time but memory per attempt. That is precisely what makes the mass-parallel attacks on graphics cards expensive.

The cost parameters are recorded in the file itself. An existing vault is always reopened with exactly the values it was sealed under, so raising them later does not strand older vaults.

Encrypting the data

The contents are encrypted and authenticated with AES-256: a file altered afterwards is recognised as tampering rather than half-opened as damaged. The file header is covered too, so nobody can quietly swap the parameters inside it.

Place binding

A vault can be bound to a place. The key is then derived from your factors and that place. This is not a check the app performs and could be talked out of — away from the place there simply is no key to withhold. A modified build of the app or a faked location gets you no further.

The file contains no coordinates: not the place, not the radius, not even the fact that a vault is bound at all.

Two vaults in one file

A container always holds two slots. If you use only one, the other is filled under a random key that nobody knows — us included. From the outside both are the same size and the same shape.

Limits

The part product pages usually omit.

A place carries little entropy

Place binding helps against someone who has obtained a backup copy and does not know where to stand. It helps little against someone holding your phone who knows which town you live in: the search space is then small. It is an additional factor to a strong password — not a substitute.

Without the place you need the recovery code

Binding a vault to a place produces a recovery code, shown once when the vault is created. It stands in for the place, not for the password — a sheet of paper found in a drawer is not the vault. Without the code and without access to the place, the vault is closed for good.

A compromised phone is lost

Encryption protects a file, not a running system. Malware with broad privileges on an unlocked device sees what you see. No app can prevent that, and we do not claim otherwise.

Biometrics is convenience

A fingerprint is a shortcut on this one device, not a cryptographic factor. Your password or key files always open the vault; biometrics only ever does so in addition, and only here.

No independent audit

This construction has not been reviewed externally. We describe how it works so that you can judge it — but a published audit report is a different thing from a self-description, and while there isn't one, we say so.

Network

In normal use the app talks to nobody. There is no account, no server and no synchronisation.

One single feature uses the internet, and only if you switch it on: the optional timestamp for photos taken inside the app. Only a SHA-256 digest of the image leaves the device — never the image. A digest cannot be turned back into a photo.

Time capsules

A note in the vault can be turned into a time capsule: it does not open before the chosen moment — not for you either. What decides that is neither the app nor the phone's clock, but a signature that simply does not exist beforehand.

The note's key is split by Shamir into three shares, any two of which suffice: one is released by the public randomness network drand, one by a key server at beattime.live, and one you keep as a recovery code. Every share is encrypted to the same moment, and neither beacon releases it earlier. Because two of three are enough, one side going away does not cost you the note.

Sealing needs no network. The chain parameters are built in and sealing uses public keys. A connection is needed only to open a capsule, because that is when the released signature has to be fetched — from us, from a mirror, from anywhere: it is public information, and it is checked locally against the key recorded inside the capsule.

What this does not promise: if both beacons disappear for good, only the recovery code is left. And a capsule protects the content, not the fact that it exists — anyone looking at your opened vault sees that a note is waiting and when it comes due.

Place-bound notes

Separately, a note can be bound to a place. Its key is derived from the grid cell you stood in when sealing it; anywhere else it does not exist. Nothing about the place is stored — no coordinates, no cell, no radius. The two combine: a note can need the moment and the place. Here too there is a recovery code, shown once and stored nowhere.