| PBKDF2 |
Converts a human password into a strong cryptographic key by repeatedly hashing it with a random salt.
|
Makes password-guessing much slower and more expensive for attackers, even if they steal the vault file.
|
Derives the encryption key (and sometimes a separate integrity key) from the master password.
|
| Salt |
A random value stored with the vault that is mixed into PBKDF2 during key derivation.
|
Prevents identical passwords from producing identical keys and defeats precomputed “rainbow table” attacks.
|
Stored in the vault header and reused whenever the vault is opened to derive the same key.
|
| Iteration Count |
The number of PBKDF2 rounds (how many times the hash function is applied).
|
Controls the cost of each password guess; higher counts increase resistance to brute force.
|
Stored in the vault header so the app knows how to regenerate keys consistently.
|
| AES-256 |
A symmetric encryption algorithm that encrypts and decrypts data using the same secret key.
|
Protects confidentiality: stolen vault data remains unreadable without the correct key.
|
Encrypts the vault contents (records, notes, metadata) before writing anything to disk.
|
| AES Mode (CBC/GCM) |
The operating mode that determines how AES processes blocks and how it handles integrity (if applicable).
|
Correct mode choice is crucial: GCM provides built-in authenticity; CBC requires separate integrity checks.
|
CBC + HMAC is common; GCM can replace the need for a separate HMAC if used correctly.
|
| IV / Nonce |
A per-encryption random (or unique) value used to ensure encrypting the same content yields different ciphertext.
|
Prevents pattern leakage and protects against attacks that exploit repeated encryption with the same key.
|
Generated fresh for each encryption operation and stored alongside the ciphertext.
|
| HMAC-SHA-256 |
A keyed integrity check that proves data was not changed and was produced by someone with the secret key.
|
Protects against tampering: detects modifications to the vault file before decryption.
|
Computes a tag over the encrypted vault (and header fields) and verifies it on open.
|
| SHA-256 |
A cryptographic hash function that maps data to a fixed-length digest.
|
Forms the “hash” component inside PBKDF2 and HMAC; reliable hashing underpins secure key derivation and integrity.
|
Used indirectly via PBKDF2 and HMAC rather than as a standalone password hash.
|
| Key Separation |
Using different derived keys for different purposes (e.g., one for encryption, one for integrity).
|
Reduces risk: even if one operation has an implementation issue, it does not automatically compromise everything.
|
PBKDF2 output is split or expanded to produce separate keys for AES and HMAC.
|
| Secure Random Number Generation |
A cryptographically secure source of randomness used for salts, IVs/nonces, and sometimes vault identifiers.
|
Predictable randomness can break encryption even if AES/HMAC are correct.
|
Generates the salt and IV/nonce whenever creating or updating the vault encryption.
|
| Authentication / Verification Step |
The process of verifying integrity (HMAC or AEAD tag) before attempting to decrypt.
|
Prevents “decrypt-then-fail” scenarios and avoids exposing the app to modified ciphertext attacks.
|
On open: derive keys → verify HMAC/tag → only then decrypt and load records into memory.
|
| In-Memory Handling |
Keeping decrypted content only in RAM while needed and avoiding writing plaintext to disk.
|
Limits exposure if the machine is compromised or if crash dumps/temporary files are captured.
|
Decrypt on demand, minimize caching, and re-encrypt immediately on save/close.
|
