Results of some basic experiments with the Diffie-Hellman Key Exchange System. I analyse the key-exchange algorithm using brute-force as well using the Baby-step Giant-step algorithm.

1. On Deriving the Private Key
from a Public Key
Basic Experiments with the Diffie-Hellman System
Dr. Dharma Ganesan, Ph.D.,

2. Disclaimer
● The opinions expressed here are my own but not the views of my employer
● The source code fragments shown here can be reused but
○ without any warranty nor accept any responsibility for failures
● Do not apply the exploit discussed here on other systems
○ without obtaining authorization from owners
2

3. Context
● The problem discussed here is given by a Cryptographer (Prof. Dan Boneh)
○ I performed this experiment to harden my under-the-hood Cryptography foundation
○ Applied Cryptography is an essential component of my professional work, too
● The key exchange system is Diffie-Hellman Public Key Cryptography
○ More details later
○ Alias: Diffie-Hellman (DH) or Diffie-Hellman-Merkle System
● The problem is to mechanically derive the private key given a public key
3

4. Agenda
● Overview of the DH key exchange system
● Breaking the DH system using Bruteforce
● Applying Baby-step Giant-step Algorithm to break the DH system
● Limitations of Baby-step Giant-step Algorithm
4

5. Prerequisite
The slides assume that the reader is comfortable with the basics of
● Group Theory (Abstract Algebra/Discrete Math)
● Modular arithmetic principles (Number Theory)
● Algorithms and Complexity Theory
● Probability Theory
● If not, it should still be possible to obtain a high-level overview
5

6. How can Alice and Bob agree on a common key K
for symmetric encryption/decryption?
6
Key K Key K
● Alice and Bob never met each other
● Alice will encrypt using the key K
● Bob will decrypt using the same key K
● But how will Alice and Bob agree on
the same key K?

7. Diffie-Hellman Key Exchange
● Invented in 1970s
● Solved the problem of symmetric key exchange over a public channel
○ Rooted in elegant mathematics (details later) - Finite Field
● Alice and Bob arrive at a shared key for encryption/decryption using math
● Eavesdropper Eve cannot easily derive the shared key
○ unless she solves hard math problems that are computationally intractable
7

8. Diffie-Hellman Key Exchange (Basic Version)
● Let G be a finite cyclic group of order p (prime)
● Let g be a generator of G
● Let Alice and Bob are two parties who want to communicate securely
● Keys of Alice:
○ Private key is a which is a random element of group G
○ Public key is ga
○ <ga
, a> is the public and private key pair of Alice
● Keys of Bob:
○ Private key is b which is a random element of group G
○ Public key is gb
○ <gb
, b> is the public and private key pair of Bob
8

9. Assumptions of the Basic Version
● Alice and Bob authenticate each other through other means
○ For example, using digital certificates, out of band shared key, etc.
● Attackers can only eavesdrop the public channel
● Attackers are not allowed to edit data exchanged over the public channel
9

10. Deriving the Shared Key for Encryption/Decryption
● Alice publishes A = ga
mod p
● Bob publishes B = gb
mod p
● Alice computes Key K = Ba
= (gb
)a
mod p
● Bob computes Key K = Ab
= (ga
)b
mod p
● Since (gb
)a
= gba
= (ga
)b
, both users have the same shared key K = gab
○ It is remarkable that a simple exponentiation property solves the key exchange problem
10

11. ● g, A= ga
, B= gb
, and p are public
○ Attackers can see values
● a and b are private
○ Never sent out by Alice and Bob
11

