Poseidon2: A Faster Version of the Poseidon Hash Function

Abstract

Zero-knowledge proof systems for computational integrity have seen a rise in popularity in the last couple of years. One of the results of this development is the ongoing effort in designing so-called arithmetization-friendly hash functions in order to make these proofs more efficient. One of these new hash functions, Poseidon, is extensively used in this context, also thanks to being one of the first constructions tailored towards this use case. Many of the design principles of Poseidon have proven to be efficient and were later used in other primitives, yet parts of the construction have shown to be expensive in real-world scenarios.

In this paper, we propose an optimized version of Poseidon, called Poseidon2. The two versions differ in two crucial points. First, Poseidon is a sponge hash function, while Poseidon2 can be either a sponge or a compression function depending on the use case. Secondly, Poseidon2 is instantiated by new and more efficient linear layers with respect to Poseidon. These changes allow to decrease the number of multiplications in the linear layer by up to 90% and the number of constraints in Plonk circuits by up to 70%. This makes Poseidon2 the currently fastest arithmetization-oriented hash function without lookups.

Besides that, we address a recently proposed algebraic attack and propose a simple modification that makes both Poseidon and Poseidon2 secure against this approach.

Keywords: Poseidon – Poseidon2 – ZK Application – Sponge/Compression Mode

1. Introduction

The area of zero-knowledge proof systems has seen a rise in popularity during the last couple of years. Arithmetization techniques such as R1CS used in Groth16 [Gro16], AIR used for FRI-based commitments [BS+18a, BS+18b], and Plonk [GWC19] and Plonk-style arithmetizations (e.g., [GW22] used in halo2 [Zca22]) make it possible to efficiently verify the correctness of a computation.

Most of these proof systems internally use hash functions for the purpose of polynomial (Merkle tree) commitments. These hash functions are rather different compared to more traditional primitives. Indeed, while the latter are often optimized for plain performance in software or hardware implementations, constructions for proof systems mostly focus on minimizing the number of constraints (similar to gates) when writing them down in a specific circuit language. This fact has led to new symmetric designs, exhibiting sometimes unusual symmetric building blocks (e.g., sacrificing plain performance in order to obtain a simpler description in a certain proof system).

In the literature, hash functions fulfilling these properties are often described as being arithmetization-oriented or circuit-friendly, which refers to their focus towards use cases of computational integrity. Besides Poseidon [GKR+21], examples of such constructions include MiMC/GMiMC [AGR+16, AGP+19], Friday [AD18], Rescue [AAB+20], Neptune [GOPS22], Anemoi [BBP+22], Griffin [GHR+23], and lookup-based primitives such as Reinforced Concrete [GKL+22] and Monolith [G+23]. In the last years, the knowledge of designing arithmetization-oriented hash functions has evolved, and more specific design goals are known today.

The Origin of Poseidon. In this paper, we mostly focus on the Poseidon hash function. First described in 2019 [GKR+19], it is heavily based on the HadesMiMC family of block ciphers [GLR+20]. The key property of HadesMiMC is that it uses two different round functions, one containing a full nonlinear layer with S-boxes applied to the entire state, and one containing a partial nonlinear layer with the S-boxes only affecting part of the state. This approach was chosen in order to provide convincing security arguments against statistical attacks using the full rounds while at the same time increasing the degree efficiently (i.e., by using a smaller number of S-boxes) using the partial rounds. However, HadesMiMC was designed with MPC use cases in mind, which has very different properties and optimization goals compared to modern proof systems. Most importantly, all linear operations can be computed locally by every party in an MPC protocol. Since the final efficiency of such a protocol depends on the number of communication rounds and no communication is needed for linear operations, the main optimization goal of HadesMiMC was to minimize the number of nonlinear operations. As a result, the final number of linear operations turned out to be comparatively high, mainly due to many multiplications with matrices of large sizes. In particular, each round of HadesMiMC contains a multiplication of a t-element state with a dense and unstructured t \times t matrix over \mathbb{F}_p, where p is a comparatively large prime. Hence, this operation results in a number of multiplications in \mathcal{O}(t^2) over \mathbb{F}_p.

