|
MoneroResearch.info |
 |
 |
 |
|
Bassa, A., & Sepanski, B. (2025). Security Assessment for the Helios–Selene Curve Cycle. Unpublished manuscript. Added by: Rucknium (29/10/2025, 15:15) Last edited by: Rucknium (29/10/2025, 15:16) |
 |
| Resource type: Manuscript BibTeX citation key: Bassa2025 View all bibliographic details  |
Categories: Monero-focused Subcategories: Full-Chain Membership Proofs Creators: Bassa, Sepanski Collection: Veridise |
Views: 86/87
|
Attachments
Monero_251008_Helios_Selene_updated_report.pdf  [33/33]
|
| Abstract |
|
In August 2025 Veridise was engaged by Monero to conduct an assessment of security and suitability for FMCP++ [13] of the Helios/Selene curve cycle introduced by tevador [16]. Further details have been provided below. The result of the assessment can be summarized below: As cycles of curves necessarily have prime order, some of the criteria applied to curves (see for instance [5]), in particular in the DH context, are not applicable and not necessary for the very particular intended use. In particular criteria about ladders, completeness and indistinguishability can only be partially satisfied, but this does not pose a security threat for the particular use. Care should however be taken during the implementation for possible shortcomings of the curves in this respect. In particular it should be ensured that curve membership checks for points are performed whenever necessary. Moreover, completeness issues (operations involving the identity point, doublings and additions to inverses) should be handled carefully during implementation. As the only feasible way of constructing cycles of curves of cryptographic sizes is through the use of complex multiplication methods, the resulting curves will (by construction) have small discriminants. As in the case of pairing friendly curves, requiring a lower bound of 2100 as in the case of SafeCurves is not an option. Computationally it would be possible to reach CM field discriminants at the order of 250, but because of the sparsity of suitable discriminants at this order this might imply security and efficiency sacrifices at other places, hence this is not required. There are however more serious issues regarding rigidity and twist security. For details see Sections 2.7.6 and 2.7.7. |