On 02/14/2013 08:46 AM, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
About the naming you use ecdsa_private_key and public_key. Note that this is the same key for static ECDH, and I think MQV.
Do you have any suggestions for improved naming? I understand ECDH, although it has been a very low priority for me so far, but I'm not familiar with MQV. Would it be better with more algorithm-neutral names, like "ecc_point" and "ecc_scalar"?
The way I think about it, the ecdsa_public key is a combination of a point and a curve-specification. If I add a highlevel "ecc_point" type, should that include a pointer to the curve or not?
Any of those would be fine (I prefer point as more intuitive). Having a pointer to the curve is a good thing I believe (a point on that curve). I don't think there are cases where a point can be used in multiple curves. It should be easy to generate those structures from x,y pairs and knowledge of the curve.
void ecdsa_private_key_mul (const struct ecdsa_private_key *key, mpz_t new_x, mpz_t new_y, const mpz_t x, const mpz_t y);
(these are not very good names, but I hope you get the idea). At least, if we think about ECDH as using a temporary keypair, then I think it's clearest to view the above operation as an operation using out private key, not as an operation involving the other party's public key.
Also a function that checks whether a point lies on a curve would be needed (may already be there, didn't check).
At least, fips-186-3 is not very specific, I think it allows any any "approved" hash function with security level high enough for the application. Or even any combination of approved curve and approved hash function where *both* have high enough security level for the application.
Then you may allow hashing directly the output of the hash and not bother with that.
regards, Nikos