----- Original Message -----
From: "David Barrett" <[EMAIL PROTECTED]>
To: "'theory and practice of decentralized computer networks'"
<[email protected]>
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
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
