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?
If there is a function to do the DH multiplication k*(ecdsa_public_key) I think the gnutls could be tested with that interface,
For ECDH, you could generate a new keypair (P, z) with ecdsa_generate_keypair, send the "public key" P as a point Q to the other party, receive another point Q, and then to compute Y one would need a function like
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.
ECDSA-256 256-bit random ECP group SHA-256 ECDSA-384 384-bit random ECP group SHA-384ECDSA-521 521-bit random ECP group SHA-512As far as I know these are the only allowed by the DSS standard (I was under the impression that SHA-224 was also allowed).
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.
Regards, /Niels