Rename "ephemeral key share" to "ephemeral public key"

[kevinlewi]

Closes #371.

See the discussion in #371 for more context. Note that this only changes the prose describing the variable names, and not the variable names themselves.

cc'ing @stef for feedback

[stef]

great thanks! only nit, for me it's the variable names also that are confusing. everytime i look at the testvectors, most of the variables are obvious, but the keyshare vars are always confusing me. would it be a big thing to also rename them?

[kevinlewi]

@stef: Personally, I'm reluctant to do the variable renaming because I think it is too big of a change at this point. But perhaps if others chime in with an opinion on whether or not it's worth the variable renaming, we could consider it? @bytemare @chris-wood

[bytemare]

I'm not against, for consistency I think it's better to also rename the vectors. (New implementors or readers might get a bit confused)

[kevinlewi]

Here are the four variables we would need to rename:

• server_keyshare
• client_keyshare
• server_private_keyshare
• client_private_keyshare

For context, these names were originally decided on in https://github.com/cfrg/draft-irtf-cfrg-opaque/commit/87c3287dc789eda67dcb93fbd481334025c71cc6 , where their previous names were:

• epkS, epkU, eskS, eskU

Any proposals for what each of these should be renamed to? Some options that come to mind: 1) client_e_pk, client_e_sk, server_e_pk, server_e_sk 2) client_ephemeral_public_key, client_ephemeral_private_key, server_ephemeral_public_key, server_ephemeral_private_key

[stef]

I think it is too big of a change at this point.

why do you think so? for existing implementations nothing changes. it helps clarity.

both of your proposals are good, but since this is a spec, clarity and expressiveness should trump brevity so i would prefer the 2nd. but i also have to admit that in my code i still use the names from 87c3287 - which i think despite their cryptic shortness are still more expressive than keyshare.

[stef]

oh i see the sage ref impl needs to be changed i guess?

[kevinlewi]

Yes, the implementation itself (the code which produces the test vectors) would also need to be adjusted accordingly. I'd like to wait and see until we have others chime in with thoughts on this here before making the change. IMO although the name keyshare may not be 100% illustrative as a variable name, it doesn't seem to significantly detract from a reader understanding the protocol (given that we also define the variable as being the ephemeral public/private key already).

[stef]

IMO although the name keyshare may not be 100% illustrative as a variable name, it doesn't seem to significantly detract from a reader understanding the protocol (given that we also define the variable as being the ephemeral public/private key already).

true, it only confuses when working with the test vectors.