What you quoted works for RSA etc as well. Just dispose of the private key right after you decrypted the session AES key. IMO it's not worth the overhead, but feel free to do that. You can even do it for each packet/message if you want. Fetch the other parties single-use public key and send the symmetric key plus the symmetrically encrypted message. Repeat that over and over.
So now I get why you wanted to use DH which basically is El Gamal with random single use keys. But you can use any other asymmetric crypto as well - just generate single use keys and dispose of the private keys right after use. Still if one gets hold of the private keys he can decrypt the symmetric key and read all messages of that session. Same for your DH approach, if an attacker would get the random DH secret number he could simply calculate the shared secret by combining it with the other parties public number. But sure the moment the private keys are deleted (from ram I guess?) no one will ever be able to reconstruct them - resulting in that forward secrecy. So just use one keypair per message - you should be able to send like 600 messages per second on an average CPU. smu johnson wrote: > To quote wikipedia on Perfect Forward Secrecy: "In an authenticated > key-agreement protocol that uses public key cryptography, perfect > forward secrecy (or PFS) is the property that ensures that a session > key derived from a set of long-term public and private keys will not > be compromised if one of the (long-term) private keys is compromised > in the future." > > STS page says: "The Station-to-Station (STS) protocol is a > cryptographic key agreement scheme based on classic Diffie-Hellman > that provides mutual key and entity authentication. In addition to > protecting the established key from an attacker, the STS protocol uses > no timestamps and provides perfect forward secrecy." > > Now, you mentioned: "Both systems are broken the moment the private > key leaks." Based on the above two quotes, especially where it says > the session key "will not be compromised if one of the (long-term) > private keys is compromised in the future"... well I do not think that > what you said is true. If I am correct in my claims, and this is > possible which I believe it is, then this is the level of security I > am trying to reach with my Simp clone project. > > On Tue, Jul 13, 2010 at 6:40 PM, Elias Önal <[email protected] > <mailto:[email protected]>> wrote: > > What I still don't get - Why don't you want the symmetrical key to be > sent in an encrypted form? Sending a random AES key RSA encrypted over > the net is no way less secure than using DH to generate it. Both > systems > are broken the moment the private key leaks. > > -- 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.
