Page 1
Project report – General Attacks on Elliptic Curve Based Cryptosystems
By Ofer Schwarz, Winter 2012-2013
Project advisor: Barukh Ziv
1 Introduction ....................................................................................................................... 2
2 Background ........................................................................................................................ 2
2.1 Elliptic curves ............................................................ 2
2.2 The discrete logarithm problem ............................... 2
2.3 Collisions and Pollard's Rho ...................................... 3
2.4 The Pohlig-Hellman reduction .................................. 4
3 Improvements and Optimizations ..................................................................................... 5
3.1 The Montgomery trick for inversion ........................ 5
3.2 Distinguished points ................................................. 5
3.3 Nivasch method for cycle detection ......................... 6
3.4 Negation Map ........................................................... 7
4 Implementation ................................................................................................................. 8
4.1 Elliptic curve arithmetic library ................................ 8
4.2 Collision library ......................................................... 8
4.3 Putting it all together ............................................... 8
5 Challenges .......................................................................................................................... 9
6 Results ............................................................................................................................. 10
6.1 The basic challenges ............................................... 10
6.2 Previous results ...................................................... 11
6.3 Optimization efficiency tests .................................. 11
7 Schedule .......................................................................................................................... 12
8 Bibliography ..................................................................................................................... 13
Page 2
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
2
1 Introduction
Many modern cryptographic algorithms, specifically for asymmetric encryption and digital
signatures, use the mathematical properties of groups as a basis for their strength. Elliptic
curves are a type of group whose structure is simple enough to allow efficient group
operations, yet complex enough that there are no known attack methods other than generic
ones, which have an exponential time complexity. Thus they are gaining increasingly
widespread popularity.
The project aimed to implement the current best-known general attack on elliptic curve-
based systems, with various improvements and optimizations, with the ultimate goal of
attacking a 64-bit curve. (See section 6 for detailed results.)
2 Background
Note: this section is a summary of the relevant material in [1].
2.1 Elliptic curves
An elliptic curve over the field is the set of all solutions ( ) to the equation
where , with an extra symbolic "point at infinity" marked . Using
geometric properties of the "graph" of solutions, one can define an abelian group structure
for the curve, with the point at infinity serving as the unit member of the group.
Cryptographic systems usually use elliptic curves over prime fields ( for some large prime
number ) or binary fields ( for some integer ), since field arithmetic in these
particular fields can be implemented very efficiently. In this project we have focused on
prime field curves.
In curves over a prime field, the Weierstrass equation above can be expressed, using a
variable change, as a much simpler equation of the form .
2.2 The discrete logarithm problem
The Diffie-Hellman, El Gamal and DSA cryptographic algorithms are all based on the
computational hardness of a mathematical problem called DLP, or Discrete Logarithm
Problem. In this problem, we are given a group , a member of the group with a finite
order, and a member of the subgroup ⟨ ⟩ generated by , i.e., such that for
some (or, using the additive syntax for abelian groups, which is commonly used for elliptic
curves: ). The goal is to find the number . (This problem is called discrete logarithm
since this operation is logically very similar to the real-valued logarithm function)
DLP in the group of integers modulo has been demonstrated to be computationally
equivalent to the problem of integer factorization, and indeed, sub-exponential algorithms
exist for both. However, the best known algorithms for DLP over a general group are
exponential, and as mentioned eariler, these are also the best-known methods for DLP over
elliptic curves.
Page 3
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
3
2.3 Collisions and Pollard's Rho
The current best-known method for solving ECDLP (Elliptic Curve DLP) relies on the following
idea: given two points on the curve, and , such that , suppose that we find
integers so that . Given these, we can easily find :
( ) ( ) ( ) ⇒ ( ) ( ) ( )
where is the order of in the group.
The naïve method for finding such a collision is using the birthday paradox: if we generate
multiple random pairs of ( ) and store the resulting linear combinations ( )
in a hash table, we can expect to find a collision after (√ ) pairs. However, this method
also requires (√ ) memory, which is highly impractical for even relatively small values of
(real cryptographic systems typically use elliptic curves of at least 192 bits).
Pollard's Rho method [2] uses an alternative approach, based on the properties of random
functions. Every function over a finite space is composed of finite-length chains:
Figure 1 : The eponymous Rho, with a highlighted collision
Each chain contains a cycle and, more importantly for us, a collision. In a random function,
the expected chain length is √ , with about half of that belonging to the tail and the
other half to the cycle part of the chain. The collision can then be found using one of several
methods, for example by choosing a random starting point and applying the well-known
Floyd's algorithm for cycle detection [3], using an expected √ applications of the
function and constant memory.
Now all that is left to do is to find a way to create a pseudorandom function so that given
, it will be easy to find that satisfy ( ) . This is achieved by
using an additive walk: first we partition the curve into several disjoint subsets ,
typically according to the value of the least bits of the coordinate, then we
choose random integers and , and define ( ) for
. While this process doesn't result in a truly random function, it does yield
good enough results, and allows for very easy calculation of the linear combinations as
mentioned.
Page 4
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
4
2.4 The Pohlig-Hellman reduction
The Pohlig-Hellman method [4] reduces an ECDLP calculation (or really any discrete
logarithm) over a group of order to several instances of ECDLP over subgroups of orders of
the prime factors of , meaning that an elliptic curve cryptosystem with order is only as
strong as the highest prime factor of .
The reduction consists of two parts: the first is noting that if
, and we have
( ) , then we can find using the Chinese Remainder theorem.
Therefore we can assume WLOG that for some prime number and positive integer
.
Now, there is a unique way to write
where
. The second part of the Pohlig-Hellman reduction finds the
values of iteratively, using a single ECDLP instance of order for each step.
First, define
and
. Then we have:
but since this means that , and we can find by solving ECDLP for
( ), where the order of is .
Once we have , we can calculate in a similar fashion, by defining
( ) ( ) (
) (
) (
)
and solving ECDLP for ( ). We can find all this way: in the 'th iteration we'll have
[ (
) ]
Page 5
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
5
3 Improvements and Optimizations
While the attack described above is enough to achieve an asymptotic complexity of (√ ),
when dealing with time frames of hours and even days, it is obvious that even constant
factors can count for a lot. To that end, several improvements and optimizations were used,
that don't give any asymptotic benefit but do result in a significant reduction of calculation
time and/or number of iterations.
3.1 The Montgomery trick for inversion
The underlying observation behind the Montgomery trick is that the most expensive field
operation is inversion (which is required for division). For example, in a prime field elliptic
curve, given ( ) and ( ), in order to calculate ( ) we need
to make the following calculations:
( ) ( )
(A quick aside: the value of is actually the geometrical "slope" of the line connecting the
points and )
Addition and subtraction in a prime field are very cheap (and even more so in binary fields).
Multiplication and squaring are more expensive, and use more modular reductions, but still
pale in comparison to inversions, which require the use of Euclid's algorithm and are
consequently considerably more expensive for large numbers.
The Montgomery trick performs field inversions in parallel, i.e., given , it
calculates
. The advantage over doing a simple calculation of every inversion by
itself is substituting the inversion operations with ( ) multiplications and a single
inversion. The trick works by calculating accumulating products: for each we
calculate ∏ , then given
we calculate ∏
.
3.2 Distinguished points
As evident by its definition, the Montgomery trick requires running several instances of
ECDLP in parallel, so they can all perform their inversions simultaneously. While probabilistic
analysis shows that running parallel instances does result in an expected overall speedup
factor of √ (so that we end up slowing the calculation "only" by a factor of √ and not ),
there is a much better method that gives a speedup factor of .
Algorithm 1: Montgomery trick for inversion
ParallelInversion(a[1..k]):
c[1] a[1]
for i = 2 to k:
c[i] c[i-1] * a[i]
u = inverse(c[k])
for i = k downto 2:
result[i] u * c[i-1]
u u * a[i]
result[1] u
Page 6
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
6
The distinguished points method [5] relies on the following observation: the previously
described Pollard's Rho "chains" may intersect.
Figure 2: Pollard's Rho with intersecting chains
Each chain still contains a cycle, but if we can keep track of the intersections as well we will
gain a significant speedup. This is achieved by keeping a central hash table with encountered
points. Of course, we can't just put every single point in a hash table, because of memory
considerations. So what we do is find some way to distinguish some fraction of the space
(e.g., points whose coordinate's least bits are all 0), and only insert distinguished points
into the hash table. This saves a factor of in memory, but still effectively guarantees that
we'll find the intersection, since if the chain is long enough (if it isn't, we'll find the cycle
quickly) and the function is random enough, we will eventually reach a distinguished point.
The distinguished points method, in conjunction with the Montgomery trick, gives all the
benefits of the reduced number of inversions with none of the disadvantages of running
several unrelated parallel instances.
3.3 Nivasch method for cycle detection
While Floyd's algorithm is the simplest and most widely known method for cycle detection, it
is by no means the most efficient. An alternative method proposed by Gabriel Nivasch in
2004 [6] uses a stack to find the smallest value on the cycle1.
The idea is to keep a stack of values encountered so far, and for each new value
encountered, remove from the stack all values that are strictly larger than it. If, at any time,
the value at the top of the stack is the same as the value currently being handled, we have
found our collision.
Nivasch also proposes a further improvement: if we partition the space into disjoint
subsets (as illustrated in section 2.3) and use a separate stack for each subset, we only need
to go on until we reach a collision in one of the stacks. Probabilistic analysis provided in [6]
1 For some predefined order, e.g., according to the value of the coordinate.
Page 7
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
7
shows that this results in an expected running time of (
( ))√ , with a memory
overhead of ( (√ )). For comparison, as mentioned previously, the expected running
time of Floyd's algorithm is about √ .
3.4 Negation Map
While point addition in elliptic curve is an expensive operation, negating a point is relatively
very cheap: in prime curves, for example, if ( ) then ( ). Thus, if we treat
every pair of points ( ) as a single element | |, for example by using the point of the
pair which has an even coordinate, we can effectively reduce the size of the search space
by a factor of 2, resulting in an overall speedup factor of √ .
3.4.1 Fruitless cycles
The use of the negation map presents a problem when using additive walks (described in
section 2.3). Suppose that for a given point | |, where for some (where
are the partition subsets of the space used to build the additive walk function), we
have ( ) which satisfies | | and . Then we would have:
(| |) ( )
so that | (| ( )|)| .
This is called a fruitless cycle of length 2, and is actually quite common, with a probability of
for each step in the walk. The cycle is called fruitless because it does not represent an
actual collision, just a byproduct of our "twisting" of the space, and since the coefficients of
the linear combination are identical, it can't be used to find the discrete logarithm. There can
also be fruitless cycles of larger even lengths, although they will of course be rarer.
3.4.2 Eliminating fruitless cycles
One method for eliminating fruitless cycles has been proposed by Bernstein, Lange and
Schwabe in [7], and relies on periodically checking for such cycles. For example, to eliminate
fruitless cycles of length 2, every iterations, when calculating ( ), first we check
if . In that case, instead of continuing the walk as planned, we define
| { }|
thus "breaking" the cycle. Similarly, for some larger interval we check periodically for cycles
of length 4, and for an even larger interval we check for cycles of length 6, etc. Since the
probability of a fruitless cycle of a given length increases exponentially as the length
increases, it is enough to check for lengths up to the smallest even length that exceeds
.
Analysis provided in [7] suggest that the optimal interval in which to check for cycles of
length is approximately . In this project, the parameters used (for ) were
.
Page 8
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
8
4 Implementation
The project's code was written entirely in C++, and consists of 3 parts: an elliptic curve
arithmetic library, a generic collision-finding library, and a wrapper that connects the two
and supplies the actual definitions of the partitioning of the space, the additive walks, etc.
4.1 Elliptic curve arithmetic library
The EC library is a generic (templated) C++ library for elliptic curve arithmetic, allowing for
different curve types and different methods of point addition and multiplication. It supplies
a main template Point class, which is a convenient interface for all EC operations and
supports validation (i.e., checking whether given coordinates ( ) actually represent a
point on the curve), standard C++ operators, and output. Additional classes (most of which
provide the template arguments for the Point class) decide the type of the curve and the
methods for adding and multiplying points. The current curve being used is kept as a global
context variable.
The only curve type currently available in the library is the prime field curve, with several
addition methods (the regular method, the Montgomery trick detailed earlier, and the
Jacobian projective coordinates described in chapter 3.2.1 of [1]) and some basic
multiplication algorithms. However, the library is designed so that it is very easy to add new
curve types and new addition and multiplication methods, and mix-and-match them as
necessary.
Since curve operation performance depends heavily on efficient field arithmetic, and that is
far beyond the scope of this project, two external open source libraries were used to achieve
this: the basic, brass tacks modular arithmetic is handled by GMP [8], a widely used library
for arbitrary-precision (big-number) arithmetic, while the higher-level number theory
algorithms are done by NTL [9], a Number Theory Library that can handle polynomials,
binary fields and matrices as well as simple prime fields, and supplies an easy-to-use C++
operator-based interface.
4.2 Collision library
Another generic, templated library handles collision-finding algorithms. It supplies an
abstract CollisionFinder interface and several concrete subclasses for various methods
described in this document – Floyd's and Nivasch's algorithms as well as the distinguished
points method. The interface is, as mentioned, completely generic and all that is required,
apart from the actual function to find a collision in, is a few problem-specific definitions (e.g.,
how to generate a random element, partition the space, or a predicate for distinguishing
points).
4.3 Putting it all together
The last part is the ECDLP code itself. It is relatively small, and includes the pseudorandom
additive walk function (as well as the negation map variant), the Pohlig-Hellman reduction,
the required functions for partitioning, distinguishing etc., and of course a main function to
run it all.
Page 9
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
9
5 Challenges
In order to test the performance of the ECDLP code, a few increasingly-difficult challenges
were used:
Challenge #1 – 30 bits2
Field order ( ): 754526683
Curve parameters ( ): 72537189, 706168557 (Curve equation is )
= (391592639, 187105396), = (699400157, 82294806)
ECDLP order ( ( )) = 754564781
Challenge #2 – 40 bits
1018754028791
( ) = 871520218049, 1007486607871
= (215868580937, 253947951840), = (283497910998, 322669501418)
= 1018752667981
Challenge #3 – 50 bits
= 862310130873029
( ) = 753664604275938, 359867061355737
= (396159790871760 299026752948778), = (594219074514457, 329535619534883)
= 862310073862651
Challenge #4 – 64 bits
= 17778887349362591359
( ) = 9532767884830205561, 17350004542596651438
= (2072463837547420019, 13457440224317410775)
= (14290627919077884680, 8330780035610710830)
= 17778887341958652103
Challenge #5 – special challenge
= 414507122857381699247
= (215672232155085007005, 176420948314972445409)
= (49818534942346740253, 67908233076804365605)
This challenge was used to test the Pohlig-Hellman reduction, since it is the only one of the
five in which the order of the point is not prime. It was given exactly in this form.
The curve parameters can be deduced from the values of and according to the curve
equation, and the order can be found using the fact that in some families of curves (one of
which the given curve belongs to), the order of the curve satisfies ( ) for
some very small integer , so that | .
The actual value of here is about 62 bits, but its largest prime factor is only 25-bit.
2 The hardness of the challenge is measured by the order of the point P, so for example "30 bits"
means .
Page 10
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
10
1
4
16
64
256
1024
4096
16384
65536
30 40 50 64
Ru
nti
me
(sec
on
ds)
Challenge bits
Average time
6 Results
The main result of this project is of course the actual attack, specifically for the 64-bit
challenge, but the modular nature of the libraries allowed for some experimenting with the
optimizations and parameters, and the results from these experiments are summarized here
as well.
6.1 The basic challenges
These are the running times for the various challenges, excluding the last special one, for the
standard version of the code, i.e., with all the improvements described in section 3. The
statistics are taken from 10 runs (except for the 64-bit challenge statistics, which include
only 1 run for obvious reasons). All runs were made on a single core of an Intel P8700 CPU.
Times are measured both in actual running time (seconds) and in distinct calls to the
function.
30 bits
Running time: min 1 sec, max 2 secs, average 1.5 secs3.
Function calls: min 2944, max 68160, average 38115.
40 bits
Running time: min 10 secs, max 57 secs, average 21.8 secs.
Function calls: min 440256, max 2538464, average 943411.
50 bits
Running time: min 117 secs, max 993 secs (16.5 min.), average 566 secs (9.5 min.)
Function calls: min 5323328, max 46201472, average 23051004
64 bits
Running time: 57540 secs (≈ 16 hours).
Function calls: 1993844576.
3 The measurement used the built in C time() function, which measures full seconds, so the actual
running times are probably considerably shorter.
0
5
10
15
20
25
30
35
30 40 50 64
log 2
(#ca
lls)
Challenge bits
Average function calls
Page 11
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
11
6.2 Previous results
The best result achieved by a previous group in this project is solving a 60-bit ECDLP in 5-6
days. Said group used a distributed attack, but without all the optimizations detailed in this
document and without the power of GMP and NTL.
The best result achieved in the entire world to date is solving a 112-bit ECDLP [10]. This
attack used a cluster of 218 PlayStation 3 game consoles with heavy optimizations (including
low-level integer operations using the PS3's Single-Instruction Multiple-Data architecture),
and took about 3.5 months or elliptic curve operations.
6.3 Optimization efficiency tests
There are 3 optimizations described in section 3: the Montgomery trick, the negation map,
and the Nivasch cycle-detection algorithm. These are the results of testing each of these
against the corresponding simpler method, using the 40-bit challenge as a benchmark (since
the 30-bit challenge is too quick to measure the difference in the runtime, and the 50-bit
one takes too long to allow multiple test runs).
The Nivasch algorithm for cycle detection is provably asymptotically better than Floyd's
algorithms, and indeed, using Floyd's algorithm instead results in an average number of
function calls that is more than twice that of Nivasch's method (the exact factor is 2.16).
However, the time per call is obviously shorter (Floyd's algorithm practically has no
overhead) and the runtime factor is 1.4 (still in favor of Nivasch, though).
The negation map is quite controversial, and hasn't been conclusively proved to improve
runtime, since the iterations it saves might be wasted on fruitless cycles and the checking
thereof. The experiment shows that while it does save an average factor of about 1.1 in the
total iteration count, it comes with a more significant added cost per iteration, so that the
total average runtime with the negation map is about 1.07 times longer.
Lastly, the Montgomery trick, while, as expected, yields no noticeable change in the average
number of calls (a factor of 1.008 that may as well be attributed to the random element),
does result in a speedup factor of 1.43. A further test for 30 bits shows a speedup factor of
1.33, which is to be expected, as the efficiency of the Montgomery trick is tied to the
difference of computation time between multiplication and inversion.
Page 12
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
12
7 Schedule
The schedule proposed in the project kickoff:
Basic study and reading: in 2 weeks (by 12/11).
Basic implementation of EC library: by mid-project meeting.
Optimizations of EC library: by end of year (1/1).
General attack implementation: by end of semester (1/2).
Further research and optimization: until submission of final report.
Actual retrospective schedule:
Basic study and reading: 2 weeks (12/11).
Familiarization and installation of GMP and NTL: 1 week (19/11).
Basic design of EC library: 2 weeks (2/12).
Basic implementation of EC library: 3 weeks (24/12 – mid-project meeting).
Testing and debugging EC library: 3 weeks (13/1).
First milestone: EC library finished – 13/1.
Design and implementation of collision library (incl. Nivasch): 3 weeks (10/2).
Important milestone: first challenge solved (30-bit) – 10/2.
Montgomery trick and distinguished points method: 2 days (12/2).
Negation map and Pohlig-Hellman reduction: 3 weeks (4/3).
Final milestone: 64-bit challenge solved – 8/3.
The major discrepancy is that the original schedule hadn't taken into consideration the
(unexpectedly heavy) course load of the semester and a quite busy exam period in the
second half of February. Other than that, the proposed schedule was pretty much spot-on.
Page 13
General Attacks on Elliptic Curve Based Cryptosystems Ofer Schwarz
13
8 Bibliography
[1] D. Hankerson, A. Menezes and S. Vanstone, Guide to Elliptic Curve Cryptography, New
York: Springer, 2004.
[2] J. M. Pollard, "Monte Carlo Methods for Index Computation (mod p)," Mathematics of
Computation, vol. 32, no. 143, pp. 918-924, Jul. 1978.
[3] R. W. Floyd, "Nondeterministic Algorithms," Journal of the ACM, vol. 14, no. 4, pp. 636-
644, October 1967.
[4] S. Pohlig and M. Hellman, "An Improved Algorithm for Computing Logarithms over
GF(p) and its Cryptographic Significance," IEEE Transactions on Information Theory, vol.
24, no. 1, pp. 106-110, 1978.
[5] P. Van OOrschot and M. J. Wiener, "Parallel collision search with cryptanalytic
applications," Journal of Cryptology, vol. 12, pp. 1-28, 1999.
[6] G. Nivasch, "Cycle Detection Using a Stack," Information Processing Letters, vol. 90, pp.
135-140, 2004.
[7] D. J. Bernstien, T. Lange and P. Schwabe, "On the correct use of the negation map in the
Pollard rho method," Public Key Cryptography - PKC 2011, pp. 128-146, 6-9 March 2011.
[8] "The GNU Multiple Precision Arithmetic Library," GNU, [Online]. Available:
http://gmplib.org/.
[9] V. Shoup, "NTL: A Library for doing Number Theory," [Online]. Available:
http://www.shoup.net/ntl/.
[10] J. W. Bos, M. E. Kaihara, T. Kleinjung, A. K. Lenstra and P. L. Montgomery, "PlayStation 3
computing breaks 2^60 barrier; 112-bit prime ECDLP solved," 2009. [Online]. Available:
http://lacal.epfl.ch/112bit_prime.