Similar to MPC use cases, in some arithmetization techniques (e.g., R1CS used in Groth16 [Gro16]), the number of nonlinear operations is also the main bottleneck. Hence, building a hash function based on the HadesMiMC permutation seemed like an efficient approach. This idea led to the specification of Poseidon, which is essentially a sponge hash function using an internal permutation similar to the one used in HadesMiMC (with minor differences such as the omission of a key addition). Poseidon has since been implemented and used in many different proving frameworks, including e.g. Ginger-lib [HL22] and Plonky2 [Pol22].

Plain Performance and the Plonk Arithmetization. Since the design of Poseidon, various new optimization goals emerged. For example, it became clear that plain performance must not be neglected, since among other things it plays a crucial role when building the commitments outside of the respective circuits. Recent hash function designs in this area acknowledge this fact and try to also optimize for plain performance.

Moreover, the variety of different arithmetization techniques has increased in the last couple of years. While R1CS was the main target for the original Poseidon, nowadays also the so-called algebraic intermediate representation (AIR) [BS+19] for FRI-based proof systems [BS+18a] or Plonk [GWC19] and "Plonkish" representations are popular approaches. Particularly, in Plonk linear operations also contribute to the final cost. Note that this is a clear distinction between Plonk and R1CS.

The Poseidon hash function, while widely used and arguably efficient in some use cases, exhibits a large number of linear operations. This makes it expensive in terms of plain performance and when considering a Plonk-style arithmetization.

1.1 Our Goals

Our first goal for Poseidon2^\pi is to achieve a simpler and more efficient version of Poseidon^\pi. At the same time, we want to stay close to the original description, which allows us to benefit from years of third-party cryptanalysis applied to Poseidon^\pi. In particular, our modifications allow us to achieve significant performance improvements while keeping the same round numbers, i.e., the same number of nonlinear operations. This is beneficial in concrete use cases in computational integrity. Indeed, the number of constraints does not increase when choosing Poseidon2^\pi instead of Poseidon^\pi, while at the same time the plain performance is better. For example, Merkle trees, a prominent building block in many proof systems, can be computed significantly faster.

The updated Poseidon2^\pi will show similarities to other primitives, for example Neptune. Still, the algorithmic description is much closer to Poseidon^\pi. We chose this approach since Poseidon^\pi is widely used in practice, and reusing components from the original design reduces implementation efforts.

1.2 Our Contributions and Results

Security Issue for Poseidon^\pi. We address a security problem with the original Poseidon^\pi permutation. Indeed, as has been observed in [BBLP22], the first two nonlinear layers can be skipped when mounting an algebraic attack on Poseidon^\pi. This results in equation systems of lower degrees and a more efficient attack. This approach can be mitigated by adding an additional linear layer to the beginning of the permutation. We discuss this issue in Section 7.3.

Poseidon2^\pi. As the main contribution, we consider various optimizations in order to make Poseidon faster and more efficient in recent proof systems. In particular, compared to the original Poseidon^\pi permutation, our modification called Poseidon2^\pi has

1. an additional linear layer at the beginning of the permutation,
2. different linear layer matrices,
3. round constants only applied to the first word in the internal rounds, and
4. the same number of rounds for many instantiations used in practice.

Regarding the last point, we compare the statistical and the algebraic security of Poseidon2^\pi with that of Poseidon^\pi. We also emphasize that our new modified permutation is very similar in nature to the original one, and thus inherits the trust gained from the third-party cryptanalysis of Poseidon. A full specification of the new linear layers and of Poseidon2^\pi is given in Section 5 and Section 6.

Modes of Operation. In many computational integrity proof systems, the construction of Merkle trees is a crucial part. For example, it is used to compute commitments to polynomials or to prove membership. When building a Merkle tree, the next hash is computed using a fixed number of previous (hash) outputs. For this purpose, the sponge function has often been used in the past, albeit with only one permutation call. In this paper, depending on the use case, we suggest to use either the classical sponge hash function or a generic compression function which computes a single new output using an arbitrary number of inputs and only one permutation call. In our practical use case, its main advantage regards the fact that it operates on a smaller size. For example, the inner part (capacity elements) of a sponge is not necessary, and thus the permutation can become smaller, with concrete advantages. We discuss both modes of operation specified for Poseidon2^\pi in Section 3.1.

Performance Comparison. Following the description of our new permutation Poseidon2^\pi, we discuss its performance characteristics in Section 8. We focus on the plain performance and on the number of Plonk constraints, and provide benchmarks from a Rust implementation for various state sizes. We also compare Poseidon2^\pi to the original version and to other similar primitives, and we provide a new Plonkish arithmetization technique which is compatible with both Poseidon^\pi and Poseidon2^\pi.

