Defining the trust boundary
A secure file vault should not require the storage provider to read every file. I built the Encrypted File Vault as an open-source prototype that encrypts content on the client before upload. That decision changes the trust model: S3 stores ciphertext, while access to the application alone does not reveal the original file without the correct key material.
Encryption and key derivation
The vault uses AES for file encryption and PBKDF2 to derive per-user keys. A unique salt and appropriate work factor make password guessing more expensive, but the design still depends on strong user credentials and careful key handling. The server coordinates metadata and authorization without treating encryption as a replacement for access control. Cryptography protects content, while authorization decides who may request it.
Safe storage and delivery
Files move through S3 using short-lived presigned URLs rather than permanent public links. Role-based access control restricts user and administrative actions, and audit logging records important events. The admin dashboard supports oversight without exposing plaintext file content. I also considered upload validation, object naming, retention, and the consequences of a lost key.
What the project clarified
The vault taught me that secure storage is a system, not an AES call. Key recovery, browser security, metadata leakage, sharing, and deletion all affect the real protection. A prototype can demonstrate the architecture, but production use would require formal threat modeling, cryptographic review, recovery design, and extensive testing across the entire file lifecycle.