Simon Josefsson simon@josefsson.org writes:
Wonderful. There is another document coming out (describing the Curve25519 algo only) which contains test vectors from the NaCl library as well, including them would be good.
URL?
I have a couple of questions ragarding curve25519.
1. The input of the curve255519 function is the x coordiante only. I compute the y cordinate, via a square root. This might fail... I don't really understand Theorem 2.1 in the curve25519 paper, but it seems to indicate that for curve25519 to be defined for arbitrary x, one needs to consider coordinates in the extended field
x = x_0 + x_1 sqrt(2) y = y_0 + y_1 sqrt(2)
Obviously I don't want to do this. I think one can get away with treating x inputs where the square root fails as invalid. That shouldn't happen for public keys computed according to the spec.
Are there any testcases for such questionable inputs?
2. API for the curve25519 function. I think I sent a mail about this previously. Should it be a single function (with some magic optimization for the input x == 9), or two functions? What do the NaCl and Sodium libraries do, and do they get it right?
3. I haven't yet figured out how to do the user-api using struct ecc_curve. I think I'll have to make functions like ecc_mul_g and ecc_mul_a go via function pointers in this struct, and also some abstract functions for converting points to and from an unspecified internal coordinate representation, which will be jacobian or edwards, with or without redc.
Internal functions like ecc_add_jja have to move from ecc.h to ecc-internal.h, and there maybe some new more abstract functions for operating on points, regardless of internal coordinate representation.
4. Also, things need to be organized so that curve2519 and EdDSA can share the internals in a clean way. Maybe there could be two struct ecc_curve for the two equivalent curves, which differ only in conversions done on input and output.
Regards, /Niels