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 and Bob generates:
  • 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