Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

Gotta Hash 'Em All! Speeding Up Hash Functions for Zero-Knowledge Proof Applications

T0 review · 4 major / 4 minor · reviewed 2026-08-09 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Latency-optimized FPGA designs make zero-knowledge-friendly hashing 10-23x faster than CPU implementations.

desk verdict HashEmAll is a credible FPGA engineering effort with first hardware implementations of three ZK-friendly hashes, but the headline speedups rest on an under-specified, likely single-threaded CPU baseline and ideal zero-I/O pipeline assumptions. read the letter →

arxiv 2501.18780 v2 pith:XQX7SRHS submitted 2025-01-30 cs.CR cs.AR

Nojan Sheybani , Tengkai Gong , Anees Ahmed , Nges Brian Njungle , Michel Kinsy , Farinaz Koushanfar This is my paper · ORCID
classification cs.CRcs.AR
keywords zero-knowledgeproofsZK-friendlyhashfunctionsFPGAaccelerationGriffinRescue-PrimeReinforcedConcreteBN254fieldmodulararithmetichardware
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Zero-knowledge-friendly hash functions such as Griffin, Rescue-Prime, and Reinforced Concrete are cheap inside arithmetic circuits but slow on ordinary CPUs because they rely on wide finite-field arithmetic. The paper argues that FPGAs can close this gap: it introduces HashEmAll, a modular library of pipelined arithmetic blocks over the BN254 prime field that implements all three hashes in both area-optimized and latency-optimized variants. The latency-optimized designs are reported to achieve at least 10x higher throughput than a Rust CPU implementation, with the Reinforced Concrete design reaching 23x and latency comparable to SHA-3. If these numbers hold, hardware hashing becomes practical for ZKP workloads such as Merkle tree commitments and recursive proofs, and the same modules could be reused for other hashes and field sizes.

What carries the argument

The mechanism is a set of modular arithmetic units for the BN254 prime field. The reconfigurable modular multiplier has three modes: MULT for quadratic function evaluation, DECOMPOSE for the Bars decomposition of Reinforced Concrete, and COMPOSE for recomposing field elements. Division inside DECOMPOSE is replaced by a lookup-table scaled reciprocal and a bit shift, avoiding expensive division hardware. Power maps x^d and $x^{{1/d}}$ for Rescue-Prime and Griffin are computed with square-and-multiply, using two parallel multipliers for the latency variant. These blocks are pipelined and arranged in a sponge construction; area-optimized designs use one pipeline for a batch of 13 inputs, while latency-optimized designs replicate pipelines (Griffin with batch 39, Reinforced Concrete with batch 26) to raise throughput.

What would settle it

Run the same three hashes on the same FPGA and CPU in an end-to-end Merkle tree construction, streaming real data blocks on and off the board, and compare total time per tree; if the aggregate speedup falls below one order of magnitude, the fully saturated-pipeline assumption does not hold for practical workloads.

Watch

Extended reading notes

Core claim

The central claim is that the expensive finite-field operations that make ZK-friendly hashes slow in plaintext can be offloaded to reconfigurable hardware with a small set of reusable building blocks: a reconfigurable modular multiplier, lookup-table-based fast division, and square-and-multiply power mapping. Pipelining these blocks inside a sponge framework yields permutation implementations whose amortized throughput on a Virtex UltraScale+ exceeds the CPU baseline by 3.31x to 23.44x across the three hashes, with every latency-optimized variant above one order of magnitude. The paper further claims this is the first FPGA realization of these three hashes, that the best design (Reinforced Concrete) reaches SHA-3-class latency, and that the modular design extends to other ZK-friendly hashes and field sizes with minimal overhead.

Load-bearing premise

The reported speedups rest on the assumption that the FPGA pipeline is always fully saturated with a ready batch of requests and that board I/O traffic is free; real workloads with small or irregular input batches will see smaller gains.

Editorial extensions

