# Handshaking Keys for Privacy with ECDH … Let’s “Go” Create It!

A fundamental part of creating a secure tunnel — such as with HTTPs — is that the client and server generate the same shared symmetric key (typically with the AES method), and that they use this to encrypt the data passed.

In days of old, the HTTPs key exchange method was the horrible RSA encryption technique. With this, the RSA public key of the server — and which was contained on the digital certificate passed from the server to the client — was used to encrypt the session key to be used and send back the server. The server then decrypted this with its private key. The client and the server then have the same shared encryption key. But this method has a major fault … if someone discovers the private key of the server, they can decrypt all of the secret communications.

And so, with TLS 1.3, the old public key encryption method of key exchange has been dumped, and the only show in town is **ECDH** (Elliptic Curve Diffie Hellman). Why? Because only the client and the server know the key used. Once the session is finished, the key is gone, and a new one is created for the next session. So, in this article, I will show how we use the **Go programming language** to create the parameters required for the key exchange. The demo is here:

We will use the Go programming, and the P-256 elliptic curve. The value of **priva** will be the private key of Alice, and **privb** will be the private key of Bob for the session. Their public keys will be **puba** and **pubb**, respectively (and which are their private key values multiplied by a base point (Gx,Gy).

Bob passes his public key (pubb) to Alice, and she passes her public key to Bob (puba).

Alice computes the shared key by taking Bob’s public key (pubb) and multiplying it with her private key (priva). Bob also computes the same shared key by taking Alice’s public key (pubb) for the session and multiplying it with his private key (privb). They should then end up with the same shared secret (and which is a hash of the resultant value). If a 256-bit key is required, then we use SHA-256 [demo]:

The following is a sample run. We can see we are using the P-256 elliptic curve which has a (Gx,Gy) base point and where we use the prime number P:

Private key (Alice) cca00b8290819e15451bf8e551cb0e5fc08c22647b5d99437c3c0f8a25abbbd3

--ECC Parameters--

Name: P-256

N: ffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551

P: ffffffff00000001000000000000000000000000ffffffffffffffffffffffff

Gx: 6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296

Gy: 4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5

Bitsize: 100

Private key (Alice) 49ed920273c9493bbb8f012bedb1e8cc987ea209ad66066079e9ea4e535fa63f

Private key (Bob) bce5a446ce1d2632e9b12be975e62cfa2bd93825e7b63533ba746ee6ee6e99adShared key (Alice) 8b48614129b344d81cc550643a1a480c7e26a5db3b84f8318ac49b6d48d3a4feShared key (Bob) 8b48614129b344d81cc550643a1a480c7e26a5db3b84f8318ac49b6d48d3a4fe

## Elliptic Curve Diffie Hellman (ECDH)

ECDH is used to create a shared key. Bob will generate a public key and a private key by taking a point on the curve. The private key is a random number (*dB*) and the Bob’s public key (*QB*) will be:

*QB*=*dB*×*G*

Alice will do the same and generate her public key (*QA*) from her private key (*dA*):

*QA*=*dA*×*G*

They then exchange their public keys. Alice will then use Bob’s public key and her private key to calculate:

SharekeyAlice=*dA*×*QB*

This will be the same as:

SharekeyAlice=*dA*×*dB*×*G*

Bob will then use Alice’s public key and his private key to determine:

SharekeyBob =*dB*×*QA*

This will be the same as:

SharekeyBob=*dB*×*dA*×*G*

And the keys will thus match.

The following illustrates the process: