A Faster Variant of CGL Hash Function via Efficient Backtracking Checks

Abstract

CGL hash function is an isogeny-based hash function that computes non-backtracking paths on a supersingular isogeny graph. Since one of the problems of CGL hash function is its relatively slow computational time, many acceleration methods have been studied, including the use of Legendre form, radical isogenies. An algorithm for computing CGL hash functions proposed at SAC’22 has achieved acceleration of several orders of magnitude, by using $2^n$-isogeny for an integer $n = \varTheta (\log p)$, where p is characteristic of the underlying field. In the algorithm, the backtracking 2-isogeny between two consecutive $2^n$-isogenies must be prevented to assure the security of the hash function.

In this paper, we propose a faster algorithm for CGL hash function by reducing the overhead of the backtracking check in the method at SAC’22. Moreover, as no explicit implementation of the aforementioned algorithm exists to the best of our knowledge, we implement the algorithm with our proposed backtracking check. We conduct a detailed and precise complexity analysis of the algorithm and other previously proposed ones, by programmatically counting the actual number of operations over the underlying finite field. We demonstrate that the proposed algorithm reduces the cost by $7.6\%$ compared to the original algorithm with 256-bit prime, achieving the fastest computation of CGL hash functions.

A Appendix

1.1 A.1 Collision Finding for DPB Method Without the Backtracking Check

We show that the backtracking check in DPB method is necessary to be collision-resistant. When the backtracking check is removed, DPB method can compute backtracking paths, which corresponds to non-cyclic isogenies. Thus, the collision-resistance of DPB method is not reduced to Problem 2.

Fig. 1.

The strategy to find a collision for DPB method without the backtracking check

Actually, we can show a polynomial time collision-finding algorithm for DPB method without the backtracking check. The strategy is shown in Fig. 1. We assume that n is even. We can compute $m,m_0,m_1\in [0,2^n)$ such that $h(m) = h(m_0 || m_1)$, where h is the hash function and || is the concatenation. Let $\{P_0, Q_0\} \subset E_0[2^n]$ be a basis of $E_0[2^n]$, $E_1$ be $E_0/\langle P_0 + m_0Q_0 \rangle$, and $\{P_1, Q_1\} \subset E_1[2^n]$ be a basis of $E_1[2^n]$. The collision pair satisfying $h(m) = h(m_0 || m_1)$ implies that $j(E_0/\langle P_0 +~\hbox {m} Q_0\rangle ) = j(E_1/\langle P_1+m_1Q_1\rangle )$.

Firstly, the integer m is randomly selected. Then, $m_0$ is selected as the lower n/2 bits of $m_0$ is the same as that of m. The selection makes the first n/2 steps of the paths corresponding to m and $m_0$ the same. Finally, we compute $m_1$ so that the path corresponding to $m_1$ can track the path to $E_0/\langle P_0+mQ_0\rangle$, which is possible by deciding $m_1$ from lower bits.

The algorithm fails when the backtracking isogeny cannot be computed at the curve $E_1$. However, the probability of the failure is negligible by selecting the upper bits of $m_0$ randomly. The algorithm is a probabilistic polynomial time algorithm overall, and we actually found collisions. The code to find collisions is available at the following GitHub repository: https://github.com/hedwig100/cgl-cost-evaluation.

1.2 A.2 The Cost Ratios of Each Operation in $\mathbb {F}_p$

The cost ratios of multiplication, square, addition, and inversion in $\mathbb {F}_p$ are computed using Boost Multiplication Library. The computed ratios are listed in Table 3. These ratios are used to convert the complexities represented by $\textrm{M},\textrm{S},\textrm{A}$, and $\textrm{I}$ in Table 1 to the complexities represented only by $\textrm{M}$ in Table 4. The acceleration ratios in Table 2 are computed from the complexities represented only by $\textrm{M}$.

Table 3. The cost ratios of each operation in $\mathbb {F}_p$ for 256, 512, 1024, 1536-bit primes

1.3 A.3 The Costs Represented only by Multiplication

The complexity represented in Table 1 is converted to the complexity represented only by $\textrm{M}$ using the cost ratios in Table 3. The converted complexities are listed in Table 4.

Table 4. The average complexities of each algorithm to compute hash per bit of input. These complexities are represented only by $\textrm{M}$ using the ratios in Table 3.