12. Exponents grow so fast (240
has 13 digits-10 trillions)
dharma@kali:~/crypto# java Growth 41
2 power 0:1:1
2 power 1:2:1
2 power 2:4:1
2 power 3:8:1
2 power 4:16:2
2 power 5:32:2
2 power 6:64:2
2 power 7:128:3
2 power 8:256:3
2 power 9:512:3
2 power 10:1024:4
2 power 11:2048:4
2 power 12:4096:4
2 power 13:8192:4
2 power 14:16384:5
2 power 15:32768:5
2 power 16:65536:5
2 power 17:131072:6
2 power 18:262144:6
2 power 19:524288:6
2 power 20:1048576:7
2 power 21:2097152:7
2 power 22:4194304:7
2 power 23:8388608:7
2 power 24:16777216:8
2 power 25:33554432:8
2 power 26:67108864:8
2 power 27:134217728:9
2 power 28:268435456:9
2 power 29:536870912:9
2 power 30:1073741824:10
2 power 31:2147483648:10
2 power 32:4294967296:10
2 power 33:8589934592:10
2 power 34:17179869184:11
2 power 35:34359738368:11
2 power 36:68719476736:11
2 power 37:137438953472:12
2 power 38:274877906944:12
2 power 39:549755813888:12
2 power 40:1099511627776:13
12

13. But Exponentiation is very fast to compute
● On my laptop, I can compute 25000
in ~0.15 sec; 25000
has 1506 digits
○ Thanks to Java’s BigInteger class
13

14. My little Exponent Wrapper Code
import java.math.BigInteger;
public class Power {
public static void main(String[] args) {
if(args.length != 2) {
System.err.println("Usage: java Power <base> <exponent>");
System.exit(1);
}
BigInteger base = new BigInteger(args[0]);
int exponent = Integer.parseInt(args[1]);
BigInteger basePowExp = base.pow(exponent);
System.out.println(base + " power " + exponent + " = " + basePowExp.toString() + ":"
+ basePowExp.toString().length());
}
}
14

15. Exponentiation in a Finite Group is very fast, too
We can compute (22
)5000
mod 100000 in 0.13s on a laptop
15

16. My little Modular Exponent Wrapper code
import java.math.BigInteger;
public class ModPower {
public static void main(String[] args) {
if(args.length != 3) {
System.err.println("Usage: java ModPower <base> <exponent> <mod>");
System.exit(1);
}
BigInteger base = new BigInteger(args[0]);
BigInteger exponent = new BigInteger(args[1]);
BigInteger m = new BigInteger(args[2]);
BigInteger basePowExp = base.modPow(exponent, m);
System.out.println(basePowExp.toString());
}
}
16

17. Complexity of Modular Exponentiation
● We need to compute gx
mod p for some random x in a finite field
● gx
can be calculated in the order of log2
(x);
○ The complexity is O(log2
x)
● For example, 232
can be calculated just using 5 multiplications
○ Right-to-left binary method is a classical method for modular exponentiation
● It is easy to calculate gx
mod p for very large x
○ For example, if x = 2200
then gx
can be computed with just 200 multiplications
● Both Alice and Bob do not have to perform many multiplications!
○ Generating public keys is fast even for very large x
○ In ~0.15 sec, Alice and Bob can compute modular exponentiation
17

18. Threat Model of the Key Exchange Method
● Given <g, ga
, gb
>, the attackers’ goal is to compute gab
, the encryption key
○ gab
also called the shared session secret key
● If gab
can be computed efficiently, the game is over because it is the
encryption key
○ Equivalently, there is no confidentiality if gab
can be computed in a short time
● If the attackers can compute a from ga
, then they compute gab
immediately
○ Similarly, if b is computable from gb
, gab
is also immediately available
18

19. Complexity of Reverse Exponentiation
● Given h = gx
mod p, we can bruteforce for all x until a suitable h is found
● Brute-force is linear in the order of the group (experimental details later)
○ Not practical for very large group of order, say 2100
or more
● Reverse of a modular exponentiation is a “hard” CS/Math problem
○ No publicly known algorithm can find x in a reasonable amount of time for very large groups
ExponentiationReverse
Exponentiation
19

20. General Problem Statement
● Given a finite cyclic group of order p, generator g, the public key h, find the
private key x.
● That is, given h = gx
mod p, the goal is to find x
● This problem is called the discrete logarithm problem in CS/Math
20

