DEV Community

Cover image for πŸ”’ How We Built a Zero-Knowledge End-to-End Encryption for upcoming ViClip v2
Vaibhav Mishra
Vaibhav Mishra

Posted on

πŸ”’ How We Built a Zero-Knowledge End-to-End Encryption for upcoming ViClip v2

When dealing with sensitive clipboard data, security is paramount. We implemented a Zero-Knowledge Architecture using military-grade AES-256-GCM encryption.

Let’s be honest: trusting servers with sensitive data is outdated. When I started building my clipboard manager app, I knew I had a major problem. People copy passwords, API keys, private messages, and sensitive personal information all day long.

If my database got hacked, or a rogue employee looked at the database, I would be exposing everyone's deepest secrets.

The solution? Zero-Knowledge End-to-End Encryption (E2EE).

"Zero-Knowledge" sounds like a fancy buzzword, but the concept is beautifully simple: The server never sees your data, and it never sees your password. Even if my entire database is stolen, the attacker walks away with absolutely nothing but scrambled gibberish.

Here is exactly how I built it using industry-standard AES-256-GCM encryption, explained so clearly that anyone can understand it.


πŸ”‘ The Core Ingredients

We use a "Two-Key" architecture. Why two keys? Because you never want to use your actual password to encrypt your data. If you change your password, you'd have to re-encrypt gigabytes of data!

Instead, we use these four components, managed entirely on your local device:

  1. DEK (Data Encryption Key): This is the VIP. A randomly generated 32-byte master key. It does the heavy lifting of locking and unlocking your actual clipboard data. The raw version of this key never leaves your device.
  2. Salt: A random string unique to you. It makes your password virtually impossible to guess via brute force.
  3. KEK (Key Encryption Key): A temporary key derived from mathematically mixing your Password + Salt 100,000 times (using PBKDF2). We only keep this in memory for a split second.
  4. Wrapped DEK: Your master DEK, locked securely inside a box using your KEK as the padlock.

Step 1: Registration (Generating the Keys)

When you sign up, the magic happens entirely locally on your machine before anything touches the internet.

registration

What just happened?

  1. We gave you a random master key (DEK) to encrypt your data.
  2. We used your password to create a separate key (KEK).
  3. We used that KEK to lock your master key in a box.
  4. We sent only the locked box to the database. The server has no idea what is inside or how to open it.

Step 2: Login (Unlocking the Master Key)

Say you log in on a brand-new computer. Your new computer needs your master key to read your data, but the server only has the locked box. Here is how your device retrieves it:

login

What just happened?
The app downloads your locked box (Wrapped DEK) from the server. Using the password you just typed in, the app recalculates your KEK and uses it to unlock the box locally. Boom! Your new device has the master key.


Step 3: Syncing Data (The Fun Part)

Now that your device has the master key (DEK) unlocked in memory, every time you copy text, it gets scrambled before it ever touches the WiFi.

We use AES-256-GCM, the exact same encryption standard used by banks and the military.

syncing

What just happened?
Every time you copy something, the text is combined with your master key and a random "Initialization Vector" (IV) (which ensures the same text never encrypts to the same ciphertext twice).

We upload only the scrambled gibberish to the cloud. When your phone downloads the record, it uses its locally stored master key to instantly decrypt the data back into readable text.


πŸ›‘οΈ The Bottom Line

  • What my server knows: You exist, your email, and a bunch of scrambled data.
  • What my server DOES NOT know: Your password, your actual encryption keys, or what you are copying.

Zero-Knowledge architecture might seem intimidating, but when you break it down, it is just a clever series of digital locks and keys. By shifting the encryption burden to the client (your device), we eliminate the server as a single point of failure.

Are you building an app that handles sensitive user data? Stop storing it in plaintext! If you have any questions about implementing AES or KEK/DEK architectures in Javascript/TypeScript, drop a comment below!

Top comments (0)