Thank you for your reply. Maybe we can drill down on the client key exchange message first. Looking at the rfc I see it should hold: ECPoint ecdh_Yc;
But for the prime192 curve, I would have expected an uncompressed point to be only 48 bytes. The size of the client key exchange message is 66 bytes. What is in the remaining bytes? Thanks, -Mike --- On Thu, 9/24/09, Dave Thompson <dave.thomp...@princetonpayments.com> wrote: > From: Dave Thompson <dave.thomp...@princetonpayments.com> > Subject: RE: trying to understand ECDHE operations > To: openssl-users@openssl.org > Date: Thursday, September 24, 2009, 6:23 PM > > From: owner-openssl-us...@openssl.org > On Behalf Of Michael D > > Sent: Thursday, 24 September, 2009 09:12 > > > I have been playing with an the command line tools of > open > > SSL and am examining traces in hopes to get an > understanding > > of how ECDHE works in real life. > > > Remember commandline s_client and s_server can do their own > > 'tracing' (-msg and -debug displays); that may be helpful. > > > My confusion focuses on the Client Key Exchange, > Change > > Cipher Spec, Encrypted Handshake message. > > > > The server has selected: > > TLS_ECDHE_ECDSA_WITH_AES256_CBC_SHA (0x00a) for the > cipher suite. > > > > My EC Public Key is: (from my certificate) > > > > 04:b9:53:3e:60:db:02:2c:6e:c4:ed:15:95:87:26: > > > > 1b:c9:96:ae:c9:a8:64:03:3a:6a:8d:14:ce:69:05: > > > > fc:4b:ea:4c:ed:a1:7f:6e:9f:37:74:20:f0:42:e2: > > > 69:a0:02:48 > > The algorithm is: > > > ASN1 OID: prime192v1 > > > > For ECDHE (E=ephmeral) the key in the cert is only for > signing. > The key-agreement key is in ServerKeyExchange for the > server, > and ClientKeyExchange for the client. I believe technically > > those don't have to be the same parameters (hence point > size) > as the signing key, but in practice they probably will be. > > > So, to make this short, what exactly is contained in > the: > > - Client Key Exchange message? > > Is this the clients 'public > key', so should be the same size > > as the server public key? > > > The same size as the server's (ephemeral) *key-agreement* > key, yes, > which as above is *probably* the same as the fixed-signing > key. > > > - Change cipher spec. > > Does this tell the server server > to switch to the AES256? > > > There is a ChangeCipherSpec message in each direction. Each > one > tells the recipient of that message to begin using the > ciphersuite > and (session) keys determined by the handshake, which in > this case > is AES256-CBC and HMAC-SHA1. > > > - Encrypted handshake message? > > Does this contain a new key > with which to use with AES256? > > > The first message you see after ChangeCipherSpec, again in > each > direction, is actually the Finished message. It contains a > (quasi) > signature of the handshake sequence, which verifies the > handshake > wasn't tampered with. It shows up in a trace only as > 'encrypted > handshake message' because it is encrypted and so the trace > tool > can't decode its contents. Unless you have an SSL-aware > trace tool > with the privatekey material(s?) available to it. > > The session keys are derived from the 'premaster secret' > agreed by > the handshake plus nonces from each party in the Hello > messages. > This derivation is the same for all ciphersuites, only the > premaster > secret agreement varies; for ECDH(E) it uses elliptic > Diffie-Hellman. > > > > > ______________________________________________________________________ > OpenSSL Project > > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager > > majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
