Implementation Session — Securing Frontend & Backend with Diffie-Hellman : Session 5

This was the fully hands-on counterpart to the earlier Diffie-Hellman theory session, where participants implemented a live key exchange between a frontend client and a backend server. The session covered the full workflow — parameter agreement, key pair generation, network exchange, shared secret derivation, and symmetric key usage — while directly confronting the man-in-the-middle vulnerability from Session 2 with real mitigation techniques like public key authentication and forward secrecy.

Building directly on the theory from Session 2, this was a fully hands-on implementation session. The group set up a simple client-server architecture where the frontend (browser/client application) and backend (server) needed to establish a shared secret over the network without ever transmitting that secret directly.

The implementation walkthrough covered:

Parameter agreement — the server generating (or using a well-known standard) prime p and generator g, and sharing these publicly with the client.

Key pair generation — both client and server independently generating their own private/public key pairs (a/A on the client, b/B on the server).

Exchange over the network — the client sending its public value A to the server via an API call, and the server responding with its public value B.

Shared secret derivation — both sides independently computing the same shared secret (g^(ab) mod p) without it ever being transmitted.

Deriving a symmetric key — passing the raw shared secret through a Key Derivation Function (KDF) to produce a proper symmetric encryption key, rather than using the raw DH output directly.

Using the derived key — encrypting subsequent frontend-backend traffic (e.g., using AES-GCM) with the derived symmetric key.

The session explicitly revisited the man-in-the-middle vulnerability flagged in Session 2, and discussed practical mitigations used in real systems:

Authenticating the exchanged public keys — e.g., signing the DH public value with a long-term identity key (this is effectively what TLS does with certificates) so a client can verify it's really talking to the legitimate server and not an attacker.

Using TLS itself — noting that in most production systems, DH/ECDH key exchange already happens inside the TLS handshake, so a custom implementation like this is primarily useful as a learning exercise or for scenarios requiring an additional application-layer secure channel.

Avoiding common mistakes — such as reusing the same DH private key across sessions (reducing forward secrecy), using weak or non-standard parameters, and failing to validate that received public values are within the correct mathematical range (to prevent invalid-parameter attacks).

The group also discussed forward secrecy — using ephemeral (session-specific) DH key pairs so that even if a long-term key is later compromised, past session communications remain secure because the ephemeral keys used to derive past shared secrets were never stored.

Outcome :

Built and tested a working DH-based key exchange between a frontend and backend.

Understood why raw DH output should be passed through a KDF before use as an encryption key.

Learned concrete mitigations for the man-in-the-middle vulnerability, including public key authentication.

Understood the concept and importance of forward secrecy using ephemeral key pairs.

 

This was the practical, applied counterpart to the theoretical Diffie-Hellman session, demonstrating exactly how the protocol is deployed in a real frontend-backend architecture, and directly confronting the authentication limitations discussed earlier with concrete mitigation strategies.