EC_METHOD struct
Hello In the EC_METHOD structure, the pointers to methods for converting between affine and projective coordinates are named: `point_set_Jprojective_coordinates_GFp` and `point_get_Jprojective_coordinates_GFp` Does that mean any implementation of EC_METHOD (for prime curves) can only use Jacobian coordinates? Is it not possible to use some other coordinate system (may be homogeneous)? -- :-)balaji __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EC_METHOD struct
balaji marisetti balajimarise...@gmail.com: In the EC_METHOD structure, the pointers to methods for converting between affine and projective coordinates are named: `point_set_Jprojective_coordinates_GFp` and `point_get_Jprojective_coordinates_GFp` Does that mean any implementation of EC_METHOD (for prime curves) can only use Jacobian coordinates? Is it not possible to use some other coordinate system (may be homogeneous)? This method name just means that the EC_METHOD implementation should support setting points based on Jacobian coordinates. Internally, it might convert them to something else. (Or, the EC_METHOD could entirely omit support for this method. Typical usage of the ECC library won't depend on this.) Bodo
Re: EC_METHOD struct
Wouldn't it have been simpler to name these function pointers just projective instead of Jprojective? This way, EC methods that use different projective system than jacobian could have their own implementation to set/get projective co-ordinates and use these function pointers without confusion. Another reason for this is, new EC methods that get implemented would take existing simple EC method as reference and steal as much code (as many functions) as possible from it. In simple EC method, set_affine_coordinates would internally call set_projective_coordinates with Z as 1. One cannot stick to this code, and leave set_projective function unset at the same time. Here, change is necessary to call the internal function instead of the function pointer that sets x, y, 1 to X, Y, Z. On Wed, Jul 16, 2014 at 4:48 PM, Bodo Moeller bmoel...@acm.org wrote: balaji marisetti balajimarise...@gmail.com: In the EC_METHOD structure, the pointers to methods for converting between affine and projective coordinates are named: `point_set_Jprojective_coordinates_GFp` and `point_get_Jprojective_coordinates_GFp` Does that mean any implementation of EC_METHOD (for prime curves) can only use Jacobian coordinates? Is it not possible to use some other coordinate system (may be homogeneous)? This method name just means that the EC_METHOD implementation should support setting points based on Jacobian coordinates. Internally, it might convert them to something else. (Or, the EC_METHOD could entirely omit support for this method. Typical usage of the ECC library won't depend on this.) Bodo
Re: EC_METHOD struct
Thulasi Goriparthi thulasi.goripar...@gmail.com: Wouldn't it have been simpler to name these function pointers just projective instead of Jprojective? This way, EC methods that use different projective system than jacobian could have their own implementation to set/get projective co-ordinates and use these function pointers without confusion. Well, I don't necessarily agree with the without confusion part ... The behavior that you get with these methods would then depend on the internals of that implementation, which isn't necessarily what users might expect from the library. If someone uses (the hypothetical) EC_POINT_set_projective_coordinates_GFp with Jacobian coordinates but these are interpreted as something else, that could be a problem. Another reason for this is, new EC methods that get implemented would take existing simple EC method as reference and steal as much code (as many functions) as possible from it. In simple EC method, set_affine_coordinates would internally call set_projective_coordinates with Z as 1. One cannot stick to this code, and leave set_projective function unset at the same time. Here, change is necessary to call the internal function instead of the function pointer that sets x, y, 1 to X, Y, Z. I know -- if you don't implement point_set_Jprojective_coordinates_GFp, you'll have to provide your own point_set_affine_coordinates_GFp (etc.). That should be straightforward in any case, though. You'll necessarily have to implement point_get_affine_coordinates_GFp, which will be more involved. I think at least for the get functions, it should be pretty clear why I prefer to have an explicit Jprojective in the function numbers, rather than merely projective: if ec_GFp_simple_point_get_affine_coordinates were to use a generically named EC_POINT_get_projective_coordinates_GFp instead of the actual EC_POINT_get_Jprojective_coordinates_GFp, you'd have to pay more attention to notice that it's not actually appropriate for the coordinates that your implementation is using. Bodo
