End-to-End Encryption Without a Key Server

How I built a secure data vault where sensitive information is encrypted before it reaches the database—and the database never gets access to the user's actual data.

The Problem

When building My Data Manager, I was dealing with information that shouldn't be readable by anyone except the user—passwords, API keys, private notes, and other sensitive data.

The biggest question was simple:

What happens if someone gets access to the database?

Traditional applications often encrypt sensitive information on the server, which means the server still needs access to the encryption key. I wanted a stronger approach.

The goal was to make sure that even if the database were exposed, the stored information would still be useless without the user's master password.

There was also one important constraint:

I didn't want to depend on an external key-management service.

The encryption system needed to be self-contained.

The Approach

I designed the encryption flow so that sensitive data is encrypted on the client side before it is stored.

The basic flow was:

Master Password → Key Derivation → Encryption Key → Encrypt Data → Store Ciphertext

The database only receives encrypted data and the information needed to derive the key later.

The user's master password itself is never stored.

Deriving the Encryption Key

A password shouldn't be used directly as an encryption key. Instead, I used PBKDF2 to derive a 256-bit key from the user's master password.

Each user receives a randomly generated salt, which is stored separately in the database.

I used:

• PBKDF2
• SHA-256
• 200,000 iterations
• 32-byte key
• Random per-user salt

The important part is that the derived encryption key is never stored.

const key = crypto.pbkdf2Sync(
  password,
  Buffer.from(salt, 'hex'),
  200000,
  32,
  'sha256'
);

This means the same password produces a different derived key when used with a different salt.

Encrypting the Data

After deriving the key, I used AES-256-GCM to encrypt the user's sensitive information.

AES-GCM was useful here because it provides both:

• Encryption of the data
• Authentication to detect tampering

Instead of storing something like:

My API Key: sk-xxxxxxxx

the database contains encrypted ciphertext and the information required for decryption.

The actual plaintext never needs to be stored.

What Happens During Decryption?

When the user wants to access their data, the process happens in reverse.

Master Password → PBKDF2 → Encryption Key → AES-256-GCM Decryption → Original Data

The important part is that the correct master password is required to recreate the encryption key.

If the password is wrong, the encrypted data cannot be successfully recovered.

The Interesting Part

The most important design decision wasn't choosing AES.

It was deciding where the encryption key should exist.

I didn't want the database to contain the key.

I also didn't want the server to permanently hold the key.

Instead, the user's password acts as the starting point for recreating the encryption key when needed.

That creates a useful security boundary:

The database can store the encrypted information without being able to read it.

Testing the Security Model

I didn't want to assume the system was secure just because encryption was implemented.

I tested the actual stored data directly in the database.

The result was what I wanted:

There was no readable plaintext sensitive data in the database.

I also tested the recovery flow with the correct and incorrect master passwords to make sure that encrypted information could only be recovered through the expected authentication path.

The project was also reviewed as part of a university research project.

What I Learned

This project changed how I think about security.

Encryption isn't simply about adding an encryption function to an application. The bigger challenge is deciding:

• Where should the key exist?
• Who should be able to access it?
• What happens if the database is leaked?
• Can encrypted data be modified without detection?
• What information is safe to store alongside the ciphertext?

The implementation also made me much more conscious of the difference between authentication and encryption.

A user being authenticated doesn't automatically mean the application should have access to everything they own.

Outcome

The final implementation achieved the main goal:

• Sensitive data is encrypted before storage
• No plaintext sensitive information is stored in the database
• The master password is never stored
• PBKDF2 is used for password-based key derivation
• AES-256-GCM protects the stored data
• Data can only be recovered with the correct master password
• The implementation was reviewed as part of a university research project

The Takeaway

The biggest lesson from My Data Manager was that security has to be designed into the architecture from the beginning.

Instead of asking:

"How do I encrypt this data?"

I started asking:

"Who should be capable of reading this data in the first place?"

That shift in thinking led to a much stronger architecture—and made this one of the most valuable security-focused projects I've worked on.