How encryption works in against.
A plain-English walkthrough of the AES-on-device encryption that keeps your against. data unreadable to anyone but you.
against. encrypts every sensitive field on your device with AES-256, using a key generated on first run and stored in your phone’s secure enclave. Nothing leaves your device. Here is exactly how that works, and what it gives you.
What “encrypted on-device” means in practice
When you log a relapse note, the text you type does not get sent over the network. It does not get written in plaintext to your phone’s storage either. Before the database row is saved, the text is run through AES (the Advanced Encryption Standard, a cipher that has been the global default for over twenty years) using a 256-bit key. The output is unreadable to anyone who doesn’t have that key.
The key is generated the first time you open the app. It’s 32 random bytes, drawn from your phone’s cryptographic random number generator (the same one that protects your bank’s app and your messages). The key is stored in your phone’s secure enclave: Keychain on iOS, EncryptedSharedPreferences on Android. We never see it. We never receive it. There is no “reset password” button, because there’s no password to reset.
What we encrypt and what we don’t
We encrypt the fields where it matters: relapse notes, trigger annotations, anything you might write that’s personal. We do not encrypt fields that don’t need it: timestamps, internal IDs, schema versions. Encrypting timestamps would not improve your privacy and would slow the app meaningfully on lower-end devices.
You can audit this for yourself in the open source. We publish the schema (see Privacy & Security) and the encryption helpers. There are no surprises.
Why CBC mode
We use AES in CBC (Cipher Block Chaining) mode with a fresh random initialization vector for every record. CBC is well-understood, has no known weaknesses against the threat model that matters here (offline access to a device’s storage), and is supported on every mobile platform without needing platform-specific cryptographic extensions. We considered GCM, which is also widely deployed and adds authentication; for our use case (single-device, single-user, no data-in-transit) the additional complexity didn’t earn its keep. We may revisit this for a future version.
What this protects against
If your phone is lost or stolen and the screen is unlocked, against. is no different than any other app the thief opens. They see what you see. That’s a risk we can’t fix at the app level; it’s why the app supports an optional biometric lock and a privacy screen overlay.
If your phone is lost or stolen and the screen is not unlocked, the encrypted database on your device is unreadable without the key, and the key lives in the secure enclave, which is hardware-protected. A motivated attacker with physical access and lab equipment is a threat we don’t claim to defeat. But for the realistic risks (phone theft, opportunistic access by someone you know), the encryption is doing its job.
What this protects against, more importantly
The other thing on-device encryption protects against is us. We could be served a subpoena. We could be acquired by a company with different values. We could be compromised by an attacker. None of those events would expose your data, because we don’t have your data. The encryption is enforcement, not promise.
Further reading
See also: Privacy & Security.