# When is the public ECC key generated?

I have been learning about the fundementals of ECC and I'm a bit confused on this point: What makes up the public key in an ECC key exchange, and when is this public key generated?

In the video at https://www.youtube.com/watch?v=F3zzNa42-tQ and the StackOverflow Q&A Basic explanation of Elliptic Curve Cryptography? , it is stated that the public key is generated when the key exchange takes place. The public keys are the Generator point "times" the private key of each party. Because the Generator point changes for each handshake, the public key must not be generator beforehand.

If this is the case, then what is the purpose of ever generating an ECC public key? For a project I am working on, it is necessary to generate a public key to be placed in a certificate signing request to connect with AWS. Also, there is openssl functionality for creating ECC public keys:

openssl ec -in ecc_private.pem -pubout -out ecc_public.pem

Is the word "public key" being loosely used? Are there multiple public keys?

• I don't watch videos, but IF they're talking about TLS-formerly-SSL (and protocols layered on it like HTTPS) it is now fairly common to use elliptic Diffie-Hellman with 'ephemeral' keypairs (generated during the handshake, used once and destroyed) for the actual key agreement, and authenticate it with elliptic DSA using a long-term key in a certificate. This is designated in the ciphersuite names as ECDHE-ECDSA (EC DH Ephemeral signed by EC DSA). So in this case yes there are multiple keyPAIRs, each with a publickey. – dave_thompson_085 Jan 26 '18 at 4:55

As already indicated in the other answer $A$ and $B$ in the video are the public keys of Alice and Bob. The public keys are part of the key pair generation by each one of the parties, usually denoted $\operatorname{Gen}$. With ECC the keys can be generated from the private key at any time, as the public key is generated after the private key within the $\operatorname{Gen}$ function, namely by multiplying the private key value with the base point $G$.

The base point is part of the domain parameters agreed upon by client and server during the handshake and is not expected to change for ECDH. When performing ephemeral-ephemeral key agreement a key pair is regenerated by each party. In that case the key agreement does not perform authentication of any party as the public key cannot be trusted by the other party; authentication is performed separately. That authentication could be performed using any means, including ECDSA with a different, static key pair. In that case the static public key is commonly within a certificate signed by a certificate authority.

What you are generating is a static or key which has the life time displayed in the certificate (after which it isn't trusted anymore, it doesn't self destruct). That key is still just the the private key $s$ multiplied with $G$ of the domain parameters. This is a deterministic calculation: there is therefore only one public key per key pair. The parameters used for this key can be different from the parameters used for the ephemeral key pair used for key agreement; the parameters are indicated by the encoding of the public key in the certificate.

So no, the term "public key" is not used "loosely" here.

There is also ephemeral-static and even static-static Diffie-Hellman, although neither of them is often used. In that case the static public keys can be part of a certificate and trusted. So the entities holding the static keys are then authenticated. A party with an ephemeral key pair isn't authenticated and may need to log in, in case it is a website user, for instance.

As indicated, this isn't used as much; ECDH certificates are not commonplace and static Diffie-Hellman doesn't offer forward secrecy - the session data will become known if the confidentiality of the static key is compromised.

You're generating a static key pair which can be used for authentication. When using a ECDHE ciphersuite you'll need to generate a ephemeral key pair as well, but this is hidden in the TLS implementation. Fortunately generating ECC key pairs is relatively fast: just randomization and point multiplication. This is one of the main benefits of using ECC.

• you state "What you are generating is a static or key which has the life time displayed in the certificate (after which it isn't trusted anymore, it doesn't self destruct). That key is still just the the private key ss multiplied with GG of the domain parameters" - if I generate this prior to communicating with AWS, before the CSR, how would I have an agreed upon G? – Code Wiget Jan 26 '18 at 15:02
• Also, how does authentication with this signed public key(certificate) fit into the key exchange we mentioned? Thanks for your help! – Code Wiget Jan 26 '18 at 15:04
• No, the static key isn't used for the key agreement part at all, it is used to sign the session up to the key agreement for authentication after the key agreement has taken place. The parameters for the key agreement are in the client's HELLO extensions, or at least they are referenced by name (with the parameters simply hard coded). The public key in the certificate is independent of the parameters in the HELLO message. – Maarten Bodewes Jan 26 '18 at 16:22

With the notation of the video, $A = \alpha G$ is seen as the public key of Alice and $B = \beta G$ as the public key of Bob.

Alice computes the shared Diffie-Hellman key using her private key $\alpha$ and Bob's public key $B$ as $K = \alpha B$.

Bob does similarly using his private key $\beta$ and Alice's public key $A$ to get the shared Diffie-Hellman key $K = \beta A$.

It is easily verified that the shared key computed by Alice is the same as the one computed by Bob: $\alpha B = \beta A = (\alpha\beta)G$.

• The question asks: “If this is the case, then what is the purpose of ever generating an ECC public key?” and ”Is the word "public key" being loosely used? Are there multiple public keys?” – it would be nice if you would edit our answer to add a few words answering those questions. Currently, all I see is an explanation of what goes on in the linked video… which hardly answers what is being asked. – e-sushi Jan 26 '18 at 7:17
• @user, this doesn't answer the question. I watched the video, i understand the concept. The question is why generate a public key from the start if you generate one during the handshake. The answer is correct from Maarten, that the keys are ephemeral. – Code Wiget Jan 26 '18 at 15:04