New secret numbers per session is as much overhead as generating new EG or RSA keys each time. This is trivial since all El Gamal does is keeping those numbers fixed - calling them public and private key. You told me that would be too slow for you. New secret numbers, new signature on the public part and new exchange plus calculation of the shared secret is equal to the overhead of any of the methods I suggested involving the generation of a new keypair you sign.
Look at the official crypto++ benchmarks, they show you it takes ages (several milliseconds) to do the DH key generation. http://www.cryptopp.com/benchmarks.html Your GPG problem was likely related to your entropy pool/source, generating RSA/EG keys doesn't take longer than DH "keys". If RSA/EG would take ages, your web-browser would struggle as well since it does TLS/SSL all the time - Never had that problem. smu johnson wrote: > On Thu, Jul 22, 2010 at 4:58 AM, Elias Önal <[email protected] > <mailto:[email protected]>> wrote: > > Dunno what your problem is, but my old core2 1,66ghz laptop generates > like 800 ECDH 256bit keys a second (as strong as RSA 2048 bit). I > don't > see how you plan to archive perfect forward secrecy by using > authenticated DH. > > > Whitfield Diffie had no problem figuring out how to achieve perfect > forward secrecy with it. Bruce Schneier mentions it in Applied > Cryptography, and explains it in greater detail in Practical > Cryptography. He didn't seem to have any problems with it either. > Simp does it, OTR does it too. SSH does a DH exchange that is not > compromised by man-in-the-middle if you verify the fingerprints, kind > of like what I want to do. > > You are telling me you just can't see how it's done. Well, here's the > thing. I didn't design the protocol, I just want to implement it in > Crypto++. If you think it can't be done, take it up with them! It > wasn't my idea. > > > I mean if the other guy keeps your DSA signed DH > number and generates the shared secret from it, he will always end up > getting the exactly same shared secret he had last time. > > > Yes, he will if he keeps his secret number, which he is susposed to > delete / purge after each session... ie, every 5 mins or so. But, if > he keeps your DSA signed DH number but he purged his secret number > like he's susposed to, he can't do anything. > > So are you saying that there is a possibility that he might not purge > what he's susposed to? Well, he might also paste the entire > conversation on a public website, too. That's a trust issue, not a > protocol issue. Besides that, how is your idea of using RSA instead > going to prevent that, if he keeps the keys? > > > So that gains > you surely no forward secrecy at all. I am pretty sure to do it > properly > you have to change at least the DH system parameters, but better the > secret part, derive a new public part/number, sign it DSA and send it > over to have the other guy get the shared secret and verify the > signature. I really don't see how you can get a new shared secret from > already shared DH keys time over time. Doesn't work that way in my > world. > > > New DH exchange per session, new secret numbers per sesson was my idea. > > -- smu -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
