On 02/14/2013 08:46 AM, Niels Möller wrote:

> Nikos Mavrogiannopoulos <[email protected]> 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


_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Reply via email to