Key Exchange
- Two parties need to agree on a secret key without revealing it to the public or hacker
- Assume Alice and Bob have secret number
s1 and s2 resp.
- Let’s agree on a public number:
p
- Step 1:
- Alice:
s1, p
- Bob:
s2, p
- Hacker
p
- Step 2:
- Alice sends:
s1 + p ⇒ Bob
- Bob sends:
s2 + p ⇒ Alice
- Hacker:
p, s1 + p, s2 + p
- Step 3:
- Alice generates:
s1 + <Bob message> = s1 + (s2 + p)
- Bob generates:
s2 + <Alice message> = s2 + (s1 + p)
- Final Secret Key:
s1 + s2 + p
- Security issue:
- Hacker can access In-transit values:
p
- Alice ------
s1 + p⇒ Bob
- Alice ⇐—
s2 + p---- Bob
- Hacker can then find the original value by reversing the addition operation
- Alice original key =
<Alice message> - p = (s1 + p) - p = s1
- Bob original key =
<Bob message> - p = (s2 + p) - p = s2
Diffie Hellman Key Exchange
- aka DHKE or DH
- We want the reversing operation to be harder, this uses modulo operations
- Assume Alice and Bob have secret number
s1 and s2 resp.
- Let’s agree on public numbers:
b (base), p (modulo)
- Alice and Bob sends
Alice to Bob: bs1modpBob to Alice: bs2modp
Alice generates Bob generates Final Secret Key=(Bob’s message)s1modp=(bs2)s1modp=(Alice’s message)s2modp=(bs1)s2modp=b(s1⋅s2)modp
- Hacker has:
b, p, b^s1 mod p, b^s2 mod p
- It is difficult for hacker to reverse the operation to derive
s1 or s2
- Notice:
- May require lot of modulo calculations
p is generally chosen to be prime to make it stronger
- Achieves forward secrecy, hence used to generate secret key in a session
- Advanced version is ECDH (Elliptic Curve DH)
- Disadvantages:
- Vulnerable for Man in the middle Attack (MITM) where the attacker can impersonate Bob/Alice to both sides and generate keys
- Hence it is needed to exactly know whether the sender really was Alice or Bob not
- References