2. Preliminaries: Modern Arithmetization Techniques

Our focus in this paper is on use cases in the area of computational integrity proof systems. In such a scenario, a prover wants to convince a verifier to have correctly run an arbitrary computation, without making the verifier recompute the result. Many such proof systems exist in practice [37, 13, 26], and they also allow for zero-knowledge versions where the verifier does not learn any private details of the provided proof.

In general, a proof can be split into two steps. First, the computation has to be represented as a number of polynomials, which is usually called arithmetization. Then, a polynomial commitment scheme is used in order to finalize the proof. In this paper, we focus on the arithmetization step, and for this purpose we briefly describe popular techniques. The aim when applying these is to keep the number of constraints as low as possible.

R1CS. A rank-1 constraint satisfaction system (R1CS) consists of n equations in the variables v_0, v_1, \ldots, v_m defined by

where v_i are elements from a finite field \mathbb{F}, v_0 \in \{0, 1\}, and a_i^{(n)}, b_i^{(n)}, c_i^{(n)} are field elements describing the n-th constraint.

Note that these equations are of degree 2 in \{v_i\}_{i=0}^m. They are derived from the statement to prove, which in many cases is a hash function evaluation. Then, minimizing the number of constraints generally leads to more efficient proofs. As an example, using high-degree functions in the hash specification results in a larger number of constraints, which is why many recent arithmetization-oriented designs rely on low-degree components.

Plonk and Variants. The Plonk [GWC19] arithmetization results in a table-like representation for the execution trace. However, the constraints are not restricted to describe entire state transitions, and in general more freedom is offered to the designer. In particular, every constraint is of the form

where a_{L_i}, a_{R_i}, a_{O_i} are witness variables describing two inputs and an output of a gate, and q_{L_i}, q_{R_i}, q_{O_i}, q_{M_i}, q_{C_i} are set such that a specific gate constraint (e.g., an addition or a multiplication) is enforced. Note that this is only a basic description of Plonk, and subsequent variants such as [GW22] make it possible to increase the "width" of the gate (e.g., the number of inputs).

A notable difference in Plonk when compared to R1CS is that linear gates (e.g., additions) also require constraints of their own. Hence, linear operations are not "for free" anymore. This can make expensive linear operations, such as matrix multiplications, not only inefficient in a plain evaluation, but also with regards to the arithmetization.

Plonkish and AIR. Both Plonkish [Zca22] and AIR [BS+19] are more powerful representations compared to R1CS and regular Plonk. Like Plonk, both Plonkish and AIR describe a computation trace as a matrix, but allow high-degree polynomial relations to represent the state transformation.

The set of states is a T \times w matrix, where T is the number of states and w is the width (or the number of registers). Focusing on a hash function evaluation, for example w is set to the state size of the hash primitive and each new state describes the values obtained after applying a round function to the previous state. In contrast to R1CS, the constraint polynomials are not required to be of degree 2, but the efficiency of the arithmetization still depends on the maximum degree d in the constraint polynomials. The prover time is proportional to T \cdot w \cdot d, whereas the proof size is an affine function of the maximal number of variables q in the constraints. Hence, more efficient Plonkish/AIR proofs are delivered by smaller degrees and/or fewer variables in the constraints.

3. Preliminaries: ZK-Friendly Symmetric Primitives

3.1 Modes of Operation

Hash functions are crucial in the context of zero-knowledge protocols. Given a hash function \mathcal{H} : \mathbb{F}_p^{\star} \to \mathbb{F}_p^{\infty} for a prime p \geq 2, it must be computationally hard to find collisions, preimages, and second preimages.

In this paper, we mainly focus on the sponge mode. However, when building a Merkle tree with small fixed-size input lengths, we often only need a single permutation call. In this case, we use a compression function rather than a full hash.

Sponge Hash Functions. A sponge hash function [14, 15] is built using an internal permutation \mathcal{P} over \mathbb{F}_p^t with t = r + c (rate + capacity). As proven in [BDPVA08], the sponge is indifferentiable from a random oracle up to p^{c/2} queries.

Compression Functions. We focus on

