[p2p-hackers] What's the risk of sharing private RSA keys?

Joseph Ashwood ashwood at msn.com
Sat Jul 7 22:03:56 EDT 2007


----- Original Message ----- 
From: "David Barrett" <dbarrett at quinthar.com>
To: "'theory and practice of decentralized computer networks'" 
<p2p-hackers at lists.zooko.com>
Sent: Saturday, July 07, 2007 5:53 PM
Subject: RE: [p2p-hackers] What's the risk of sharing private RSA keys?

> 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.

Take a look at ECC, we are at or near the tipping point where ECC becomes 
faster per security. Right now 2048-bit RSA is about the minimum that should 
be used, and I'm beginning to consider moving my recommendations to 
2536-bit, but with ECC 256 bits is sufficient. Also keep in mind that you 
can and should cache the previous keys, so you can safely change keys only 
every TB or so. Just store a few thousand keys, that's only a couple hundred 
KB of storage space the users won't notice.

Basically here's what you'll want to do

Generate one time use 256-bit ECDH key pair on pre-established curve (fix it 
for all clients)
ECDSA= sign data with long term private 256-bit ECDSA key, use SHA-256
EPH_a = {version, generation time, local identifier, remote identifier, 
one-time use 256-bit public key, curve}
A={EPH_a, ECDSA(EPH_a)}
send A, receive B
B is identical in format to A, reverse the process, verify the ECDSA 
signature
Perform the ECDH key agreement this delivers a 256-bit shared secret SS
A->B Enc = HMAC_SHA-256(SS, "A->B Encryption") //(Key, Data)
A->B MAC = HMAC_SHA-256(SS, "A->B Authentication")
B->A Enc = HMAC_SHA-256(SS, "B->A Encryption")
B->A MAC = HMAC_SHA-256(SS, "B->A Authentication")
Note that for efficiency you only have to perform the keying process of the 
HMAC once. I may have missed some things that are necessary, this was only a 
very quick process.

With Crypto++ (which I find has more useful benchmarks than OpenSSL) a 
1.83GHz Core 2 using just the 32-bit operations should be able to compute 
all of this in about 20-25ms, or less computation time in computation than 
the round trip for a single packet. Although this does not include direct 
verification of the keys which should probably be added. Using 64-bits the 
time can be cut approximately in half. If you use AES for the encryption and 
MACing it should be possible to achieve 50MB/sec without any stress. If you 
want maximum performance I would actually recommend moving to LibTomCrypt, 
Tom's work on that has delivered probably the highest performance for the 
primitives.
                    Joe 



More information about the p2p-hackers mailing list