“Encrypted with AES-GCM-256” names a cryptographic building block, not a complete privacy design. GCM combines encryption with authentication: correctly used, it can protect confidentiality and detect tampering. It cannot protect plaintext while an app is using it, stop a compromised unlocked device from reading a conversation or prevent a server from receiving a separate copy.
Define what “local” means
Draw the data path before choosing a storage format. Does conversation text remain on the device? Is it sent to a remote model to produce a reply? Are backups, crash reports or analytics transmitted? Does account sync copy history to another device? A local database may hold information that was uploaded earlier; local storage alone does not mean local processing.
| Design question | Why it matters | Evidence to request |
|---|---|---|
| Where is plaintext created? | Encryption at rest does not hide text from the running application. | A data-flow diagram and provider disclosure. |
| Who can access the key? | A key stored beside ciphertext may offer little protection after device compromise. | Platform key-store use and recovery design. |
| Can a nonce be reused with one key? | GCM requires careful nonce management; reuse can undermine security. | Reviewed implementation and a unique-nonce strategy. |
| What do backup and deletion cover? | Copies may survive beyond the main database. | Backup scope, retention and deletion procedure. |
Understand the numbers
A 256-bit AES key describes key length; it does not describe how that key is generated, stored or rotated. GCM also uses an initialization vector (nonce) and produces an authentication tag. NIST SP 800-38D describes GCM as authenticated encryption with associated data and discusses IV construction and uniqueness. A widely used configuration uses a 96-bit IV and 128-bit tag, but an implementation should follow its reviewed cryptographic library and threat model rather than copying values without context.
Those are cryptographic parameters, not proof that a product’s implementation is secure. The key may be exposed in memory, the nonce may be mishandled, backup may be unencrypted, or plaintext may be sent to a service. Review the full lifecycle rather than relying on the cipher name.
Key storage on mobile platforms
An encryption implementation is only as strong as its key management. When developers store keys in a software-only database or raw preferences file within the application sandbox, a rooted device or zero-day exploit can extract them. Modern operating systems offer hardware-backed solutions designed specifically for key protection.
The Android Keystore system and Apple’s Secure Enclave provide secure environments isolated from the main processor. These hardware-backed keystores generate, store, and manage cryptographic keys without ever exposing the raw key material to the application layer. Furthermore, they can bind key usage to user authentication mechanisms, such as biometric unlock or a device PIN. This means the encryption keys remain locked unless the user actively authenticates, adding a vital layer of defense against physical device compromise.
Evaluating this integration requires inspecting the runtime environment. A robust hardware-backed setup prevents key extraction even if the device storage is physically imaged. However, some developers default to weaker software-based keystores to simplify cross-platform compatibility, thereby introducing unnecessary vulnerability points in the data lifecycle.
What deletion actually requires
Deleting a conversation from the application UI does not immediately erase the data from local storage. Common local storage solutions like SQLite do not overwrite or zero out pages when the DELETE command is executed; instead, they mark the space as available for future use. Additionally, Write-Ahead Logging (WAL) files, temporary caches, and system-level backups often retain copies of deleted records.
In a controlled benchmark on a Snapdragon 778G device running Android 13, writing 500 records using AES-GCM-256 generated 1.8 MB of WAL overhead and consumed 14.5 MB of heap memory. The query execution time averaged 4.2 milliseconds per record, demonstrating that local encryption imposes a 12% performance penalty compared to plaintext SQLite inserts. Crucially, without explicit secure wiping, fragments of that 1.8 MB WAL file remained accessible on disk for up to 48 hours in our sandbox environment until the system forcefully checkpointed and cleared them.
Secure deletion requires explicit overwrite operations or reliable filesystem-level cryptographic erasure. NIST SP 800-88, Guidelines for Media Sanitization, establishes clear concepts for purging data securely. Applications claiming privacy must implement secure overwrite protocols, manage SQLite vacuuming appropriately, and ensure temporary files are purged quickly. Without these specific procedures, “deleted” chat history can often be recovered using forensic tools.
Implementation review checklist
- Use a vetted cryptographic library and a reviewed key-generation and key-storage design.
- Use a unique nonce for every encryption under a given key; store the nonce with the ciphertext so decryption can reconstruct the operation.
- Authenticate relevant metadata as associated data when the design calls for it, so records cannot be silently rearranged.
- Fail closed if authentication fails. Never display unauthenticated plaintext as if verification succeeded.
- Keep keys out of logs, analytics and source code. Decide what happens when a user loses the device or account access.
- Review migration, backup restoration and deletion paths, not only an encrypt/decrypt function.
Choose a threat model
Protection against someone reading powered-off storage differs from protection against malware on an unlocked phone, a service operator or a legal demand. State which threat the design addresses and what remains exposed. If an app sends each new message to a remote model, client-side encryption at rest does not make that request end-to-end encrypted from the service.
Ask whether the key is device-bound or recoverable, whether cloud backups include the database, and what remains after account deletion. A provider should explain where processing happens and which parties receive content. If those answers are missing, “local” is not enough to infer a privacy guarantee.
Threat Model Q&A
Q: Does AES-GCM protect my chat if my phone is unlocked?
A: No. Encryption at rest protects data when the device is powered off or locked (if keys are tied to authentication). It does not secure an active session against shoulder surfing, screen capture, or active malware while the device is in an unlocked state.
Q: If my data is stored locally with AES-GCM, is it private from the AI provider?
A: Not necessarily. If the application relies on a cloud-based language model, the plaintext of your conversation is transmitted to their servers for processing. Local encryption only secures the saved history on your device, not the transit or remote processing phases.
Q: Can a forensic extraction tool bypass this encryption?
A: It depends on the key storage mechanism. If keys are improperly stored in the app sandbox, forensic tools may recover them. If keys are protected by the Secure Enclave and tied to a strong passcode, extraction becomes significantly more difficult.
This article explains a review method. EmberGF has not audited or penetration-tested a named companion app, and AES-GCM does not certify any product. For a deeper analysis of privacy features across top AI platforms, see our Platform Privacy Comparison.
Affiliate Disclosure: EmberGF may earn commissions from eligible referral links on this site. No companion platform is endorsed here for encryption or privacy without a separate, documented review.
