Every privacy-conscious app these days claims to be "encrypted". The word does an extraordinary amount of marketing work. It is also, on its own, almost meaningless. Encryption that uses a key the vendor can read is not really protecting you from the vendor. Encryption in transit that ends at a database stored in plaintext on a server is not protecting you from the breach. Encryption with a weak algorithm is not protecting you from anyone.
So when we say Trenziq stores your ledger using AES-256 with keys in the Android Keystore, that is a precise claim with three specific parts. Let's unpack each of them in plain language.
Part 1: AES-256 is the algorithm
AES — the Advanced Encryption Standard — is a symmetric block cipher published by NIST in 2001 after a five-year open competition. "Symmetric" means the same key encrypts and decrypts; "block cipher" means it operates on fixed-size chunks of bytes (16, in AES's case); the "256" in AES-256 refers to the size of the key in bits.
For practical purposes, you need to know three things about AES-256:
- It is the standard. AES is used by the US government for classified data up to TOP SECRET. It is in TLS, in disk encryption, in WhatsApp, in every iPhone. It has been studied harder than almost any algorithm in history.
- Brute force is not a realistic threat. A 256-bit keyspace contains
2256possibilities — a number too large to write meaningfully. Even imagining every grain of sand on Earth as a top-end GPU running for the age of the universe, you would not make a dent. - Implementations matter more than the algorithm. AES has not been broken; specific implementations have been broken because they reused a nonce, leaked timing, or stored the key carelessly. The interesting questions are about how the key is handled.
Part 2: SQLCipher is the storage layer
Trenziq's ledger lives in SQLite, the embedded database that runs on basically every smartphone ever shipped. Vanilla SQLite, however, stores its database file in plaintext on disk — if a forensic tool pulls the file off the device, the rows are right there.
SQLCipher is a well-respected, open-source extension to SQLite that transparently encrypts every page of the database with AES (256-bit, in CBC mode with HMAC) before writing it to disk and decrypts it on read. From the app's point of view, it is just SQLite. From the disk's point of view, it is opaque ciphertext.
This solves a very specific problem: if your phone is off, or the database file is otherwise pulled out of the app's sandbox, the data is unreadable without the key. That is the meat of "encryption at rest".
Why "encrypted at rest" needs a footnote
"At rest" specifically means "while sitting on storage". It does not mean "while the app is open with the database unlocked in memory". A finance app cannot, by definition, work without decrypting the data at some point — but it can absolutely refuse to send that decrypted data anywhere. The cloud-finance dangers piece goes into where that boundary tends to leak.
Part 3: Android Keystore is where the key lives
The hardest, and most consequential, part of any encryption story is key management. Where does the key come from? Where does it live? Who can read it?
On modern Android devices, the answer is the Keystore — an OS-level service that, on phones with hardware-backed key support (almost all phones from the last seven years), stores cryptographic keys inside a dedicated secure element or trusted execution environment. The key never leaves that hardware boundary. Even the app that requested it cannot extract its bytes; the app can only ask the Keystore to perform operations using the key.
For Trenziq, this means:
- The AES-256 key that locks your ledger is generated on first run, inside the Keystore.
- The key is bound to the device. Pull the database file onto another phone and there is no path to decrypt it.
- If you uninstall the app, the key is destroyed. The ciphertext that any backup tool may have copied becomes permanently unusable.
What this combination actually defends against
Crypto is most useful when you can map it to specific threats. Here is the matrix as it applies to Trenziq:
| Threat | Defended? | How |
|---|---|---|
| Lost / stolen locked phone | Yes | Database is AES-256 ciphertext on disk; key is device-bound. |
| Forensic disk imaging of the device | Yes | The imaged blob is unreadable without the in-hardware key. |
| Malicious app on the same device | Mostly | Android sandboxing prevents direct file access; key is not extractable. |
| Lost / stolen unlocked phone | No | The app, like any app, will open. Use device lock + biometrics. |
| Server-side breach | N/A | There is no server. |
| State-level adversary with physical access & vendor cooperation | Out of scope | Honest answer — this is not the threat model. |
What about backups?
Trenziq's optional Google Drive backup runs entirely client-side. The database is already AES-encrypted on disk; when you opt in, the backup picks up that ciphertext, wraps it with another envelope tied to a user-supplied secret, and pushes the resulting blob to your Drive. Google sees an opaque file, nothing more.
This is the right place to mention the responsibility you take on when you turn that backup on: you need to remember the wrapping secret. There is no "forgot password" link, because we cannot provide one without becoming exactly the kind of intermediary we set out to avoid. The companion piece on Android permissions walks through the related INTERNET-permission story.
How to evaluate "AES-256" claims in other apps
If you are auditing any finance app's encryption claim, ask these five questions:
- Where is the key? Hardware-backed Keystore, software keystore, or — alarmingly — embedded in the binary?
- Can the vendor decrypt my data? If yes (typical for cloud apps), the encryption is only as strong as the vendor's operational security.
- What is "at rest" defined as? Disk only? Memory? Both?
- What is the mode? AES-CBC + HMAC, AES-GCM, AES-CTR — they have different properties. "AES" without a mode is a yellow flag.
- Is the implementation auditable? SQLCipher, libsodium, Android Keystore — these are open, well-studied. Hand-rolled crypto is a red flag.
Closing the loop with sovereignty
Strong encryption is necessary but not sufficient. It makes your data unreadable to the wrong people; it cannot, on its own, prevent the data from being collected by the wrong people in the first place. That is why Trenziq pairs AES-256 storage with the more important architectural decision: nothing leaves the device unless you explicitly ask it to. The longer essay on data sovereignty ties the two threads together.
If you remember nothing else from this piece, remember this: an encryption claim without a key-management story is a marketing slogan. Now you know what to ask for.
Further reading from the network: If you appreciate engineering that treats users as the customer, our sister teams take the same posture in their own verticals — VoBot Developers for engineering, IBULUXE for premium essentials, Plasma Biotech for pharma research, Jigyasa Foundation for social-impact work and PGH for hospitality.