Privacy and encryption
These words get used loosely in app descriptions, and the differences between them are exactly where the value is. Hidden is not locked. Locked is not encrypted. And a key somebody else holds is not really yours.
-
ChaCha20-Poly1305
-
A modern encryption algorithm that both hides data and detects tampering with it. Fast on phones, which do not always have hardware acceleration for the older alternative.
ChaCha20 does the encrypting; Poly1305 produces a tag that verifies the data has not been altered. Together they are what is called authenticated encryption — decryption fails loudly on a modified file rather than producing plausible garbage.
It is the same construction used in TLS and in modern secure messaging. On hardware without AES acceleration it is meaningfully faster than AES, which is why phones tend to prefer it.
See also: At rest vs in transitKey wrapping
-
Key wrapping
envelope encryption -
Encrypting the files with one key, and then encrypting that key separately with each way in. Changing a passcode rewraps a small key rather than re-encrypting everything.
Files are encrypted once, with a key generated on the device. That key is then wrapped — encrypted — by the passcode, and wrapped again by the recovery code. Two envelopes, one key inside each.
The consequences are all practical. A passcode change rewrites a few hundred bytes instead of a hundred gigabytes. Biometric unlock is another wrapped copy rather than a second security model. And losing every wrapper loses the key, because the key exists nowhere else.
See also: Recovery codeChaCha20-Poly1305
-
Recovery code
-
A one-time string that can unwrap the master key when the passcode is forgotten. Nobody can reissue it, because nobody else ever had it — including the people who wrote the app.
It is shown once, at setup, and it is the second of the two doors. Written down and kept somewhere other than the device, it turns a forgotten passcode into an inconvenience.
If the passcode is forgotten and the recovery code is lost, the files cannot be decrypted by anyone. That is not a support policy that could be argued with; it is what having no copy of the key means. Store it as carefully as the files deserve.
See also: Key wrappingZero-knowledge
-
Decoy vault
plausible deniability -
A second passcode that opens a different, innocuous vault. Someone made to unlock the app can, and what opens is not the thing they were looking for.
Both passcodes are real and both open a real vault. Nothing on screen indicates that another one exists, and the app cannot be asked which one it is showing.
It exists for the situation where refusing to unlock is not an option — a border, a demand, someone standing over you. Encryption alone does not help there, because the problem is not the key, it is being compelled to use it.
See also: Recovery codeHidden vs encrypted
-
Keychain
-
The system's protected store for small secrets, backed by the device's security hardware. It is where keys and tokens belong, and where nothing large should go.
Items in it can carry conditions: only readable when the device is unlocked, only on this device, only after biometric or passcode confirmation. Those conditions are enforced by hardware rather than by the app asking politely.
It stores secrets, not data. Keys, tokens and wrapped material go there; the encrypted files themselves live on disk, where size is not a problem.
See also: Key wrappingAt rest vs in transit
-
At rest vs in transit
-
Encrypted at rest means unreadable on disk. Encrypted in transit means unreadable on the network. They are separate protections, and a product may honestly claim one while not doing the other.
HTTPS is encryption in transit: safe from anyone watching the network, and fully readable by the server at the other end once it arrives. Encryption at rest is about the stored copy, which is what matters if a device is lost or a disk is imaged.
Reading a privacy claim carefully usually means working out which of the two it is about. "Your data is encrypted" without either word attached is a sentence that has been chosen not to say.
See also: ChaCha20-Poly1305Zero-knowledge
-
Zero-knowledge
-
A design where the operator cannot read what it stores, because the keys never leave the user's devices. The test is simple: can they reset your password and still give you your data?
If a service can restore access after you forget everything, it holds something that can unlock your data — which means it can be compelled to use it, and that anyone who breaches the service inherits the same ability.
The trade is real and should be stated plainly rather than sold as pure benefit: genuine zero-knowledge means genuinely losing access when the last key is lost. There is no third option where the operator can rescue you but nobody else can.
See also: Recovery codeAt rest vs in transit
-
Biometrics
Face ID, Touch ID -
The device, not the app, confirms it is you; the app is told yes or no. No fingerprint or face data ever reaches an app, and none of it is a password.
Biometric unlock is a convenience wrapped around a secret, not a replacement for one. What it protects is a stored key, which is why a passcode always exists behind it — the biometric can fail, and the fallback has to be something you know.
The comparison happens inside dedicated hardware and the templates never leave it. An app that offers Face ID is asking the system a question, not collecting anything.
See also: KeychainKey wrapping
-
Anonymous analytics
-
Counting events without recording who did them. The value of the claim depends entirely on what is attached to each event — and file names, paths and URLs are where such promises usually break.
Knowing that a screen was opened is a count. Knowing which file was played is a description of a person. The line between the two is not the word "anonymous"; it is which fields the event carries.
A claim worth trusting says what is *not* sent as specifically as what is: no file names, no paths, no URLs, no credentials, no identifier that survives across sessions — and offers a way to switch the whole thing off.
See also: At rest vs in transit