# How does ECDHE_RSA key exchange mechanism work?

Using Wireshark, I found these data exchanged with google.com over TLS:

1. Client Hello
• possible cipher suites and possible curve types (eg. secp256r1) sent
2. Server Hello
• cipher suite selected
3. Certificate
• RSA certificate signatures exchanged, etc. (hopefully, not important for me)
4. Client Key Exchange, Change Cipher Spec, Hello Request
• ECDHE pubkey sent to server
5. New Session Ticket, Change Cipher Spec, Hello Request, Application Data
• session ticket received, etc. (hopefully, not important for me)

Ok, and now my question: What I learned, I need curve equation, random point on it and the finite field size (for modulo operation) in order to apply ECC.

The only thing I found was the pubkey of size 520 bits, which should represent:

• 1st 8 bits - base 16 prefix
• next 256 bits - X coordinate of the "random point"
• last 256 bits - Y coordinate of the "random point"

Ok, I have the point, but what about the curve equation and the field size?

Does the curve secp256r1 define only one specific curve? (I suppose not, so where/how is it defined?)

What is and where to find the size of the field? (Or is there only one size for given standard? ...don't think so.)

PS: This is how I understood the topic, if I'm wrong, please, correct me. :)

Curve secp256r1 is not a type of curve; it is a curve, and is standardized under that name by SECG, under the name P-256 by NIST, and under the name prime256v1 by ANSI. It also happens to be the by far the most common elliptic curve used in cryptography. The field size, curve equation, and generator point are all part of the curve spec; the point of having a standardized curve is that it takes time to generate elliptic curve parameters, and there's no need for different people to use different curves.

Incidentally, based on your not mentioning the generator point you might be a bit mistaken on how the "random point" in ECDH is created. An ECDH key doesn't just have a randomly selected point for a public key; rather, you randomly pick an integer $k$ as your private key, and then compute the public key as $kG$ for a known point $G$. Like the curve parameters, both parties must know $G$; like the curve parameters, there's no reason why everyone in the world can't use the same $G$. So, this generator point is also part of the curve spec.

You also missed a crucial step in ECDHE: the ServerKeyExchange message. This is a mandatory part of ECDHE exchanges, and comes after the Certificate message and before ServerHelloDone. This has the server's ephemeral ECDH public key; the ClientKeyExchange has the client's ephemeral key.

• ok, so the equation, the field size and the point is defined by secp256r1. Then the point I mentioned, which is sent to server, is the kG, right? But what about the the server's qG? I didn't find it anywhere and yet I think it's necessary for the symmetric key used for the actual encryption. In terms kqG (server side) = qkG (client side) = the symmetric key used for AES, right? Thank You! – user2781994 Mar 24 '15 at 18:26
• @user2781994 See edit. There also is a ServerKeyExchange message with the server's public key. – cpast Mar 24 '15 at 18:43
• Yay! I found it, don't know how I could miss it. But still the size of the server key is 1154 bits (without handshake type byte and 3 length bytes). What is sent there since you said this should be only qG point coordinates (256-bit for X and the same for Y)? Thanks. – user2781994 Mar 24 '15 at 19:26
• @user The server key exchange is a signed ECDH public key. That's what the public key in the server cert is used for -- it ties the server's ephemeral ECDH key to the cert, which ties it to the domain. – cpast Mar 24 '15 at 23:34
• Nitpick: ServerKX contains the curve parameters (which apply to both peers) and server pubkey (a point), plus the signature. The parameters can be "explicit" with the actual prime (Fp) or polynomial (F2^n), curve coefficients, base point, order and cofactor, but in practice people use the standard curves which are identified by a 2-octet code number (see rfc4492) which is small and easily overlooked in the decode. ClientKX contains only the client pubkey (a point); if client is authenticated, which is rare, its signature is in a separate message CertVerify. – dave_thompson_085 Mar 25 '15 at 3:44