If this is right

  • With latency-optimized HashEmAll, a single FPGA can hash ZK-friendly functions at least an order of magnitude faster than the CPU baseline, which removes the hashing bottleneck in Merkle-tree and recursive-proof pipelines.
  • The best design, Reinforced Concrete, reaches a per-hash latency comparable to SHA-3, so ZK-friendly hashing no longer carries a plaintext penalty for proof systems that support lookups.
  • Because the area-optimized variants use far fewer DSPs and LUTs, the designs can be deployed on smaller, lower-cost FPGAs rather than high-end boards.
  • The modular arithmetic blocks are field-parameterizable, so the same library can be extended to other ZK-friendly hashes and other prime fields, such as a 64-bit Goldilocks field, with minimal changes.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • An end-to-end benchmark that includes FPGA board I/O and non-saturated batch arrival would likely lower the reported 10-23x speedups, so the headline claim should be validated under realistic streaming workloads.
  • Because the paper measures the permutation rather than the full sponge hash, the speedup for hashing short messages may be smaller; a testable extension is to measure full absorption/squeezing of multi-block messages.
  • The same modular arithmetic approach could target 64-bit Goldilocks fields, where CPU native arithmetic is fast; whether the FPGA advantage persists on such fields is an open question that the paper's methodology could answer.
  • If the HashEmAll modules are integrated with proof-generation accelerators that handle NTT and MSM, the next bottleneck in ZKP proving could be addressed on a single FPGA rather than in separate systems.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper presents HashEmAll, a collection of FPGA implementations of three ZK-friendly hash functions (Rescue-Prime, Griffin, and Reinforced Concrete) over the BN254 prime field. For each hash, the authors provide an area-optimized and a latency-optimized variant, built from reusable modules for modular multiplication, power mapping, and fast division. The implementations are synthesized on a Virtex UltraScale+ device and evaluated for resource utilization, frequency, latency, throughput, and power. The central claim is that the latency-optimized designs outperform CPU implementations from the ZKFriendlyHashZoo by at least 10x, with Reinforced Concrete achieving 23.44x, and that the Reinforced Concrete design reaches latencies comparable to SHA-3.

Significance. If the performance claims hold, this is an useful step toward practical hardware acceleration of ZK-friendly hashing: it is, to the authors' knowledge, the first FPGA realization of Griffin, Rescue-Prime, and Reinforced Concrete, and it provides an open-source, modular library that can be reused for other hashes and field sizes. The modular design, explicit area-versus-latency trade-offs, and public repository are strengths, as is the reporting of synthesis results, resource usage, and power. The main significance issue is that the headline speedups depend on comparison choices that are not fully disclosed or are internally inconsistent; the underlying FPGA arithmetic is not the main risk, but the empirical comparison protocol must be sharpened before the 'at least 10x' and 'practical' claims can be accepted as stated.

major comments (4)
  1. [Abstract and Section VII] The abstract states that latency-optimized HashEmAll designs 'outperform CPU implementations by at least 10x' and Section VII repeats 'speedup of at least an order of magnitude.' This is directly contradicted by Table II, which reports Griffin_L at 9.94x, and by Section VI.B, which says the smallest speedup is Griffin_L. The headline should be corrected to an accurate range, such as 'from 9.9x to 23.4x' or 'up to 23x,' unless the CPU baseline is changed so that all designs cross the 10x threshold.
  2. [Section VI.A and Table II] The CPU baseline is under-specified. The paper says the CPU numbers are replicated on an AMD Ryzen 3990X using the ZKFriendlyHashZoo repository [39], but it does not state whether the measurements are single-threaded or multi-threaded, which compiler and optimization flags were used, or whether CPU throughput/latency includes input/output overhead. Since Section II.C motivates Merkle-tree hashing as an embarrassingly parallel workload, a single-threaded CPU baseline is not the natural comparison for that use case, and a 64-thread baseline would materially reduce the reported speedups. The authors should disclose the threading model and, if single-threaded, either add a multi-threaded comparison or explicitly scope all speedup claims to single-threaded CPU implementations.
  3. [Section VI.B] The evaluation explicitly assumes a fully saturated pipeline and ignores I/O traffic in and out of the FPGA board. This is a reasonable ideal-throughput metric, but it is not sufficient to support the abstract's broader 'practical' and 'real-world' claims, since real systems must transfer hash inputs and outputs over PCIe or another interface. Please quantify the I/O impact at representative transfer sizes, or restate the headline claims as on-FPGA saturated-pipeline throughput rather than end-to-end system performance.
  4. [Section VI.B] The SHA-3 comparison is not apples-to-apples and should be removed or reframed. The paper says RC_L 'has a comparable run time with SHA-3,' citing a reported SHA-3 latency of 419.2 ns from [16], but that is a CPU latency, while RC_L's 0.145 us amortized latency is an FPGA permutation latency computed with zero I/O overhead and fully saturated pipelines. The input widths and computation environments also differ. The related introductory claim that HashEmAll achieves runtime 'in the same order of magnitude' as SHA-3 is consequently unsupported by the data presented.
