From: Jeff Rose Subject: Re: [p2p-hackers] What's the risk of sharing private RSA keys?
On Jul 8, 2007, at 1:35 AM, David Barrett wrote: The only real difference between the public and private key is it's far more expensive to encrypt/decrypt with the private key than with the public - on the order 20x. So far as I know, other than the difference in CPU cost, they are interchangeable. Really? Unless I am not understanding it right, encryption and decryption in RSA require basically the same operation, namely, taking some number to an exponent, mod n. http://en.wikipedia.org/wiki/RSA OpenSSL has a neat command-line tool that just does benchmarking; here's the output for RSA on one of my servers: Doing 512 bit private rsa's for 10s: 15864 512 bit private RSA's in 10.00s Doing 512 bit public rsa's for 10s: 179788 512 bit public RSA's in 10.00s Doing 1024 bit private rsa's for 10s: 3102 1024 bit private RSA's in 10.00s Doing 1024 bit public rsa's for 10s: 63041 1024 bit public RSA's in 10.00s Doing 2048 bit private rsa's for 10s: 540 2048 bit private RSA's in 10.01s Doing 2048 bit public rsa's for 10s: 19201 2048 bit public RSA's in 10.00s Doing 4096 bit private rsa's for 10s: 82 4096 bit private RSA's in 10.08s Doing 4096 bit public rsa's for 10s: 5424 4096 bit public RSA's in 10.00s If I understand correctly, this means one direction is faster than the other. Clearly, given the cost difference of the keys, it should be at least 20x more difficult to guess the private key given the public than vice versa using a brute force attack. Anyway, do you think 20x is worth thinking about, even if it were the case. If an algorithm can be broken by n computers or 20n computers it's still broken. I don't know about RSA, but saw on this link (below) that AES (Rijndael) takes on the order of 149 trillion years to decrypt with a cryptanalysis machine. Who cares if it's only 7 or 8 trillion instead? I think with a 2048 bit RSA key you can be pretty secure about things for your forseable lifetime. (Quantum computing could change things though...) Well, if I had CPU to burn, I'd agree with you. But in my particular case, I'm trying to cut down the CPU cost, and thus I'm forced to make security/CPU tradeoffs. Granted, for most applications, even a year's worth of protection is probably adequate - any hacker willing to throw more than a CPU-year of effort at breaking your security will probably find a weaker link than cracking your encryption, but still. But good to at least understand security/CPU tradeoffs anyway. P.S. Where is the P2P though? What kind of communications are you trying to support? (Actually, that could be a nice survey paper. Encryption algorithms and techniques paired with different P2P interactions... Probably should be a real crypto person.) Well, it's for part of a P2P system so it's loosely related. Basically, key exchange is surprisingly expensive, and if you establish a ton of peer connections - such as for a swarming download - then it can actually become a bottleneck on low-end CPUs. -david
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
