Link from AffinePoint,ProjectivePoint and Scalar to curve type #1995

Activity

1. tarcieri commented on Sep 4, 2025

   

   tarcieri

   on Sep 4, 2025

   Member

   More actions

   #1911 seems relevant here.

   I'll say the general idea of even having the ZST and functions impl'd on it permits access to the entire family of types. I've generally thought of it as a top-down hierarchy where elliptic-curve is solely additive upon group.

   Needing to go from one of the members of that family of types back to the ZST seems like a potential sign the functionality should be factored off of the ZST, or if that doesn't make sense, perhaps it should stay there.
2. daxpedda commented on Sep 4, 2025

   

   daxpedda

   on Sep 4, 2025

   Last edited by daxpedda

   ContributorAuthor

   More actions

   I will give more context then.

   Before RustCrypto/elliptic-curves#1389, the reason why we had this trait on the ZST instead of ProjectivePoint, is because it included hash_to_scalar(). Calling ProjectivePoint::hash_to_scalar() seems a bit messed up to me.

   After RustCrypto/elliptic-curves#1389, hash_to_scalar() is a separate standalone function. It seems obvious to me that ProjectivePoint::hash_from_bytes() and ProjectivePoint::encode_from_bytes() (both returning ProjectivePoint) seem better then NistP256::hash_from_bytes() returning a ProjectivePoint.

   The problem arises when we implement GroupDigest for ProjectivePoint (instead of the ZST), we don't have access to MapToCurve. So we could move MapToCurve to ProjectivePoint as well, but then hash_to_scalar() can't access MapToCurve::SecurityLevel. We could also require the standalone functions to require the ZST instead of ProjectivePoint and Scalar. Ergo hash_to_scalar::<NistP256, ...>(...) instead of hash_to_scalar::<Scalar, ...>(...), which is fine of course.

   However, I believe the ideal scenario would be something like this:

   impl MapToCurveParameters for NistP256 {
       type SecurityLevel;
   }
   
   impl MapToCurve for ProjectivePoint {
       type FieldElement;
       type Length;
   
       fn map_to_curve(element: Self::FieldElement) -> Self;
   }
   
   impl GroupDigest for ProjectivePoint: AssociatedCurve {
       const HASH_TO_CURVE_DST;
       const ENCODE_TO_CURVE_DST;
   
       type ExpandMsg: ExpandMsg<<Self::Curve as MapToCurveParameters>::SecurityLevel>;
   }

   ---

   Considering its totally possible to find other solutions to move GroupDigest to ProjectivePoint, if this is the only motivation, we can close this issue.
3. daxpedda commented on Sep 16, 2025

   

   daxpedda

   on Sep 16, 2025

   ContributorAuthor

   More actions

   I'm gonna go ahead and close this.

   I should mention that the original motivation is diminished as well if we want to move GroupDigest to Point<C> instead. See #1900 (comment).
4. daxpedda

   closed this as not plannedon Sep 16, 2025