Zero-Trust Encryption: Building My Data Manager with AES-256-GCM

The Philosophy

Most "encrypted" apps use encryption at rest — the data is encrypted on disk, but the server holds the key. That means anyone with server access (or a court order) can read your data. Zero-trust encryption means the server never has the ability to decrypt your data. Period.

How It Works

Registration: User chooses a master password. The client generates a random 32-byte salt. Using PBKDF2 with 100,000 iterations, the password + salt are transformed into a 256-bit AES key. The salt is stored on the server. The key is never stored.

Login: The server sends the salt. The client re-derives the key using PBKDF2(password + salt). The key exists only in memory for the session duration.

Encryption: Data is encrypted with AES-256-GCM before leaving the client. GCM provides authenticated encryption — any tampering with the ciphertext will be detected upon decryption.

Decryption: Data is decrypted client-side using the in-memory key. The server never sees the plaintext.

Why AES-256-GCM

GCM (Galois/Counter Mode) provides both confidentiality and integrity. Without integrity checking, an attacker could modify encrypted data and the system would silently decrypt garbage. GCM's authentication tag catches any modification.

PBKDF2 Parameters

• Algorithm: PBKDF2-SHA256
• Iterations: 100,000
• Salt: 32 bytes (random, per-user)
• Output: 256-bit key

100,000 iterations adds ~100ms to login time but makes brute-forcing the password exponentially harder.

What I Would Do Differently

If I were rebuilding this today, I would add Argon2id as a key derivation option alongside PBKDF2. Argon2 is memory-hard — resistant to GPU-based brute forcing in ways that PBKDF2 is not.