If you're using TLS, the protocol does all of this for you. You don't have to worry about it.
Long-winded explanation: The public/private keypairs that each peer creates have a public part (the part that is signed by the CA, and made available to the peer that they want to communicate with) and a private part (a part that they never, ever, ever show to anyone else). These keypairs have the property that anything encrypted with the public key can only be decrypted with the corresponding private key, and anything encrypted with the private key can only be decrypted with the corresponding public key. Since all peers have a keypair, and they're all generated randomly, none of the keypairs will match anyone else's. TLS uses this property to perform zero-knowledge proofs that each side knows the correct and corresponding private key. Then, they use this information to generate a "session keys", which is used to initialize the stream ciphers and HMACs in a way that reduces the possibility of successful cryptographic analysis. This session key is created in a way that prevents any eavesdropper from figuring out what it is, though both sides know what it is. Once this is done, the channel is 'secure' and user data can start flowing, without having to worry about anyone else being able to get anything intelligible from the conversation. However, the secret keys must be kept secret, or else anyone who obtains even one of them and has a recording of the traffic between the two peers will be able to decrypt all of the conversations. -Kyle H On Thu, Apr 10, 2008 at 9:22 PM, Julian <[EMAIL PROTECTED]> wrote: > Here is what I came up with: > > Peer A, B, C. > > Peer A, B, C generates 2 2048 bit RSA keys. > > Peer A, B, C connects to Login server over TLS. > > Login server signs each key and signs only one for key signing. > > Peer A generates a session key and signs it. > > Peer A connects to Peer B over TLS. > > Peer A exchanges public key with Peer B. > > Peer A and B now have encrypted channel that C cannot decrypt. > > Thoughts? > > > > On Apr 10, 2008, at 4:59 AM, Kyle Hamilton wrote: > > > > If E got the public key of the server, then he would be able to > > authenticate certificates signed by the server. The 'secret' or > > 'private' key is what's needed to create a signature for a > > certificate, and without it it's impossible to perform the proof that > > the private key is known to E. (sure, E could present that > > certificate -- but the next step of the TLS protocol is to verify that > > E has the private key associated with the public key embedded in the > > certificate, and E would not be able to do that and the handshake > > would fail.) > > > > In any case, though, the security of the system does not depend on the > > public key being limited to only 'trusted' entities. > > > > I recommend that you look at a text on asymmetric ciphers, or > > public-key cryptography, to better understand this concept. > > > > -Kyle H > > > > On Wed, Apr 9, 2008 at 2:44 PM, Julian <[EMAIL PROTECTED]> wrote: > > > > > If E got ahold of this key it could complete a handshake to the server > get > > > sensitive data? > > > > > > > > > > > > > > > > The 'key' that you need to include with your binary is actually the > > > > CA's certificate (which contains the CA's public key). You don't need > > > > to include any 'trusted' information in the client other than that, > > > > and you don't need to include any 'secret' information at all. > > > > > > > > > > > > > > ______________________________________________________________________ > > > OpenSSL Project http://www.openssl.org > > > User Support Mailing List openssl-users@openssl.org > > > Automated List Manager [EMAIL PROTECTED] > > > > > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List openssl-users@openssl.org > > Automated List Manager [EMAIL PROTECTED] > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
