150 likes | 256 Views
Generating RSA Primes. Jim Townsend CSE633 Final Results Fall 2010. Importance. Encryption is harder to secure than ever RSA is an important standard in Public Key Encryption Developed in 1977, it began with relatively small keys – 128,256 bit keys
E N D
Generating RSA Primes Jim Townsend CSE633 Final Results Fall 2010
Importance • Encryption is harder to secure than ever • RSA is an important standard in Public Key Encryption • Developed in 1977, it began with relatively small keys – 128,256 bit keys • Current standard: 1048 bit keys (310 decimal digits) • Math on these numbers is very CPU intensive
How Keys are Generated • Use the Miller-Rabin algorithm • Tests against a specific few numbers • Only a probabilistic method • Probability a number is prime: .75 • Repeated passes used to eliminate false positives • 16 repetitions: (1-.75)^16 • Runtime: O(ln(N)^4)
Sieve of Eratosphenes • Decided to implement a small sieve on the numbers before using the Miller-Rabin algorithm • Using all the prime numbers less than 1000 (168 numbers), see if any of those evenly divide the number first • Decreased serial runtime by more than half
Current Program • The program takes in two strings: a starting value and a range • Runs a sieve on the range with the first 168 primes • Uses the remaining numbers and tests them with the Miller-Rabin algorithm up to 16 times on each.
Serial Results • Finding small numbers was relatively fast • Found 2263 primes 20 digits long in just .68 seconds • Large numbers are a different story: • 310 digits (Current RSA standard) took 27.01 seconds to find only 118 primes
Parallel Algorithm • Divided the range among each processor • Each node checked its set and reported the number of primes it found • Final reduction to sum up the count
Gains • Saw incredible speedup due to the minimal communication needed • Most of the real gains came from tweaking the serial algorithm • Using the sieve and only checking odd numbers • Would see much more by using load balancing using OpenMP
Future Work • Could be more improved by load balancing the test with OpenMP • Exit on first failed test • Much better synchronization would be possible • Could also use this to divide the test into smaller pieces as well • Implementation in CUDA using GPGPUs