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: 100Private key (Alice) 49ed920273c9493bbb8f012bedb1e8cc987ea209ad66066079e9ea4e535fa63fPrivate 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:

Professor of Cryptography. Serial innovator. Believer in fairness, justice & freedom. EU Citizen. Auld Reekie native. Old World Breaker. New World Creator.

More from Prof Bill Buchanan OBE

Professor of Cryptography. Serial innovator. Believer in fairness, justice & freedom. EU Citizen. Auld Reekie native. Old World Breaker. New World Creator.