Encryption hides bytes; authentication proves them
Confidentiality and integrity are separate properties, and it is possible to have the first without the second. A cipher that only conceals data will decrypt whatever it is handed — including bytes an attacker altered on the way — and hand the result to the application as though nothing happened.
Authenticated encryption closes that gap. Alongside the ciphertext it produces an authentication tag, and decryption fails outright when the tag does not match. For a vault this matters more than it sounds: the alternative is silently displaying a manipulated file.
What AES-GCM actually combines
AES-GCM is one established construction that provides both properties at once. It encrypts with AES in counter mode and computes an authentication tag over the ciphertext, so a single operation delivers confidentiality and tamper detection.
The construction is only as good as its inputs. It depends on a unique nonce for every encryption under a given key, and on that key being derived and stored correctly. Neither of those is implied by naming the algorithm.
Why nonce management is the quiet failure mode
A nonce is a value that must never repeat for the same key. Reusing one in a counter-mode construction undermines the guarantees the mode is supposed to provide and can expose relationships between the encrypted records.
This implementation detail is rarely visible in consumer-facing descriptions. It is a fair question to ask of any vault that publishes technical documentation, along with how it prevents nonce reuse.
Key derivation and key storage are separate controls
Deriving a key from what you type is one problem; keeping that derived key safe while the app is closed is another. A vault can do the first well and the second badly.
Treat them as two questions with two answers: what function turns the credential into key material and at what cost, and where does the resulting key live between sessions. Platform key stores exist precisely to answer the second.
What to look for in the documentation
- A named authenticated-encryption construction, not just a key size.
- A statement about nonce uniqueness per encryption.
- Whether filenames and metadata are protected alongside file bodies.
- Key derivation and key storage described as distinct mechanisms.
- Clear failure on authentication mismatch, rather than partial or best-effort display.
Reading claims critically
- Equating a 256-bit key label with a complete design.
- Ignoring nonce management because the algorithm is standard.
- Assuming authenticated encryption protects an unlocked screen — it does not.
What authentication does not cover
Tamper detection applies to the records the vault manages. It says nothing about copies that left the vault, about a compromised operating system observing the decrypted result, or about someone reading the screen while the file is open.
In this guide, authenticated encryption describes protection for stored vault records. AEAD constructions can also protect data in transit, but neither use protects copies or an already-decrypted display by itself.
A fictional example
Leo starts with a non-sensitive test: “Look for a named authenticated-encryption construction in technical documentation.” Next, Leo follows the second check: “Check whether filenames and metadata are protected as well as file bodies.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Equating a 256-bit key label with a complete design
- Ignoring nonce management
- Assuming encryption protects an unlocked screen
What this workflow does not change
- Equating a 256-bit key label with a complete design
- Ignoring nonce management
- Assuming encryption protects an unlocked screen
Questions people ask
Does AES-GCM prevent deletion?
No. It protects confidentiality and integrity, not availability.
Does authentication mean user login?
Here it means cryptographic integrity authentication, not account sign-in.