minor comments (4)
  1. [Table I] The RCL row has formatting errors: the LUT utilization entry is missing a closing parenthesis and the FF entry is missing a percent sign; these should be corrected as '316,049 (18.28%)' and '169,043 (4.89%)'.
  2. [Section VI.B] The sentence 'This results also out This' is incomplete and should be rewritten; it appears to be a leftover fragment from an earlier draft.
  3. [Section III.C] In the definition of Griffin's permutation, the input is written as x = (x0, ..., xm), which suggests m+1 elements, but the text says the state size is m. The notation should be x = (x0, ..., x_{m-1}) for clarity.
  4. [Section V.A] The notation 'Result = (x x D/s_i) >> 508' is missing the multiplication symbol; it should read 'Result = (x * (D/s_i)) >> 508' to avoid confusion with the modular multiplication operator.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the reported speedups are direct measured/synthesized ratios against external CPU benchmarks, not derivations from fitted inputs.

full rationale

The paper's central claim (10-23x speedup) is an evaluation result, not a derivation. Table II's speedup column is the ratio of HashEmAll's amortized throughput (from Vivado synthesis, Table I) to CPU throughput taken from [16] and replicated with the ZKFriendlyHashZoo repository; no parameter is fitted to the claimed outcome and no equation is defined in terms of the result. The one self-citation, [30] (AMAZE, same author group), is used as the source of reusable modular-arithmetic modules and as a reference for optimized multiplication; the claimed speedups do not follow from [30] by construction, and the paper's own synthesis and benchmark table independently support the numbers. Section VI.B's statement that I/O is ignored and the pipeline is assumed saturated is a benchmark idealization, not a circular reduction; it is a limitation that a user could test separately. The internal inconsistency that Griffin_L shows 9.94x despite the abstract claiming 'at least 10x' is a correctness/consistency issue, not circularity.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The central claim depends on the correctness of reused arithmetic modules, the hash specifications, external CPU benchmarks, and synthesis-based performance estimates. There are no fitted free parameters in a scientific sense, but the design choices of batch size, multiplier count, and division scaling factor are hand-selected and affect the reported speedups. No new physical or mathematical entities are introduced.

free parameters (4)
  • Batch size for area-optimized designs = 13
    Area-optimized designs process a batch of 13 inputs per pipeline; this is a designer-chosen constant that affects throughput and resource usage.
  • Batch size for latency-optimized designs = 13 (Rescue-Prime), 39 (Griffin), 26 (RC)
    Latency-optimized designs use multiples of 13; the specific multipliers chosen by the authors affect the reported throughput.
  • Division scaling factor D = 508 bits
    In Section V.A, D is a power of two selected to make division by subfield sizes compatible with bit shifts; it is a hand-picked design constant.
  • Number of modular multiplier units = 3 or 6
    Area-optimized designs use 3 multipliers; latency-optimized use 6 (or 2 parallel modules for RC). This is a design choice, not derived.
assumptions (4)
  • domain assumption The BN254 modular arithmetic modules from AMAZE [30] are correct and secure.
    The paper builds all hashes on these modules and cites [30] rather than re-verifying them (Section V).
  • domain assumption The specifications of Rescue-Prime, Griffin, and Reinforced Concrete are correct as given in [14], [15], [16].
    The hardware implementations follow the published permutations without independent cryptanalysis.
  • domain assumption The CPU baseline throughputs from [16] and the ZKFriendlyHashZoo [39] are representative of a fair comparison.
    The speedup claims rest on these external benchmarks; the paper does not fully document how they were obtained (Section VI.B).
  • domain assumption Vivado synthesis results accurately predict on-board timing and power.
    Frequency, power, and resource numbers are from synthesis, not from measurements on the FPGA board (Table I).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Gotta Hash 'Em All! Speeding Up Hash Functions for Zero-Knowledge Proof Applications." pith.science (2026). https://pith.science/paper/XQX7SRHS

