How End-to-End Encryption Works: Building a Secure Chat App From Scratch

js

How End-to-End Encryption Works: Building a Secure Chat App From Scratch

Learn how end-to-end encryption secures chat apps with key exchange, double ratchet, and AES-GCM. See the core system in action.

Apr 6, 2026

How End-to-End Encryption Works: Building a Secure Chat App From Scratch

I’ve been thinking a lot about digital privacy lately. Not in an abstract, headline-reading way, but in a deeply practical one. It started when a friend, a journalist working on a sensitive story, asked me a simple question: “How do I know my chat app is actually secure?” I realized I couldn’t give a simple answer without explaining the entire machinery working under the hood. Most of us use apps with “end-to-end encryption” labels, trusting that our conversations are private. But what does that actually mean? What magic happens between hitting ‘send’ and the message appearing on your friend’s screen? I decided to strip away the marketing and build the core of that system myself, to truly understand it. Let’s walk through what I learned.

Forget complex libraries for a moment. The goal is clear: two people, Alice and Bob, should be able to exchange messages. A server should help them connect, but it should never, at any point, have the ability to read their conversation. This is the heart of end-to-end encryption. The server is just a messenger; it carries a locked box without holding the key.

So, how do we create a lock and key that only Alice and Bob possess, especially if they’ve never met before to exchange secrets? This is the first major puzzle. If we use one permanent key, and it’s ever compromised, every past and future message is exposed. Have you ever considered that your encrypted messages from years ago might not be safe today with some systems? We need a method that constantly changes the keys.

The answer starts with a handshake, but not a simple one. We use a method inspired by the Signal Protocol, which powers many major apps. First, every user generates a permanent “Identity Key.” Think of this as your long-term cryptographic fingerprint. Then, they also generate temporary “Pre-Keys” and leave them on the server, like a set of numbered, sealed envelopes.

When Alice wants to talk to Bob for the first time, she asks the server for one of Bob’s sealed pre-key envelopes. She uses a combination of her identity key, Bob’s identity key, and this temporary pre-key to perform a special calculation called a Diffie-Hellman key exchange. This calculation allows two parties to create a shared secret over a public channel. The result is a “Root Key” and a “Chain Key” that only Alice and Bob can derive. The server, which facilitated the exchange, was never involved in the calculation and has no access to the result. The lock is created.

Now, let’s look at some code to make this tangible. We’ll use the Web Crypto API, which is built into modern Node.js. First, generating that crucial identity key pair:

async function generateIdentityKeyPair() {
    const keyPair = await crypto.subtle.generateKey(
        {
            name: "ECDH",
            namedCurve: "P-256",
        },
        true, // Make it extractable so we can store it
        ["deriveKey"]
    );
    return keyPair;
}

But we’re not done. What if someone steals Alice’s phone and gets her current keys? Would they be able to decrypt future messages? This is where the “Double Ratchet” comes in. It’s a beautiful piece of engineering that ensures “forward secrecy.” With every message sent or received, the keys ratchet forward, changing. Imagine a combination lock that automatically scrambles itself after each number is dialed.

Here’s the essence of it. Each message gets its own unique “Message Key,” derived from the current Chain Key. After deriving the message key, the Chain Key is updated. This means each message key is used once and then thrown away. If you compromise a key, you can only decrypt that single message, not the entire conversation. The sending and receiving chains ratchet independently, handling out-of-order messages gracefully. Can you see how this turns a static secret into a flowing, evolving river of secrecy?

Let’s implement a simple ratchet step for the sending chain:

async function ratchetChainKey(chainKey) {
    // We use HMAC-based Key Derivation (HKDF) to get new keys
    const newChainKey = await crypto.subtle.sign(
        "HMAC",
        chainKey,
        new TextEncoder().encode("chain_key_update")
    );
    const messageKey = await crypto.subtle.sign(
        "HMAC",
        chainKey,
        new TextEncoder().encode("message_key")
    );
    return { newChainKey: newChainKey, messageKey: messageKey };
}

Finally, we need to actually encrypt a message. We use the disposable message key with a strong algorithm like AES-GCM, which provides both confidentiality and authentication. This means the recipient can be sure the message wasn’t tampered with.

async function encryptMessage(text, messageKey) {
    const iv = crypto.getRandomValues(new Uint8Array(12)); // Unique for each message
    const encodedText = new TextEncoder().encode(text);

    const ciphertext = await crypto.subtle.encrypt(
        {
            name: "AES-GCM",
            iv: iv
        },
        messageKey,
        encodedText
    );

    return {
        iv: Array.from(iv), // Send the IV with the ciphertext
        ciphertext: Array.from(new Uint8Array(ciphertext))
    };
}

On Bob’s side, the process is reversed. He uses his private keys to perform the same initial handshake calculation, arriving at the same shared root. He then follows the ratcheting steps, deriving the same sequence of message keys to decrypt each message. The server only ever sees the public keys and the encrypted payloads—the opaque locked boxes.

Building this was an eye-opener. Security isn’t a feature you bolt on; it’s a fundamental architecture you build from the ground up. It requires careful thought about key management, state, and recovery. The next time you see “end-to-end encrypted,” you’ll know there’s a sophisticated dance of keys and ratchets happening silently in the background, protecting your words. It’s not magic; it’s mathematical certainty applied with careful engineering.

I hope this journey into the core of private messaging was as enlightening for you as it was for me. What part of this process surprised you the most? If you found this breakdown helpful, please share it with a curious friend or leave a comment with your thoughts below. Let’s keep the conversation about digital privacy open and informed.

As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!

101 Books

101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.

Check out our book Golang Clean Code available on Amazon.

Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!

📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!