1. General Attacks on Elliptic Curve Based Cryptosystems Merabi Chicvashvili Ron Ryvchin Project Advisor: Barukh Ziv Spring 2014

2. Elliptic Curves   Point addition can be defined geometrically and algebraically

3. Algebraic Approach  Point Addition  R = P + Q  s = (P y – Q y ) / (P x – Q x )  R x = s 2 – P x – Q x  R y = s*(P x – R x ) - P y  Point Doubling  R = 2·P  s = (3·P x 2 + a) / (2·P y )  R x = s 2 – 2·P x  R y = s*(P x – R x ) - P y

4. Cryptography with Elliptic Curves

5. Elliptic Curve Encryption

6. Attacking ECC  Best possible way is a ‘collision attack’ known as Pollard’s rho attack,taking O(n 1/2 ) curve additions, where n is the order of the base point  The Pohlig-Hellman algorithm reduces the size of the problem.  ECDLP is reduced to ECDLP modulo each prime factor of n  As field size increases, the attack becomes harder at an exponential rate  ECC key of 163 bits is equivalent to RSA key of 1024 bits  ECC key of 256 bits is equivalent to RSA key of 3072 bits

7. Pollard rho Algorithm

9. Additive walks

10. Cycle detection

11. Performance Analysis - Speed  Attack performance dependents on:  Field arithmetic speed – provided by NTL library  Curve arithmetic speed – selection of coordinates  Algorithmic level – partition function, cycle detection

12. Performance Analysis – additive walk and partition function

13. Performance Analysis - coordinates  Affine point addition:  1 squaring, 2 multiplications, 1 inverse  Inverse is expensive!  Jacobian coordinates: x, y, z  Jacobian point addition:  12 squarings, 4 multiplications, no inverse!

14. Performance Analysis - coordinates

15. Performance Analysis – cycle detection  Brent’s cycle detection algorithm does less function evaluations than Floyd’s. In his work Brent claims that his algorithm improved Pollard Rho performance by 24%, on average.  Brent’s algorithm counts number of steps. At the end, we know the length of the cycle.  We used this counter to improve the algorithm for some cases of “rho” shape, staying with O(1) space complexity

16. Performance Analysis – cycle detection “Perfect” cycle detection: Tail = 2 i - 1Tail = 2 i - 1 Cycle = 2 iCycle = 2 i No redundant stepsNo redundant steps

17. Performance Analysis – cycle detection “Worse” case: Tail = 2 iTail = 2 i Cycle = 2 i -1Cycle = 2 i -1 Same number of steps to collisionSame number of steps to collision The algorithm does (tail-1) + 2 i + cycle stepsThe algorithm does (tail-1) + 2 i + cycle steps Redundant steps: ~50%Redundant steps: ~50%

18. Performance Analysis – cycle detection Worst case 1: Very short or no tailVery short or no tail An iteration finishes just one step short of the possible collision pointAn iteration finishes just one step short of the possible collision point Could finish in about 2 i steps, will take twice moreCould finish in about 2 i steps, will take twice more Worst case 2: … After finishing the tail in ~2 i steps, we waste the same number of steps before we get the first green point on the cycleAfter finishing the tail in ~2 i steps, we waste the same number of steps before we get the first green point on the cycle

19. Performance Analysis – cycle detection “Middle point” improvement: Remember the point after 2 i-1 stepsRemember the point after 2 i-1 steps Compare new points to both last “green” and “yellow”Compare new points to both last “green” and “yellow” Collision found after (tail – 1) + 2 i-1 + cycle stepsCollision found after (tail – 1) + 2 i-1 + cycle steps Saving: 2 i-1, which is ~1/6 th of the original resultSaving: 2 i-1, which is ~1/6 th of the original result The saving is up to 1/4thThe saving is up to 1/4th Experimental measurements: ~50% of attacks were shortened, for each challenge (key size) there was an attack that found middle point collision, speedup: 14-24%Experimental measurements: ~50% of attacks were shortened, for each challenge (key size) there was an attack that found middle point collision, speedup: 14-24%

20. Results  Previous best results: 64 bits challenge in ~16 hours (1,993,844,576 function calls)  Our best result:  64 bits in ~42 minutes (436,215,366 function calls)  70 bits in ~5 hours (4,924,092,173 function calls)

21. Full Results challenge sizefunction evaluations time (min)time (max) (bits)minmaxaverage 30 24,176 77,424 37,974 0.05 sec0.2 sec 40 365,389 2,200,397 1,125,607 1 sec6 sec 50 5,471,207 54,876,055 25,661,00318 sec 197 sec 64 436,215,366 6,261,487,497 3,499,239,651 2507 sec (42 min)23917 sec (~7 hours) 70 4,924,092,173 90,946,847,050 38,666,966,411 17878 sec (~5 hours)328611 sec (~4 days)

22. Special Challenge

25.  Since the order of the curve is not a prime number we applied Pohlig-Hellman reduction to this challenge.  Although n is large, its largest prime factor is 28202267.  The whole attack finished in about 3 minutes.

26. Bibliography  V. Shoup, "NTL: A Library for doing Number Theory" http://www.shoup.net/ntl/  Darrel Hankerson, Alfred Menezes, Scott Vanstone, “Guide to Elliptic Curve Cryptography”.  I. Duursma, P. Gaudry, and F. Morain, “Speeding up the Discrete Log Computation on Curves with Automorphisms”  R´obert L´orencz, “New Algorithm for Classical Modular Inverse”.