@misc{pith2026250118780,
  author       = {Pith},
  title        = {Pith review of: Gotta Hash 'Em All! Speeding Up Hash Functions for Zero-Knowledge Proof Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XQX7SRHS}},
  note         = {Machine review of arXiv:2501.18780}
}
abstract

Collision-resistant cryptographic hash functions (CRHs) are crucial for security, particularly for message authentication in Zero-knowledge Proof (ZKP) applications. However, traditional CRHs like SHA-2 or SHA-3, while optimized for CPUs, generate large circuits, rendering them inefficient in the ZK domain. Conversely, ZK-friendly hashes are designed for circuit efficiency but struggle on conventional hardware, often orders of magnitude slower than standard hashes due to their reliance on expensive finite field arithmetic. To bridge this performance gap, we present HashEmAll, a novel collection of FPGA-based realizations for three prominent ZK-friendly hashes: Griffin, Rescue-Prime, and Reinforced Concrete. Each offers distinct optimization profiles, with both area-optimized and latency-optimized variants available, allowing users to tailor hardware selection to specific application constraints regarding resource utilization and performance. Our extensive evaluation shows that latency-optimized HashEmAll designs outperform CPU implementations by at least $10 \times$, with the leading design achieving a $23 \times$ speedup. These gains are coupled with lower power consumption and compatibility with accessible FPGAs. Importantly, the highly parallel and pipelined architecture of HashEmAll enables significantly better practical scaling than CPU-based approaches towards building real-world ZKP applications, such as data commitments with Merkle Trees, by mitigating the hashing bottleneck for large trees. This highlights the suitability of HashEmAll for real-world ZKP applications involving large-scale data authentication. We also highlight the ability to translate the HashEmAll methodology to various ZK-friendly hash functions and different field sizes.

Figures

Figures reproduced from arXiv: 2501.18780 by the authors.

Figure 1
Figure 1. Example of a Merkle Tree constructed from a dataset [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. One round of the RescuePrimeπ permutation ZK domain. Rescue-Prime utilizes a combination of power maps x d and x 1/d as its round functions, where d is chosen based on the specific field. The permutation RescuePrimeπ, is repeated for r rounds, each of which consists of the following operations for an input of state size m: 1) S-box: Apply power map x 7→ x d to all elements in state. 2) MDS & Constants: Multiply stat… view at source ↗
Figure 3
Figure 3. One round of the Griffinπ permutation, where ⊞ denotes element-wise addition 2) Griffin: Griffin [15] is a family of hash functions that is based on the Rescue-Prime hash function to achieve better plaintext performance while maintaining comparable ZK per￾formance. Griffin uses a combination of power maps x d and x 1/d, along with a Horst-inspired construction in its round functions, where d is chosen based on the s… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: RCπ permutation 3) Reinforced Concrete: Reinforced Concrete [16] (RC) is a lookup-based hash function that is optimized to achieve high performance when operating over large finite fields. One of the limitations of RC is that it can only achieve peak performance when o…
Figure 5
Figure 5. Figure 5: Sponge framework for permutation fπ. This framework absorbs the message m and outputs the hash h. two designs: HA, a design that aims to minimize area and resource utilization and HL, a design that aims to maximize amortized latency and throughput. All of the permutati…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Zero-Knowledge Proof Frameworks: A Systematic Survey

    cs.CR 2025-02 conditional novelty 5.0 of 10

    A systematic survey and reproducible benchmark of 25 open-source zero-knowledge proof frameworks, with Docker environments and performance comparisons on SHA-256 and matrix multiplication.

Reference graph

Works this paper leans on