This is secure if p^n \geq 2^{2\kappa} and p^{t-n} \geq 2^{\kappa}.

3.2 The Poseidon^\pi Permutation

Let p > 2^{30} and t \geq 2. The permutation \mathcal{P} over \mathbb{F}_p^t is

with R_F = 8 external rounds and R_P internal rounds. The external round applies S-boxes to the entire state; the internal round applies a single S-box to the first element. Both use a t \times t MDS matrix M.

4. Security: Initial and Final Matrix Multiplications

For block ciphers, initial/final affine layers do not affect security. For sponge functions, the situation differs. The first nonlinear layer can be skipped by adjusting IV [BBLP22]. Similarly, omitting the final linear layer removes diffusion. Hence, an SPN for sponge use must start and end with a linear layer. For compression functions, these layers do not decrease security either.

5. More Efficient Linear Layers

We propose new linear layers that maintain the same security level while reducing operations. Goals: (1) minimize constant multiplications for plain performance, and (2) use small matrix entries replaceable by addition chains.

5.1 Matrix for the External Round

For t = 4t', we use

where M_4 is the MDS matrix

needing 8 additions and 4 constant multiplications per 4-element block, totaling 3t Plonk constraints.

5.2 Matrix for the Internal Round

For partial rounds, MDS is not required. We use

with \mu_i \in \mathbb{F}_p \setminus \{0,1\}. This needs 2t-1 additions and t multiplications.

5.3 Preventing Arbitrarily Long Subspace Trails

If the minimal polynomials of M_{\mathcal{I}}, M_{\mathcal{I}}^2, \ldots are irreducible and of maximum degree, no arbitrarily long subspace trail exists [GRS21].

6. Poseidon2^\pi Specification

The permutation \mathcal{P}_2 over \mathbb{F}_p^t is

External rounds use M_{\mathcal{E}}; internal rounds use M_{\mathcal{I}} with a single round constant \hat{c}_0^{(i)}.

Differences from Poseidon^\pi: (1) initial linear layer M_{\mathcal{E}}, (2) two different linear layers for t \geq 4, (3) one round constant per internal round.

Instances (some examples for 2-to-1 compressions):

7. Security Analysis

7.1 Statistical Attacks

Differential Attacks. The branch number of M_{\mathcal{E}} is b = t/4 + 4 \geq 5. Six external rounds suffice for security, as in Poseidon^\pi. Other statistical attacks (linear [Mat93], truncated differential [Knu94], rebound [M+09]) are similarly covered.

7.2 Algebraic Attacks

Interpolation Attack. Maximum degrees and monomial counts match for both schemes.

Grobner Basis Attacks. No significant difference between Poseidon^\pi and Poseidon2^\pi was observed.

7.3 Attack from Bariant et al. [BBLP22]

This attack skips the first round when solving CICO, requiring S(xy) = S(x)S(y) (true for power maps). The initial linear layer in Poseidon2^\pi reduces the advantage to 1 round. Combined with the 12.5% internal round margin, the scheme remains secure.

8. Performance Evaluation

8.1 Theoretical Comparison

For \log_2(p) \approx 64, the number of linear-layer operations is reduced significantly, especially for the external rounds.

8.2 Implementation and Benchmarks

Rust benchmarks on Intel i7-6700K for three primes (BLS12 255-bit, Goldilocks 64-bit, Babybear 31-bit). Performance in \mu s:

Poseidon2^\pi achieves up to 4x speedup for 24-word instances and >2x even for 3-word.

8.3 Efficient Plonkish Version

We show that (t-1) polynomial equations suffice (vs. t in [32, App. E]).

Total: about t \cdot R_F + R_P - t + 1 constraints of degree d.

Acknowledgements. We thank Nicholas Mainardi and the anonymous reviewers for their contributions.

Appendix A. Efficient Circulant MDS Matrices

Circulant matrix–vector products can be computed via FFT in \mathcal{O}(t \log_2(t)) using the isomorphism with \mathbb{F}_p[X]/(X^t - 1).

Appendix B. Efficient Computation of M_{\mathcal{E}}

M_4 \cdot x requires 8 additions and 4 multiplications (by 2 and 4). For state size t, repeat t/4 times plus 2t finalization additions.

Appendix C. Optimized Feistel-ERF Implementation

An accumulator-based approach reduces \text{GMiMC}_{\text{erf}} [AGP+19] per-round operations to a constant, independent of t.

