
Computational Science Scientific Computing  Bioinformatics, Computational Chemistry, Computational Neuroscience, Computational Physics, Numerical Algorithms, Symbolic Mathematics, Cognitive Science 
 LinkBack  Thread Tools  Display Modes 
July 31st, 2008, 08:27 AM  #16  
Joined: Jul 2008 Posts: 13  Re: Practical RSA ecncryption speeds
In other news...GMP trounces Pari in modular exponentiation deathmatch!!! Implementing the Greathouse benchmark, we have: G50kB: Pari78ms, GMP77ms; G500kB: Pari422ms, GMP335ms; So GMP is marginally faster after all. Also faster is CRG's computer..than mine... Speaking of which, I'm not racing against this cluster you're building, am I? Quote:
 
My Computer Forum is free to register and we welcome everyone! 
July 31st, 2008, 09:40 AM  #17  
Joined: Dec 2007 Posts: 232  Re: Practical RSA ecncryption speeds Quote:
Yes, I'm not surprised to see GMP being faster. The difference between the two is a little odd, though; while GMP should gain comparative advantage vs. Pari as exponent length increases, 50 kB > 500 kB should scale as a factor of 10 (but it didn't). Quote:
Quote:
 
July 31st, 2008, 01:29 PM  #18 
Joined: Jul 2008 Posts: 13  Re: Practical RSA ecncryption speeds
I should just clarify that G50kB and G500kB use the same modulus and exponents, the second just iterates 10x more than the first. Since those weren't very accurate or experimentaly sound results and since I was feeling a little nostalgia for my one year of college physics, I decided to do it up right and calculate with standard error aka uncertainty aka stdev/sqrt(population). I also used a different timer because clock() from time.h kind of sucks I think under Cygwin. What I did use was a little include file from one of the profs. at my university; it essentially boils down to calling some asm function called rdtsc. Anyway, I tested a proper MiB's worth of 256 bit modular exponentiation in (1) a C program calling the GMP library and (2) the Pari/GP interpreter: GMP: 690.±2 ms Pari: 875±1 ms This was for 20 runs each on, once again, my 1.6GHz Intel Centrino Duo. This has been fun it sort of gets that lust for massive computation going, you know? Oops, I just thought seriously about learning FORTRAN again. 
July 31st, 2008, 05:38 PM  #19 
Joined: Dec 2007 Posts: 232  Re: Practical RSA ecncryption speeds
My timing program worked similarly  though I must say I'm impressed with your data; I could never get it to cluster that well. Is the +/ one standard deviation?

August 1st, 2008, 12:35 AM  #20 
Joined: Jul 2008 Posts: 13  Re: Practical RSA ecncryption speeds
Not quite. It is the standard deviation divided by the square root of the sample size. For me that was twenty. My standard devs were 9.8 and 5.2 respectively. The quantity I put up is variously known as standard error, error, or uncertainty. I don't know the exact statistical significance, I just remember that this is what we used in first year college physics when measuring things multiple times. You can check it out here, I guess they call it standard error of the mean: http://en.wikipedia.org/wiki/Standar...r_(statistics) 
August 1st, 2008, 06:04 AM  #21 
Joined: Dec 2007 Posts: 232  Re: Practical RSA ecncryption speeds
Hmm, that raises some interesting points since I calculated my range differently  but that seems like a good measure.

August 1st, 2008, 06:22 AM  #22 
Joined: Jul 2008 Posts: 13  Re: Practical RSA ecncryption speeds
By the way, what function do you use in your timing program? I read something today that makes me unsure of the validity of rdtsc.

August 1st, 2008, 09:27 AM  #23 
Joined: Dec 2007 Posts: 232  Re: Practical RSA ecncryption speeds
I just use clock from the standard library.

April 30th, 2010, 02:05 PM  #24 
Joined: Apr 2010 Posts: 96  Re: Practical RSA ecncryption speeds
Can someone write a tutorial on RSA and also on its implementation and pm me a link to it please? I havent come across it before but am interested now 
November 23rd, 2011, 04:49 AM  #25 
Guest Joined: Posts: n/a  Re: Practical RSA ecncryption speeds
However, currently I only use it for swap encryption (because of its speed). ... It doesn't seem to be practical