39 extracted references · 33 canonical work pages · cited by 1 Pith paper

  1. [39]

    Hash functions for zero-knowledge applications zoo,

    “Hash functions for zero-knowledge applications zoo,” https://extgit.iai k.tugraz.at/krypto/zkfriendlyhashzoo, Aug. 2021, IAIK, Graz University of Technology

    work page 2021

  2. [16]

    Reinforced concrete: a fast hash function for verifiable computation,

    L. Grassi, D. Khovratovich, R. L ¨uftenegger, C. Rechberger, M. Schofnegger, and R. Walch, “Reinforced concrete: a fast hash function for verifiable computation,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 1323–1335

    work page 2022

  3. [1]

    Pseudo trust: Zero-knowledge authentication in anonymous p2ps,

    L. Lu, J. Han, Y . Liu, L. Hu, J.-P. Huai, L. Ni, and J. Ma, “Pseudo trust: Zero-knowledge authentication in anonymous p2ps,”IEEE Transactions on Parallel and Distributed Systems, vol. 19, no. 10, pp. 1325–1337, 2008

    work page 2008

  4. [2]

    Zero-knowledge authentication protocol based on alternative mode in rfid systems,

    H. Liu and H. Ning, “Zero-knowledge authentication protocol based on alternative mode in rfid systems,”IEEE Sensors Journal, vol. 11, no. 12, pp. 3235–3245, 2011

    work page 2011

  5. [3]

    Zkrownn: Zero knowledge right of ownership for neural networks,

    N. Sheybani, Z. Ghodsi, R. Kapila, and F. Koushanfar, “Zkrownn: Zero knowledge right of ownership for neural networks,” in2023 60th ACM/IEEE Design Automation Conference (DAC). IEEE, 2023, pp. 1–6

    work page 2023

  6. [4]

    zprobe: Zero peek robustness checks for federated learning,

    Z. Ghodsi, M. Javaheripi, N. Sheybani, X. Zhang, K. Huang, and F. Koushanfar, “zprobe: Zero peek robustness checks for federated learning,” inProceedings of the IEEE/CVF International Conference on Computer Vision, 2023, pp. 4860–4870

    work page 2023

  7. [5]

    Zkcnn: Zero knowledge proofs for con- volutional neural network predictions and accuracy,

    T. Liu, X. Xie, and Y . Zhang, “Zkcnn: Zero knowledge proofs for con- volutional neural network predictions and accuracy,” inProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021, pp. 2968–2985

    2021

  8. [6]

    Mystique: Efficient conversions for zero-knowledge proofs with applications to machine learning,

    C. Weng, K. Yang, X. Xie, J. Katz, and X. Wang, “Mystique: Efficient conversions for zero-knowledge proofs with applications to machine learning,” in30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 501–518

    2021

