Hey guys - May someone else convince smu, I have tried and gave up ;)
You can reconstruct the shared secret by breaking the discrete logarithm
problem using only the transfered data and the "calculated public
number". Ofc you can't get the "private number" since you dispose it
after use if I got you right - that's how you archive forward secrecy.
But if I use signed random RSA keys and send the AES key encrypted using
it an attacker also would either have to break the discrete logarithm or
recover your "private number/key" which you would dispose after use just
like you did with the DH secret. So where exactly is the difference in
your opinion?
Here is a quote from my test project, as you can see I am using DH (ECDH
is DH on Elliptic Curves - still DH) and even Crypto++ is calling the
public and private numbers of DH "keys".
> // ### TESTS BELOW! ###
> void CryptoHandler::EcTest(void)
> {
> typedef CryptoPP::ECDH < CryptoPP::ECP >::Domain ECDHDomain;
>
> //alice
> ECDHDomain alice = ECDHDomain(CryptoPP::ASN1::secp256r1());
> alice.AccessGroupParameters().SetPointCompression(true);
> string alice_privKey(alice.PrivateKeyLength(), 0);
> string alice_pubKey(alice.PublicKeyLength(), 0);
> alice.GenerateKeyPair (prng, (byte*)alice_privKey.data(),
> (byte*)alice_pubKey.data());
>
> cout << "Alice public key length: " << alice.PublicKeyLength() <<
> endl;
> cout << "Alice public key: ";
> hexOutput(alice_pubKey.data(), alice_pubKey.size());
> cout << endl;
>
> cout << "Alice private key length: " << alice.PrivateKeyLength()
> << endl;
> cout << "Alice private key: ";
> hexOutput(alice_privKey.data(), alice_privKey.size());
> cout << endl << endl;
smu johnson wrote:
> Hi Elias, was going over these e-mails and some other various stuff
> and there's something I'm confused about.
>
> Regarding my forward secrecy discussion (rants :), you suggested to
> "Just dispose of the private key right after you decrypted the session
> AES key." Correct me if I am wrong, but this is still implying that
> you believe that a private key pair is necessary to send the session
> key still, or do a DH. RSA sends a public number, DH sends a public
> number. I don't get where you see the difference. Let's bring it back
> to the crypto++ list and have someone else convince you, I am actually
> not seing us getting anywhere and I believe you didn't understand DH
> properly.
>
> If you believe for a DH exchange at all, that you need a keypair, and
> that the key is sent encrypted, then that isn't at all what DH is used
> for and was invented for. The idea is that two parties arrive at the
> very same key, that is never sent over the airs, unencrypted or not,
> by sending public data that is allowed to be eavesdropped upon...
> relying once again (like RSA and other things), upon the difficulty of
> trap-door mathematics. There is no keypair generated, so the key is
> never sent over encrypted by anyone's private key, period. So when
> you say I should generate a keypair that is destroyed, that would
> probably do what I want, but since a DH doesn't generate any keypair
> and an STS can accomplish perfect forward secrecy, there is no need.
>
> Now, in order to defeat the man-in-the-middle with regular DH, I
> believe all you have to do to get an STS protocol going, or
> authenticated Diffie-Hellman, is to digitally sign the public numbers
> that are sent back and forth over the insecure lines, using a
> long-term public/private key pair that you keep for the long haul (ie,
> 2+ years). By long term, I don't mean that you generate a key pair
> every time you do a DH exchange, because it would take too long to
> generate, would take too long and be too inconvenient to verify the
> fingerprints over the phone etc etc, and would serve no benefit over a
> long-term keypair that you keep for a few years, until you feel that
> the time has come where you should increase the size of the bits of
> your RSA and generate a new keypair.
>
> To sum all this bullsnap up... it seems the main thing we are
> disagreeing on is how a DH works. You seem to think the key needs to
> be sent encrypted, and a DH is busted if the private key is
> compromised. I am saying that DH has nothing to do with pub/pri
> keypairs, unless you're doing STS.
>
> -- smu
>
> On Tue, Jul 13, 2010 at 7:15 PM, Elias Önal <[email protected]
> <mailto:[email protected]>> wrote:
>
> 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]>
> > <mailto:[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]
> <mailto:[email protected]>.
> More information about Crypto++ and this group is available at
> http://www.cryptopp.com.
>
>
>
>
> --
> smu johnson <[email protected] <mailto:[email protected]>>
>
--
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.
