Diffie‑Hellman Key Agreement: Theory, Formula Derivation, and Java/Android Implementation

Privacy‑preserving computation refers to techniques that allow data analysis without exposing the original data, ensuring that data remains usable yet invisible during exchange. The Diffie–Hellman (DH) key agreement protocol is a classic security mechanism that enables two parties to establish a shared secret over an insecure channel without any prior shared information.

1. Origin of DH DH was proposed by Whitfield Diffie and Martin Hellman in 1976 as a method for secure key exchange.

2. Problem Solved It solves the problem of securely transmitting a symmetric encryption key (e.g., for AES) without sending the key itself over the network.

3. Principle Both parties agree on a large prime p and a primitive root g . Each side generates a private random number ( a for Alice, b for Bob) and computes a public value ( A = g^a mod p , B = g^b mod p ). After exchanging A and B , each side computes the shared secret K = B^a mod p = A^b mod p . The secret never travels over the network.

4. Example Walk‑through Assume Alice chooses p = 97 , g = 5 , private a = 123 . She computes A = 5^{123} mod 97 and sends A to Bob. Bob picks b = 456 , computes B = 5^{456} mod 97 , and sends B back. Both derive the same secret (e.g., 22 ).

5. Formal Derivation The article provides a step‑by‑step algebraic proof using modular arithmetic and the binomial theorem to show that (g^a)^b ≡ (g^b)^a (mod p) , confirming the equality of the two computed keys.

6. Practical Implementation – Server (Java)

// DHServer class skeleton
public class DHServer {
    /** Large prime p */
    private static final String SOURCE = "FFFFFFFFFFFFFFFFC90FDAA22168C234...FFFFFFFFFFFFFFFF";
    private BigInteger mP;
    private BigInteger mG;
    private int mServerNum;
    // ... initialization, generateBaseInfo(), processServerKey() methods
}

The server generates p , selects a suitable g , creates a random serverNum , and computes processedServerNum = g^{serverNum} mod p . The init() method returns a map containing p , g , serverNum , and processedServerNum .

7. Practical Implementation – Client (Android/Java)

// TiDHClient class skeleton
public class TiDHClient {
    private final int mClientNum;
    private BigInteger mP, mG, mProcessedServerNum, mProcessedClientNum, mKey;
    public TiDHClient() {
        mClientNum = new Random().nextInt(99999 - 10000) + 10000;
    }
    public String processKey(String p, String g, String processedServerNum) {
        mP = new BigInteger(p);
        mG = new BigInteger(g);
        mProcessedServerNum = new BigInteger(processedServerNum);
        mProcessedClientNum = mG.modPow(BigInteger.valueOf(mClientNum), mP);
        mKey = mProcessedServerNum.modPow(BigInteger.valueOf(mClientNum), mP);
        return mKey.toString();
    }
    public String getProcessedClientNum() {
        return mProcessedClientNum == null ? "" : mProcessedClientNum.toString();
    }
    public String getKey() {
        return mKey == null ? "" : mKey.toString();
    }
}

The client fetches p , g , and processedServerNum from the server, computes its own processedClientNum , sends it back, and finally obtains the shared secret key.

8. End‑to‑End Handshake Flow

Client requests p , g , and serverNum from the server.

Server creates and returns the base information.

Client computes processedClientNum and sends it to the server.

Server computes the final shared key using the received value.

Both sides now hold an identical secret that was never transmitted.

The same principle underlies TLS 1.3 handshakes, and variations such as DH‑RSA or placing the generation of p and g on either side are discussed.

By following the presented code, developers can build their own SDK for secure data transmission, ensuring that the exchanged key cannot be captured or cracked.