Show all 39 references
  1. [7]

    Gzkp: A gpu accelerated zero-knowledge proof system,

    W. Ma, Q. Xiong, X. Shi, X. Ma, H. Jin, H. Kuang, M. Gao, Y . Zhang, H. Shen, and W. Hu, “Gzkp: A gpu accelerated zero-knowledge proof system,” inProceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volu...

    2023

  2. [8]

    Pipezk: Accelerating zero-knowledge proof with a pipelined architecture,

    Y . Zhang, S. Wang, X. Zhang, J. Dong, X. Mao, F. Long, C. Wang, D. Zhou, M. Gao, and G. Sun, “Pipezk: Accelerating zero-knowledge proof with a pipelined architecture,” in2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2021, pp. 416–428

    2021

  3. [9]

    Scalable, trans- parent, and post-quantum secure computational integrity,

    E. Ben-Sasson, I. Bentov, Y . Horesh, and M. Riabzev, “Scalable, trans- parent, and post-quantum secure computational integrity,”Cryptology ePrint Archive, 2018

    2018

  4. [10]

    Efficient (non-) membership tree from multicollision- resistance with applications to zero-knowledge proofs,

    M. Petkus, “Efficient (non-) membership tree from multicollision- resistance with applications to zero-knowledge proofs,”Cryptology ePrint Archive, 2024

    2024

  5. [11]

    Nova: Recursive zero-knowledge arguments from folding schemes,

    A. Kothapalli, S. Setty, and I. Tzialla, “Nova: Recursive zero-knowledge arguments from folding schemes,” inAnnual International Cryptology Conference. Springer, 2022, pp. 359–388

    2022

  6. [12]

    On the hardware implementations of the sha-2 (256, 384, 512) hash functions,

    N. Sklavos and O. Koufopavlou, “On the hardware implementations of the sha-2 (256, 384, 512) hash functions,” inProceedings of the 2003 International Symposium on Circuits and Systems, 2003. ISCAS’03., vol. 5. IEEE, 2003, pp. V–V

    2003

  7. [13]

    Systemization of knowledge: Zk-friendly hash functions,

    Ingonyama, “Systemization of knowledge: Zk-friendly hash functions,” Nov 2022. [Online]. Available: https://medium.com/@ingonyama/syst em-of-knowledge-zk-friendly-hash-functions-ab825616c9f1

    2022

  8. [14]

    Rescue-prime: a standard specification (sok),

    A. Szepieniec, T. Ashur, and S. Dhooghe, “Rescue-prime: a standard specification (sok),”Cryptology ePrint Archive, 2020

    2020

  9. [15]

    Horst meets fluid-spn: Griffin for zero-knowledge applica- tions,

    L. Grassi, Y . Hao, C. Rechberger, M. Schofnegger, R. Walch, and Q. Wang, “Horst meets fluid-spn: Griffin for zero-knowledge applica- tions,” inAnnual International Cryptology Conference. Springer, 2023, pp. 573–606

    2023

  10. [17]

    zk-snarks: a gentle introduction,

    A. Nitulescu, “zk-snarks: a gentle introduction,”Ecole Normale Su- perieure, 2020

    2020

  11. [18]

    Limbo: efficient zero-knowledge mpcith-based arguments,

    C. Delpech de Saint Guilhem, E. Orsini, and T. Tanguy, “Limbo: efficient zero-knowledge mpcith-based arguments,” inProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021, pp. 3022–3036

    2021

  12. [19]

    Brakedown: Linear-time and post-quantum snarks for r1cs

    A. Golovnev, J. Lee, S. T. Setty, J. Thaler, and R. S. Wahby, “Brakedown: Linear-time and post-quantum snarks for r1cs.”IACR Cryptol. ePrint Arch., vol. 2021, p. 1043, 2021

    2021

  13. [20]

    zktree: A zero-knowledge recursion tree with zkp membership proofs,

    S. Deng and B. Du, “zktree: A zero-knowledge recursion tree with zkp membership proofs,”Cryptology ePrint Archive, 2023

    2023

  14. [21]

    Review and investigation of merkle tree’s technical principles and related application fields,

    S. Jing, X. Zheng, and Z. Chen, “Review and investigation of merkle tree’s technical principles and related application fields,” in2021 Inter- national Conference on Artificial Intelligence, Big Data and Algorithms (CAIBDA). IEEE, 2021, pp. 86–90

    2021

  15. [22]

    Hash functions monolith for zk applications: May the speed of sha-3 be with you

    L. Grassi, D. Khovratovich, R. L ¨uftenegger, C. Rechberger, M. Schofnegger, and R. Walch, “Hash functions monolith for zk applications: May the speed of sha-3 be with you.”IACR Cryptol. ePrint Arch., vol. 2023, p. 1025, 2023

    2023

  16. [23]

    Poseidon: A new hash function for{Zero-Knowledge}proof systems,

    L. Grassi, D. Khovratovich, C. Rechberger, A. Roy, and M. Schofnegger, “Poseidon: A new hash function for{Zero-Knowledge}proof systems,” in30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 519–535

    2021

  17. [24]

    What’s the deal with hash functions in zero knowledge?

    TACEO, “What’s the deal with hash functions in zero knowledge?” ht tps://blog.taceo.io/whats-the-deal-with-hashes-in-zk/, 2023, accessed: November 18, 2024

    2023

  18. [25]

    Mimc: Efficient encryption and cryptographic hashing with minimal multi- plicative complexity,

    M. Albrecht, L. Grassi, C. Rechberger, A. Roy, and T. Tiessen, “Mimc: Efficient encryption and cryptographic hashing with minimal multi- plicative complexity,” inInternational Conference on the Theory and Application of Cryptology and Information Security. Springer, 2016, pp. 191–219

    2016

  19. [26]

    plookup: A simplified polynomial protocol for lookup tables,

    A. Gabizon and Z. J. Williamson, “plookup: A simplified polynomial protocol for lookup tables,”Cryptology ePrint Archive, 2020

    2020

  20. [27]

    Arya: Nearly linear-time zero-knowledge proofs for correct program execution,

    J. Bootle, A. Cerulli, J. Groth, S. Jakobsen, and M. Maller, “Arya: Nearly linear-time zero-knowledge proofs for correct program execution,” in International Conference on the Theory and Application of Cryptology and Information Security. Springer, 2018, pp. 595–626

    2018

  21. [28]

    A review of zk-snarks,

    T. Chen, H. Lu, T. Kunpittaya, and A. Luo, “A review of zk-snarks,” arXiv preprint arXiv:2202.06877, 2022

    2022 arXiv

  22. [29]

    GitHub - datenlord/TRIDENT: A Hardware Implemented Poseidon Hasher — github.com,

    “GitHub - datenlord/TRIDENT: A Hardware Implemented Poseidon Hasher — github.com,” https://github.com/datenlord/TRIDENT.git, [Accessed 03-05-2024]

    2024

  23. [30]

    Amaze: Accelerated mimc hardware architecture for zero-knowledge applications on the edge,

    A. Ahmed, N. Sheybani, D. Moreno, N. B. Njungle, T. Gong, M. Kinsy, and F. Koushanfar, “Amaze: Accelerated mimc hardware architecture for zero-knowledge applications on the edge,”2024 ACM/IEEE Inter- national Conference on Computer-Aided Design (ICCAD), 2024

    2024

  24. [31]

    Zk hash bounties,

    ZK Hash Bounties, “Zk hash bounties,” https://www.zkhashbounties.inf o/, 2024, accessed: November 18, 2024

    2024

  25. [32]

    Pairing-friendly elliptic curves of prime order,

    P. S. Barreto and M. Naehrig, “Pairing-friendly elliptic curves of prime order,” inInternational workshop on selected areas in cryptography. Springer, 2005, pp. 319–331

    2005

  26. [33]

    Lightweight mds involution matrices,

    S. M. Sim, K. Khoo, F. Oggier, and T. Peyrin, “Lightweight mds involution matrices,” inFast Software Encryption: 22nd International Workshop, FSE 2015, Istanbul, Turkey, March 8-11, 2015, Revised Selected Papers 22. Springer, 2015, pp. 471–493

    2015

  27. [34]

    Cuzk: Accelerating zero-knowledge proof with a faster par- allel multi-scalar multiplication algorithm on gpus,

    T. Lu, C. Wei, R. Yu, C. Chen, W. Fang, L. Wang, Z. Wang, and W. Chen, “Cuzk: Accelerating zero-knowledge proof with a faster par- allel multi-scalar multiplication algorithm on gpus,”IACR Transactions on Cryptographic Hardware and Embedded Systems, vol. 2023, no. 3, pp. 194–220, 2023

    2023

  28. [35]

    Accelerating zero-knowledge proofs through hardware-algorithm co-design

    N. Samardzic, S. Langowski, S. Devadas, and D. Sanchez, “Accelerating zero-knowledge proofs through hardware-algorithm co-design.”

  29. [36]

    Fast square-and-multiply exponentiation for rsa,

    L. C. K. Hui and K.-Y . Lam, “Fast square-and-multiply exponentiation for rsa,”Electronics Letters, 1994

    1994

  30. [37]

    Sponge functions,

    G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche, “Sponge functions,” inECRYPT hash workshop, vol. 2007, no. 9, 2007

    2007

  31. [38]

    zk-bench: A toolset for com- parative evaluation and performance benchmarking of snarks,

    J. Ernstberger, S. Chaliasos, G. Kadianakis, S. Steinhorst, P. Jovanovic, A. Gervais, B. Livshits, and M. Orr `u, “zk-bench: A toolset for com- parative evaluation and performance benchmarking of snarks,” inIn- ternational Conference on Security and Cryptography for Networks. ...

    2024

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.