21. Simplified Problem Statement
Write a program to compute discrete log modulo a prime p.
Let g be some element in Z*
p
and suppose you are given h in Z*
p
such that h=gx
where 1≤x≤240
. Your goal is to find x. More precisely, the input to your program is
p,g,h and the output is x.
Z*
p
denotes a finite integer cyclic group of order p
❖ Let’s crack it using Baby-step Giant-step algorithm (implementation in Java)
21

22. Brute-force/naive Exponent Search Code
Given a finite cyclic group of order p, generator g, the public key h, find the private key x by brute-forcing
to break the Diffie-Hellman for exponents less than the given bound.
public static long search(BigInteger p, BigInteger g, BigInteger h, long bound) {
for(long x = 0; x < bound; x++) {
BigInteger gRaisedx = g.modPow(BigInteger.valueOf(x), p);
if(gRaisedx.equals(h)) {
return x;
}
}
return 0;
}
22

23. Junit test client for brute-force search
public class DiscreteLogTestBF extends
TestCase{
public void testRecoverExponent() {
BigInteger p = new
BigInteger("13407807929942597099574024998
205846127479365820592393377723561443721
764030073546976801874298166903427690031
858186486050853753882811946569946433649
006084171");
BigInteger g = new
BigInteger("11717829880366207009516117596
335367088558084999998952205599979459063
929499736583746670572176471460312928594
829675428279466566527115212748467589894
601965568");
BigInteger h = new
BigInteger("32394751040504504435652643787
280657886490975209524495278347924529719
819761432925580738569379585531805328789
280014947060973941085775857324523076734
44020333");
/* Assume that the exponent is bounded by 2
power 40.
*/
long bound = (long) Math.pow(2, 40);
long x = DiscreteLogBF.search(p, g, h,
bound);
BigInteger gRaisedx =
g.modPow(BigInteger.valueOf(x), p);
assert gRaisedx.equals(h);
}
} 23

24. Brute-force - didn’t work even after ~10 hrs
● Brute-force is hopeless to solve the discrete log problem
● I had to press ctrl+c to terminate the program after ~10 hrs
dharma@kali:~/crypto# time junit DiscreteLogTestBF
^C
real 550m57.510s
user 549m19.944s
sys 0m31.444s
24

25. Baby-step Giant-step algorithm
● Assume that the unknown x < 2n
, for a given n > 0
● The exponent is rewritten using smaller numbers
○ where B = ⌈√2n
⌉, and x0
, x1
in [0, B-1]
○ Split the exponent into two sides
● Phase1:Built a hashtable of the left-hand side(LHS)
○ Map from h/gxi
to xi
○ Key-value pair: h/gxi
→ xi
● Phase2: For each x0
compute the RHS and
○ search until the RHS is part of the hashtable
■ compute x using known values x0
, x1
, and B
● Alias: Meet-in-the-middle attack
25

26. Baby-step Giant-step implementation - phase 1
26
BigInteger findExponent(BigInteger p, BigInteger g, BigInteger h, long bound) {
Hashtable<BigInteger, Long> hashtable = new Hashtable<BigInteger, Long>();
BigInteger gRaisedB = g.modPow(BigInteger.valueOf(bound), p);
BigInteger x = BigInteger.ZERO;
for(long x1 = 0; x1 < bound; x1 = x1+1) {
BigInteger lhs = g.modPow(BigInteger.valueOf(x1), p).
modInverse(p).multiply(h).m
hashtable.put(lhs, x1);
}
Baby-step: Building a
hashtable between h/gx1
and x1

27. Baby-step Giant-step implementation - phase 2
for(long x0 = 0; x0 < bound; x0 = x0 + 1) {
BigInteger rhs = gRaisedB.modPow(BigInteger.valueOf(x0), p);
if(hashtable.get(rhs) != null) {
System.out.println("x0 = " + x0 + " x1 = " + hashtable.get(rhs));
x = BigInteger.valueOf(bound * x0 + hashtable.get(rhs));
break;
}
}
return x;
} giant-step: Searching
whether (gB
)x0
exists in the
baby-step hashtable
27

28. Given public parameters p, g, and h, find x (private)
public void testRecoverExponent() {
BigInteger p = new
BigInteger("134078079299425970995740249982058461274793658205923933777235614437217640300735469768
01874298166903427690031858186486050853753882811946569946433649006084171");
BigInteger g = new
BigInteger("117178298803662070095161175963353670885580849999989522055999794590639294997365837466
70572176471460312928594829675428279466566527115212748467589894601965568");
BigInteger h = new
BigInteger("323947510405045044356526437872806578864909752095244952783479245297198197614329255807
3856937958553180532878928001494706097394108577585732452307673444020333");
long expMiddle = (long) Math.pow(2, 40/2);
BigInteger x = DiscreteLog.findExponent(p, g, h, expMiddle);
BigInteger gRaisedx = g.modPow(x, p);
System.out.println("Exponent x = " + x);
assert gRaisedx.equals(h);
}
● p, g, and h are about 150 digits
● The finite group size is 512 bits
28

29. Output: private key x such that h = gx
mod p
29
● On a DELL personal laptop it took only ~1.5 minutes to extract the private key
○ This includes the time to build the hash table and search
dharma@kali:~/crypto# time junit DiscreteLogTest
x0 = 357984 x1 = 787046
Exponent x = 375374217830 (i.e., 375 billion, 374 million, 217 thousand, and 830)
real 1m54.240s
user 1m56.588s
sys 0m0.416s

30. Scalability problems - out of Heap Memory
● The Baby-step builds a large hashtable
● I was curious how large the exponent I can handle on my laptop
● Tried for exponent x ≤ 250
● The Baby-step table will have at most 225
hash table entries
○ This is about 34 million entries (just too many)
● My Java JVM heap ran out of memory when x > 242
30

31. Scalability Problems - Out of Disk Memory
● I stored the hash table onto my disk
○ This storage strategy can break DH if x ≤ 254
● The Baby-step table will have at most 227
hash table entries
○ This is about 135 million entries (just too many)
● My disk ran out of memory, if x > 254
31

32. Complexity of Baby-step Giant-step algorithm
● Time complexity is the square root of order of the group: O(p1/2
)
● If the order is 240
, the private key can be computed in 220
operations
○ This is significantly better and faster than brute-force search
● But, in practice the order of the group is very large, for example, 2400
○ Then, the Baby-step giant-step will take 2200
operations (still a lot of time)
● This algorithm is promising but not scalable for very large groups
○ Java heap runs out of memory after storing 222
key-value pairs in memory
○ Distributed hashing or disk-based hashing could help but not dramatic (exponents grow fast)
● No easy way to recover the private key from a public key in general
32

33. Probabilistic Analysis
● The private key we reconstructed is x = 375374217830
● x = (101011101100110000011000000001001100110)2
● # of bits of x is only 39 bits
○ dharma@kali:~/crypto# echo -n "101011101100110000011000000001001100110" | wc -c
39
● Recall that our prime field’s order is 512 bits
● Prob (x < 240
) = 240
/2512
= 1/2472
○ There is a negligible probability that a random private key (or exponent) x is less than 240
● Popular libraries check whether the random exponent is very large
○ Otherwise, it is easy to derive the private key from the public key
○ Details given later
33

34. Distributed searching for private key (i.e. exponent)?
● Let’s assume the exponent strength is 160-bits (i.e. x < 2160
)
● Baby-step giant-step will need to build a hash table of 280
entries
● Based on this experiment, we can build a hash table of 227
per computer
○ Thus, we would need 280
/ 227
= 253
computers
● The world has about 231
= 2 billion computers (in 2017) but we need 253
computers
○ 253
= 9007199254740992
● In 231
computers, we can store 231
* 227
= 258
hash table entries
● If the exponent x is less than 2116
, we can use all computers in the world to
solve the discrete log problem
34

35. Similar Attacks - LogJam
● A team of Cryptographers used other discrete log algorithm to break DH
○ Number Field Sieve (NFS)
● Three major phases of NFS only depend on the order of group
○ Most implementations use well-known, published groups in RFC standards
● LogJam precomputes the computationally intensive phases upfront
● Finally, it uses session-specific parameters to find x such that h = gx
mod p
35

36. Do real implementations check the strength of the
Private Key (i.e., exponent x)?
36
○ It appears that Bouncy Castle implementation checks the strength of the random
number used as the private key
■ See DHKeyGeneratorHelper.java and DHParameters
○ public class DHParameters implements CipherParameters {
private static final int DEFAULT_MINIMUM_LENGTH = 160;
for (;;) {
BigInteger x = BigIntegers.createRandomInRange(min, max, random);
if (WNafUtil.getNafWeight(x) >= minWeight) {
return x;
}
}

37. Non-standard implementations do not check the
strength of the private key
37
http://www.geeksforgeeks.org/implementation-diffie-hellman-algorithm/
http://www.programmingboss.com/2015/11/diffie-hellman-key-exchange-algorithm.
html
https://gist.github.com/cloudwu/8838724
https://github.com/pannous/Diffie-Hellman/blob/master/DH.java
...

38. Amateur code do not check private key strength :)
38
https://github.com/pannous/Diffie-Hellman/blob/master/DH.java
// on machine 1
secretA = new BigInteger(bitLength-2,randomGenerator);
// on machine 2
secretB = new BigInteger(bitLength-2,randomGenerator);
// to be published:
publicA=generatorValue.modPow(secretA, primeValue);
publicB=generatorValue.modPow(secretB, primeValue);
sharedKeyA = publicB.modPow(secretA,primeValue);
sharedKeyB = publicA.modPow(secretB,primeValue);
secretA or B
can be small.

39. An interesting comment that surprised me :)
https://gist.github.com/cloudwu/8838724
This implementation of DH possible works for 64-bit key size but can be broken
easily using Baby-step Giant-step (hash table size will only be 232
)
39

40. Closing Remarks
● DH key exchange system is based on one-way functions
○ Easy to compute (exponentiation) but difficult to reverse
● Brute-force is hopeless to solve the discrete log problem to reverse
○ Did not solve even after running for 10 hrs
● Baby-step Giant-step algorithm is much better than brute-force
● Given h = gx
mod p, finding x is possible for “smaller” x values only though
○ By small, I mean on my laptop, x <= 244
○ If we store the hash table onto the disk, we can break if x <= 254
● If we choose standard implementations, the lower bound of x is checked!
○ This makes it difficult to break DH using Baby-step Giant-step algorithm
○ Non-standard implementations do not have the check - can be dangerous
40

41. Tentative Future Plans
● Using powerful key-store implementations (e.g., Berkeley DB)
● Experiment with other discrete log algorithms. For example:
○ Pollard Rho method
○ Index Calculus
○ Number field sieve
● Analyse existing open-source implementations of DH
● Discrete log in Elliptic Curve Crypto
41

42. References
● W. Diffie and M. E. Hellman. “New Directions in Cryptography”, IEEE
Transactions on Information Theory, vol. IT-22, no. 6, november, 1976.
● Modular Exponentiation
https://en.wikipedia.org/wiki/Exponentiation_by_squaring
● David Adrian et. al. “Imperfect Forward Secrecy: How Diffie-Hellman Fails in
Practice”, ACM Conference on Computer and Communications Security.
42

43. References ...
● C. Paar and J. Pelzl. “Understanding Cryptography: A Textbook for Students
and Practitioners”, Springer, 2011.
43