On the Parallelization of Square-Root Vélu’s Formulas

Round 1

Reviewer 1 Report

This paper discusses the parallelization of the square-root Velu formula for isogeny operations. In contrast to SIDH-based cryptography using 2- and 3-isogenies, other isogeny-based cryptography employs odd-degree isogenies.

Particularly, considering precise quantum analysis results for CSIDH and the SQISign specification, it is evident that larger isogeny degrees are necessary, making square-root Velu operations essential in this context.

The paper effectively explains the need for the study, provides background information, and details the research content.

While it would be beneficial to present speed-up factors by applying the findings to actual isogeny-based algorithms, as the performance of the isogeny-based cryptography is mainly determined by isogeny computations, the experimental results in the paper are meaningful as it is.

<Minor comments>

- page 4. equation in lemma 1. X is missing

X^2+\frac{F_1(x(P),x(Q))}{F_0(x(P),x(Q))}X+\frac{F_2(x(P),x(Q))}{F_0(x(P),x(Q))}

- page 5. equation in Lemma 2. It seems that variable i should be changed to j.

E_J(X,Z)=\prod_{j\inJ}

Author Response

Please see the attachment

Author Response File: Author Response.pdf

Reviewer 2 Report

This paper proposes the parallelization method to compute sqrt Velu formulas. Their methods provide an efficient computation of large-degree isogenies with n cores.

It is an important task for isogeny-based cryptography to implement their cryptosystems in computational costs. A parallelization is one direction to reduce their computational costs. However, there is not much research on the parallelizations of isogeny-based cryptography somehow.  So, this research is important from the sight of implementing isogeny-based cryptography.

They also provided the source code of their parallelization. It's nice for everyone to check their theory.

This paper is well-written, and I couldn't find any fatal errors in this paper.

I think this paper is worth accepting.

Minor comments:

- I think there are some studies about sqrt-Velu formulas of elliptic curves in other forms (e.g., Edwards, Huff's), and these formulas may be reduced to Montgomery curves by The Generalized Montgomery Coordinate: A New Computational Tool for Isogeny-based Cryptography (iacr.org). I guess this technique is also adapted to these formulas. If so, it is better to mention these studies.

- If my understanding is correct, IS-CUBE does not use sqrt-Velu formulas. The binSIDH may use them.

- p.13, line 6: "xISOG-Parallel" went outside of the area.

- p.17, the end of the proof of Prop. 3: \qed went to the next line.

- p.17, Prop. 4: There is a weird space between "=" and "6b"

- p.21-23: Use align* or something for multi-line equations.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 3 Report

This is a well written paper about the potential of parallelization when computing and evaluating prime-degree isogenies using square-root Vélu's formulae. The work provides a revised cost model of reference [23] in the paper and explains how this cost estimate changes when distributing work over multiple processors. I believe this work to be of sufficient interest to be published in MCA.

Some minor comments:
- When motivating you may want to also mention that this would be of interest if anybody would have the idea to instantiate the VDF by De Feo, Masson, Petit and Sanso with larger degree isogenies. Also in the more recent "effective" group actions that generalise CSI-FiSh to larger security levels, e.g. SCALLOP, larger degree isogenies may be computed. (I appreciate, that in both cases you are not working over the base field, but this is also true for some other applications you motivate your work with)

- line 340: "Algorithm" is missing in front of the "4"
- line 421: "analyzis" -> analysis

- You observe that for larger number of cores your expected results seem to further diverge from the experimentally observed results. Is there some good explanation for that or might this be an indicator there is some small factor missing in the expectation? (This would be indipendent of the explanation you give for the diminishing returns by using more cores you give in the end.)
- It would be nice if you could add some small comments about the overhead incurred by distributing all the tasks to n processors and combining the results again in the end. This may not be a (big) issue for 2,4,8 processors, but probably becomes one later..

Author Response

Please see the attachment.

Author Response File: Author Response.pdf