Diffie-Hellman

Diffie-Hellman (DH) is a mechanism that allows two parties to create a shared secret over a public, insecure channel also known as a key exchange. Since all message exchanges are public the eavesdropper will not be able to determine the shared secret.

Both parties agree on a shared public base, which is known to everyone, including potential eavesdroppers. Each party then generates its own public key, which can also be shared openly. In addition, each party has a private key that is kept strictly secret and never transmitted.

A cornerstone of this mechanism is that deriving the private key from the public key is considered computationally infeasible, meaning it would take an impractically long time to compute.

Introduction

Charlie and Brianna want to establish a shared secret they need the following elements:

  • Public Base  Value that everyone (including an eavesdropper) can see

  • Private Key   Value is private (to only one party)  often a randomly generated number.

  • Public key     Value is calcualted from the private key and the base

Mixing

Charlie and Brianna to exchange their public keys (if they havent already in advance) keeping the public key secret adds a layer of obscuration. An eavesdropper now knows the public base and the public keys—but they still don't know the private keys.

  • Charlie Public Key     C-Pub     

  • Charlie Private Key    C-Priv

  • Public Base                 Base    

  • Brianna Public key     B-Pub

  • Brianna Private  key   B-Priv

  • Public Base                 Base

Q(x,y)
d
G(x,y) 

Expresison I: Charlie mixes his Private Key (C-Priv) with Briana’s Public key  (B-Pub)
Expresison II: Briana’s mixes her Private Key (B-Priv) with Charlie's Public key  (C-Pub)

The result is always the same identical secret and is a product of 3 keys.

ECC

The defacto standard for performing a Diffie-Hellman (DH) key exchange  is Elliptic Curve Cryptography (ECC).  The original DH protocol was built on the mathematics of finite fields, the industry has since  migrated to elliptic curves because its is currently the most effiicent in key sizes and computation.

Generator Point

The generator point G(x,y) base point on the eliptic curve is a constant value chosen by curve designer insitution NIST. Both parties and the public has this value its not a secret. A public key is produced my multiplying the privatekey with generator. Q = d x G

Charlie’s Keys

FileEditViewProject
keys.c — Charlie's Cryptographic Keys
uint8_t C_priv[32] = { // Charlies Private Key
0x39, 0xda, 0x1a, 0x3e, 0x3c, 0xbc, 0xd0, 0xe5, 0xc7, 0x82, 0x44, 0x0c, 0xdf, 0x30, 0xee, 0xf9,
0x7e, 0xa5, 0x29, 0x49, 0x78, 0xa6, 0x49, 0x8e, 0x9c, 0x7e, 0x0d, 0x33, 0x3f, 0xac, 0x6b, 0xf0
};
uint8_t C_pub[64] = { // Charlies Public Key
0x5c, 0x2d, 0x86, 0x5f, 0x44, 0xe6, 0xce, 0x6c, 0xa2, 0x32, 0x71, 0xf5, 0x2e, 0x02, 0x79, 0x33,
0x06, 0x48, 0x08, 0xb3, 0xc7, 0x6e, 0xf2, 0xb2, 0xe7, 0x53, 0xe2, 0xa5, 0xd3, 0xfc, 0x16, 0x15,
0xae, 0xe8, 0x92, 0xd2, 0x16, 0xa2, 0x8b, 0x4e, 0x1a, 0x29, 0x9e, 0x94, 0x58, 0xe2, 0x2b, 0x0c,
0x74, 0xd4, 0x0d, 0xdc, 0x48, 0x4c, 0x9d, 0xf3, 0xe4, 0x40, 0x57, 0xe3, 0x90, 0xf9, 0x96, 0xcc
};

Charlie has generated a P256 public key from his private key using the generator point G(x,y) and the elliptic curve. He can now safely send his public key to Briana. 

Briana’s Keys

FileEditViewProject
keys.c — Briana's Cryptographic Keys
uint8_t B_priv[32] = { // Brianas Private Key
0xba, 0x36, 0x17, 0x44, 0xe4, 0x9b, 0x2a, 0x2d, 0xca, 0x83, 0xb9, 0x95, 0x5f, 0x78, 0x91, 0x51,
0xd0, 0x87, 0xf1, 0xf8, 0x3a, 0x9b, 0x36, 0x37, 0xd8, 0x8e, 0xab, 0x46, 0xbc, 0x43, 0x2f, 0x23
};
uint8_t B_Pub[64] = { // Brianas Public Key
0x40, 0x34, 0x99, 0x9c, 0x87, 0x54, 0x46, 0x70, 0x22, 0xe5, 0x13, 0x33, 0xd9, 0x5e, 0xfe, 0x00,
0x7e, 0x5e, 0x99, 0xaa, 0xaa, 0x76, 0x33, 0x7f, 0x30, 0xcc, 0xf2, 0x03, 0x32, 0x7f, 0xbe, 0x2f,
0x97, 0x1e, 0x25, 0x77, 0x93, 0x21, 0x69, 0x72, 0x3e, 0x75, 0x4e, 0x27, 0xec, 0x0a, 0x96, 0x05,
0x84, 0xb2, 0xed, 0xf6, 0x94, 0xd5, 0xe7, 0xb3, 0xc5, 0xfb, 0x01, 0x64, 0x08, 0x13, 0x69, 0x96
};

Briana has generated a P256 public key from her private key using the generator point G(x,y) and the elliptic curve. She can now safely send his public key to Charlie. 

Shared Secret

FileEditViewProject
ecdh.c — Shared Secret Generation
uint8_t charlie_secret[32]; uint8_t briana_secret[32];
p256_ecdh_shared_secret(charlie_secret, C_priv, B_Pub);
p256_ecdh_shared_secret(briana_secret, B_priv, C_pub);
Radikant
File
Edit
View
Window
Help
p256_ecdh.log
Charlie Secret: : b1aeec16463f2b0f18a82acc8add7b15f84e79403fae82a1b33e59a33841b386 Briana Secret: : b1aeec16463f2b0f18a82acc8add7b15f84e79403fae82a1b33e59a33841b386

Once Charlie and Briana mix their keys (see Expression I & II) the resulting shared secret is identical. They have never shared sensitive information to the public or an eavesdropper. They can now use this secret generate a key and use it to encrypt their communication using a cryptographic cipher.

Shared key

ECDH is not used to encrypt information it sole purpose is to establish a shared secret between two parties withouth eavesdropping because no sensitive information is ever transmitted. The shared key is just an x coordinate of a point P(x,y) on the eliptic curve. For an eliptic curve there are two possible y values both parties generate P(x,y) point. For common usecases the P(y) value is disregarded.

KDF

The size of the shared secret will depend on the exact curve used. P256 (secp256r1) generates a 256 bit shared secret, P521 (secp521r1) respectively generates a 521 bits key. Using AES256 technically would technically allow to use the 256 shared secret directly as a key for AES Encryption but since it reveals some information you would want an Key Derrivation Function KDF to transform the secret into an random looking cryptograhic key.