References

• [AAB+20] A. Aly, T. Ashur, E. Ben-Sasson, S. Dhooghe, and A. Szepieniec. "Design of Symmetric-Key Primitives for Advanced Cryptographic Protocols". IACR Trans. Symmetric Cryptol. 2020(3).
• [ABM23] T. Ashur, T. Buschman, and M. Mahzoun. "Algebraic cryptanalysis of POSEIDON". ePrint 2023/537.
• [ACG+19] M. R. Albrecht et al. "Algebraic Cryptanalysis of STARK-Friendly Designs". ASIACRYPT 2019.
• [AD18] T. Ashur and S. Dhooghe. "Marvellous: a STARK-friendly family of cryptographic primitives". ePrint 2018/1098.
• [AGP+19] M. R. Albrecht et al. "Feistel Structures for MPC, and More". ESORICS 2019. [page on this site]
• [AGR+16] M. R. Albrecht et al. "MiMC: Efficient Encryption and Cryptographic Hashing with Minimal Multiplicative Complexity". ASIACRYPT 2016.
• [AKMQ22] J.-P. Aumasson, D. Khovratovich, B. Mennink, and P. Quine. "SAFE (Sponge API for Field Elements)". 2022. [page on this site]
• [ASTW22] M. Ambrona, A. Schmitt, R. R. Toledo, and D. Willems. "New optimization techniques for PlonK's arithmetization". ePrint 2022/462. [page on this site]
• [BBLP22] A. Bariant, C. Bouvier, G. Leurent, and L. Perrin. "Algebraic Attacks Against Some Arithmetization-Oriented Primitives". IACR Trans. Symmetric Cryptol. 2022(3).
• [BBP+22] C. Bouvier et al. "Anemoi Permutations and Jive Compression Mode". ePrint 2022/840. [page on this site]
• [BCD+20] T. Beyne et al. "Out of Oddity – New Cryptanalytic Techniques Against Symmetric Primitives Optimized for Integrity Proof Systems". CRYPTO 2020. [page on this site]
• [BDPVA07] G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche. "Sponge functions". Ecrypt Hash Workshop 2007.
• [BDPVA08] G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche. "On the Indifferentiability of the Sponge Construction". EUROCRYPT 2008.
• [BRS02] J. Black, P. Rogaway, and T. Shrimpton. "Black-Box Analysis of the Block-Cipher-Based Hash-Function Constructions from PGV". CRYPTO 2002.
• [BS+18a] E. Ben-Sasson et al. "Fast Reed-Solomon Interactive Oracle Proofs of Proximity". ICALP 2018.
• [BS+18b] E. Ben-Sasson et al. "Scalable, transparent, and post-quantum secure computational integrity". ePrint 2018/46.
• [BS+19] E. Ben-Sasson et al. "Scalable Zero Knowledge with No Trusted Setup". CRYPTO 2019.
• [BS90] E. Biham and A. Shamir. "Differential Cryptanalysis of DES-like Cryptosystems". CRYPTO 1990.
• [Dam89] I. Damgard. "A Design Principle for Hash Functions". CRYPTO 1989.
• [DK10] O. Dunkelman and N. Keller. "The effects of the omission of last round's MixColumns on AES". Inf. Process. Lett. 2010.
• [DL18] S. Duval and G. Leurent. "MDS Matrices with Lightweight Circuits". IACR Trans. Symmetric Cryptol. 2018(2).
• [DR01] J. Daemen and V. Rijmen. "The Wide Trail Design Strategy". IMA 2001.
• [F+93] J.-C. Faugere et al. "Efficient Computation of Zero-Dimensional Grobner Bases by Change of Ordering". J. Symb. Comput. 1993.
• [G+23] L. Grassi et al. "Monolith: Circuit-Friendly Hash Functions with New Nonlinear Layers". ePrint 2023/1025.
• [GHR+23] L. Grassi et al. "Horst Meets Fluid-SPN: Griffin for Zero-Knowledge Applications". CRYPTO 2023. [page on this site]
• [GKL+22] L. Grassi et al. "Reinforced Concrete: A Fast Hash Function for Verifiable Computation". CCS 2022. [page on this site]
• [GKR+19] L. Grassi, D. Khovratovich, A. Roy, C. Rechberger, and M. Schofnegger. "Poseidon: A New Hash Function for Zero-Knowledge Proof Systems". ePrint 2019/458. [page on this site]
• [GKR+21] L. Grassi, D. Khovratovich, C. Rechberger, A. Roy, and M. Schofnegger. "Poseidon: A New Hash Function for Zero-Knowledge Proof Systems". USENIX Security 2021. [page on this site]
• [GKRS22] L. Grassi, D. Khovratovich, S. Ronjom, and M. Schofnegger. "The Legendre Symbol and the Modulo-2 Operator in Symmetric Schemes". IACR Trans. Symmetric Cryptol. 2022(1).
• [GLR+20] L. Grassi et al. "On a Generalization of Substitution-Permutation Networks: The HADES Design Strategy". EUROCRYPT 2020. [page on this site]
• [GOPS22] L. Grassi, S. Onofri, M. Pedicini, and L. Sozzi. "Invertible Quadratic Non-Linear Layers for MPC-/FHE-/ZK-Friendly Schemes". IACR Trans. Symmetric Cryptol. 2022(3).
• [Gro16] J. Groth. "On the Size of Pairing-Based Non-interactive Arguments". EUROCRYPT 2016.
• [GRR16] L. Grassi, C. Rechberger, and S. Ronjom. "Subspace Trail Cryptanalysis and its Applications to AES". IACR Trans. Symmetric Cryptol. 2016(2).
• [GRS21] L. Grassi, C. Rechberger, and M. Schofnegger. "Proving Resistance Against Infinitely Long Subspace Trails". IACR Trans. Symmetric Cryptol. 2021(2).
• [GW22] A. Gabizon and Z. J. Williamson. "Turbo-PLONK". 2022.
• [GWC19] A. Gabizon, Z. J. Williamson, and O. Ciobotaru. "PLONK". ePrint 2019/953. [page on this site]
• [HL22] Horizen Labs. "ginger-lib". 2022.
• [IAIK21] IAIK. "Hash functions for Zero-Knowledge applications Zoo". Graz University of Technology, 2021.
• [JK97] T. Jakobsen and L. R. Knudsen. "The Interpolation Attack on Block Ciphers". FSE 1997.
• [K+16] S. Kolbl et al. "Haraka v2". IACR Trans. Symmetric Cryptol. 2016(2).
• [Knu94] L. R. Knudsen. "Truncated and Higher Order Differentials". FSE 1994.
• [KR21] N. Keller and A. Rosemarin. "Mind the Middle Layer: The HADES Design Strategy Revisited". EUROCRYPT 2021. [page on this site]
• [LAAZ11] G. Leander et al. "A Cryptanalysis of PRINTcipher: The Invariant Subspace Attack". CRYPTO 2011.
• [LMR15] G. Leander, B. Minaud, and S. Ronjom. "A Generic Approach to Invariant Subspace Attacks". EUROCRYPT 2015.
• [M+09] F. Mendel et al. "The Rebound Attack: Cryptanalysis of Reduced Whirlpool and Grostl". FSE 2009.
• [Mat93] M. Matsui. "Linear Cryptanalysis Method for DES Cipher". EUROCRYPT 1993.
• [Mer89] R. C. Merkle. "A Certified Digital Signature". CRYPTO 1989.
• [PGV93] B. Preneel, R. Govaerts, and J. Vandewalle. "Hash Functions Based on Block Ciphers". CRYPTO 1993.
• [Pol22] Polygon. "Introducing Plonky2". 2022.
• [RPO22] T. Ashur et al. "Rescue-Prime Optimized". ePrint 2022/1577. [page on this site]
• [RZ23] RISC Zero. "RISC Zero: General-Purpose Verifiable Computing". 2023.
• [S+23] A. Szepieniec et al. "The Tip5 Hash Function for Recursive STARKs". ePrint 2023/107. [page on this site]
• [SK96] B. Schneier and J. Kelsey. "Unbalanced Feistel Networks and Block Cipher Design". FSE 1996.
• [SS21] J. F. Sauer and A. Szepieniec. "SoK: Grobner Basis Algorithms for Arithmetization Oriented Ciphers". ePrint 2021/870.
• [Sze21] A. Szepieniec. "On the Use of the Legendre Symbol in Symmetric Cipher Design". ePrint 2021/984.
• [Zca22] Zcash. "halo2". 2022.