Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

gECC: A GPU-based high-throughput framework for Elliptic Curve Cryptography

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

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

Pith's one-line read A GPU framework that batches elliptic-curve operations and trims integer multiply-add instructions claims 5.56x ECDSA and 4.94x ECDH speedups over the leading GPU library.

desk verdict Real GPU-ECC engineering with a genuinely useful SASS-level analysis, but the headline speedups as printed do not match the paper's own tables, and the claimed ECDH result is not actually benchmarked. read the letter →

arxiv 2501.03245 v1 pith:HPWZCHYD submitted 2024-12-22 cs.CR cs.ARcs.DC

Qian Xiong , Weiliang Ma , Xuanhua Shi , Yongluan Zhou , Hai Jin , Kaiyi Huang , Haozhou Wang , Zhengru Wang This is my paper · ORCID
classification cs.CRcs.ARcs.DC
keywords ellipticcurvecryptographyGPUaccelerationmodularmultiplicationMontgomery'strickbatchinversionSM2IMADinstructionsECDSA
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

The paper sets out to show that the throughput bottleneck of elliptic-curve cryptography on GPUs is not hardware but design: existing GPU libraries optimize single EC operations, while gECC batches thousands of operations and reworks the underlying modular arithmetic. Its core proposal is to use affine coordinates instead of Jacobian coordinates, paying for the extra modular inversions with Montgomery's trick so $N$ inversions collapse into one, and to schedule that inversion with a gather-apply-scatter pattern that avoids warp divergence. On the arithmetic side, the paper identifies the count of Integer Multiply-Add (IMAD) instructions, not raw instruction count, as the true bottleneck in 256-bit modular multiplication, and reduces it with predicate-register carry propagation and, for the SM2 curve's special prime, IADD3 additions in place of IMAD. If the claims hold, GPU systems could sign and verify ECDSA 4.18x and 5.56x faster than the state-of-the-art GPU library and raise a real permissioned blockchain's transaction throughput by 1.56x. This matters because ECC underpins TLS, verifiable databases, private set intersection, and blockchain.

What carries the argument

The load-bearing machinery is a stack of three moving parts. Montgomery's trick ([1]) compresses $N$ modular inversions into one inversion plus $3N$ multiplications, making affine-coordinate formulas competitive; a gather-apply-scatter (GAS) scheduling pattern ([34]) runs the compress/inverse/decompress steps across warps so that only one inversion per streaming processor is needed, avoiding divergence. The third part is the SASS-level instruction analysis: the paper measures issue rates of DFMA, DADD, IMAD, and IADD3 on Ampere GPUs, finds IMAD the bottleneck at roughly 136 instructions per 256-bit Montgomery multiplication, and cuts it by carrying the high-word carry through predicate registers, reordering IMADs to avoid register moves, and using the SM2 prime $q = 2^{256} - 2^{224} - 2^{96} + 2^{64} - 1$ to replace IMAD with IADD3 in the reduction phase. The L2 persistent cache and column-major data layout handle the large intermediate arrays.

What would settle it

Benchmark on an A100 the latency of a single 256-bit modular inversion versus a 256-bit modular multiplication, both using the SM2 prime; if the inversion-to-multiplication ratio is below about 20, the $N > 20$ crossover derived in Section 3.1 no longer holds and the reported batch-based speedups would not reproduce.

Watch

Extended reading notes

Core claim

The central discovery is that two seemingly unrelated bottlenecks dominate ECC throughput on GPUs and can be attacked together. First, batching: replacing point-by-point Jacobian computation with affine-coordinate formulas batched by Montgomery's trick converts $N$ modular inversions into one inversion plus $3N$ multiplications, and the paper derives that affine batching wins over Jacobian once the batch size $N$ exceeds 20. Second, microarchitecture: by disassembling SASS instructions and measuring issue rates, the paper finds that 256-bit modular multiplication is gated by IMAD instruction count and by register bank conflicts, not by floating-point throughput; their fix uses predicate registers to carry the high-word carry and reorders IMAD instructions to reduce register moves, then exploits the SM2 prime $q = 2^{256} - 2^{224} - 2^{96} + 2^{64} - 1$ to replace further IMADs with IADD3. On the author's measurements, these optimizations yield 1.63-1.72x faster modular multiplication than the fastest single-thread integer baseline, 4.18x faster ECDSA signature generation, 5.56x faster signature verification, 4.94x faster ECDH fixed-point multiplication, and 1.56x higher throughput in a FISCO-BCOS blockchain deployment.

Load-bearing premise

The batching advantage rests on the assumption, imported from CPU latency figures rather than measured on the A100, that modular inversion is roughly 100x more expensive than modular multiplication; if the real ratio is near 20x or below, affine-coordinate batching loses to Jacobian coordinates.

Editorial extensions

If this is right

  • For batch sizes above about $N > 20$, affine-coordinate EC operations with Montgomery's-trick batching outperform Jacobian-coordinate operations, so throughput-oriented GPU ECC libraries can safely abandon the usual Jacobian choice.
  • Minimizing IMAD instructions matters more than raw instruction count: programs with fewer SASS instructions can run slower if their issue rate is lower, so future GPU arithmetic optimization should be guided by issued-cycle estimation, not instruction totals.
  • The SM2 curve's special prime admits a reduction phase built almost entirely from 72 IADD3 instructions instead of hundreds of IMADs, giving 1.63-1.72x over the fastest integer-based baseline on V100 and A100.
  • End-to-end, the framework lifts ECDSA signature generation to 14,141,978 per second, signature verification to 4,372,853 per second, and a four-node FISCO-BCOS blockchain from about 5,948 to 9,313 transactions per second.

Reading between the lines

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

  • The paper's IMAD-count analysis is framed for Ampere GPUs; applying the same framework to a different architecture would require re-measuring issue rates, since the 4-cycle IMAD issue interval and IADD3 2-cycle interval are hardware-specific.
  • The affine-coordinate batching strategy is not curve-specific in principle, but the IADD3-based reduction gain depends on the SM2 prime's special form; other standardized curves like secp256k1 would need their own reduction identities to see the same arithmetic-level boost.
  • The reported gains assume large concurrent workloads; applications with batch sizes below the $N > 20$ crossover would not see the inversion-amortization benefit and could even regress.
  • The GAS-style batch inversion could carry over to other finite-field settings where inversion is expensive, such as pairing-based or post-quantum primitives that rely on modular inversions, though the instruction-level tuning would differ.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 gECC, a CUDA framework for high-throughput elliptic curve cryptography on GPUs, targeting the SM2 curve on NVIDIA A100 and V100. The framework batches EC operations via Montgomery's trick, uses a Gather-Apply-Scatter mechanism for batch modular inversion, introduces multi-level cache management and column-major data layout, fuses PADD/PDBL kernels, and optimizes modular multiplication at the SASS level by reducing IMAD instructions through predicate-register carries and IADD3 substitutions. The evaluation compares against RapidEC, CGBN, and DPF, and reports multi-fold speedups for ECDSA, ECDH, point multiplication, and modular multiplication, plus a 1.56x improvement in a FISCO-BCOS blockchain application. The claimed headline speedups are 5.56x for ECDSA and 4.94x for ECDH in the abstract; however, these numbers are not consistently reproduced by the tables in Section 5, and no end-to-end ECDH benchmark is presented.

Significance. If the reported results hold, gECC would be a strong systems contribution: it appears to be the first GPU implementation of batched PMUL using Montgomery's trick, it provides a detailed SASS-level analysis of modular multiplication bottlenecks, and it includes useful ablation experiments (RapidEC+OM, RapidEC+OM+BI, RapidEC+OM+BF, gECC-MO, gECC-MO-KF) that isolate the effect of each optimization. The paper also makes the code publicly available, which supports reproducibility. The main weakness is that the central quantitative claims in the abstract and introduction are internally inconsistent with Tables 4 and 5, and the ECDH claim is not backed by any dedicated experiment. These issues are correctable but must be fixed before the paper can be accepted.

major comments (4)
  1. [Abstract and §5.2] The abstract's headline '5.56x for ECDSA' is not reproduced by Table 4. Section 1 states 4.18x for signature generation and 5.56x for signature verification; Table 4 gives 14,141,978/3,386,544 = 4.18x for generation and 4,372,853/773,481 = 5.65x for verification. The value 5.56x does not appear in Table 4, so the abstract's ECDSA number appears to be a rounding or transcription of the verification-only speedup. Please correct the number to 5.65x and state that it refers to signature verification, or provide an end-to-end ECDSA experiment whose result is 5.56x, and update the abstract accordingly.
  2. [§5.1 and Table 5] The abstract's 4.94x for ECDH is not supported by any experiment in the paper. Section 5.1 states that ECDH throughput is dominated by FPMUL and that 'we only report the throughput value of the FPMUL operation,' but no ECDH benchmark appears in Section 5. Table 5 gives a maximum FPMUL speedup of 14,389,168/3,810,161 = 3.78x (batch size 2^14). The introduction's pair 'up to 4.04x and 4.94x' for FPMUL and UPMUL also does not match Table 5, whose maxima are 3.78x and 6,689,186/1,427,610 = 4.69x. The 4.94x figure must be either an actual ECDH measurement (which should be added) or a correctly labeled UPMUL value; as written, the most prominent quantitative claim is unverifiable.
  3. [§3.1] The crossover argument for affine coordinates with Montgomery's trick (N > 20) is derived from CPU latency ratios: Section 2.2 states that modinv/modadd is about 500 and modmul/modadd about 5 'on a mainstream server.' Since the target platform is the A100, and the affine-batching design depends on modular inversion being substantially more expensive than modular multiplication on that GPU, the crossover should be established on the target hardware. Please measure the modinv/modmul latency ratio on the A100 and V100, and if the ratio differs from the CPU-based estimate, re-derive the crossover and re-examine the batch-size claims in Section 5.3.
  4. [§3.4, Algorithm 3] The claim that 'our design ensures constant time' is not substantiated. Algorithm 3 contains a scalar-dependent branch 'if s[i] == 1 then Qj = Rj' (line 22), and Section 4.1's own microarchitectural analysis shows that instruction issue behavior is sensitive to instruction order and dependencies. On a GPU, a per-thread branch on a secret scalar can produce warp divergence whose timing depends on the scalar bits. Please either remove the constant-time claim, qualify it to 'no secret-dependent operation count' with supporting evidence, or provide a side-channel evaluation showing that the branch does not leak timing information.
minor comments (4)
  1. [§5.1 and §3.4] There are several typos and terminology issues: 'Votal V100' should be 'Volta V100', 'PUML operation' should be 'PMUL operation', and 'SP' is used for what appears to be the A100's SM or warp scheduler; please define the term consistently with CUDA terminology.
  2. [Table 3 and §5.4] The notation for the floating-point implementation is inconsistent: Table 3 and parts of Section 4 use 'DPF-1', while Section 5.4 and Figure 12 use 'DFP-1'. Please use one name throughout.
  3. [§2.2] The statement that modmul and modinv have about 5x and 500x the latency of modadd on a mainstream server has no citation or measurement; please add a reference or move the measurement to the evaluation section.
  4. [Figures 9 and 10] The normalized-throughput axis labels and the scientific-notation values in Figures 9 and 10 are difficult to read; please enlarge the fonts and label the bars with the exact numeric values used in the text.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: gECC's results are empirical comparisons against independent baselines; the abstract/table speedup mismatch is a verifiability defect, not circular reasoning.

full rationale

The derivation chain is not circular. The central throughput claims (Section 5, Tables 4 and 5, Figures 9-12) are measured against independent baselines: RapidEC [33], CGBN-1/2/4 [35], DPF-1 [31], and the FISCO-BCOS CPU baseline. gECC's design choices are motivated by (a) the affine-versus-Jacobian operation counts in Table 1, (b) the latency ratios cited in Section 2.2 (modmul about 5x modadd, modinv about 500x modadd), and (c) the SASS instruction-issue microbenchmarks in Table 2. The crossover batch size N>20 in Section 3.1 is a derived design heuristic from those counts and ratios, not a fitted parameter later reported as a prediction; if the GPU's modinv/modmul ratio is lower than the cited CPU ratio, the heuristic weakens, but no fitted quantity is disguised as a prediction. The IMAD-minimization work in Section 4.1 uses a theoretical 136-IMAD count derived from the m^2 + m + m^2 structure of SOS Montgomery multiplication; the paper's claim that its disassembled implementation 'aligns with the theoretical prediction' is a validation against the algorithm structure, not an input-output tautology. No load-bearing step reduces to a self-citation: the cited prior works (Montgomery [1], RapidEC [33], CGBN [35], DPF [31], sppark [50], and the SM2 ASIC work [60]) are external, and none of the authors' own prior results are invoked to justify a design choice. The headline discrepancy between the abstract and introduction numbers (5.56x for ECDSA, 4.94x for ECDH, 4.04x for FPMUL) and Tables 4-5 (4.18x signature generation, 5.65x verification, maximum 3.78x FPMUL, maximum 4.69x UPMUL, and no separate ECDH benchmark) is a serious verifiability and internal-consistency problem, but it is a correctness and number-traceability issue, not circularity. Therefore, the circularity score is 0.

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

The paper's central claims are empirical performance results, not mathematical derivations. The design introduces a small number of assumptions: the relative latency of modular inversion versus multiplication, and the measured SASS issue rates. No invented entities are introduced. The only hand-set knob that affects the central performance claims is the L2 persistent cache fraction, which is not reported.

free parameters (1)
  • L2 persistent cache fraction = not stated
    The paper says gECC sets aside a portion of L2 as persistent cache (Section 3.3) using CUDA's up-to-75% residency control, but does not report the actual fraction used. This hand-set configuration can affect batch PADD and PMUL performance.
assumptions (4)
  • standard math Elliptic curve group laws and the double-and-add algorithm (Algorithm 1) are correct.
    Section 2.1 uses these to define PADD/PDBL/PMUL; standard textbook material.
  • domain assumption Modular inversion is roughly 100x more expensive than modular multiplication on the target GPU, making affine-coordinate batch inversion beneficial for batch sizes above 20.
    Section 3.1 derives the N>20 crossover using CPU latency ratios (modinv about 500x modadd, modmul about 5x modadd) stated in Section 2.2; the same ratio is assumed on GPU and is not measured on A100.
  • domain assumption The measured SASS instruction issue rates (IMAD/DFMA every 4 cycles, IADD3 every 2 cycles, Table 2) are stable and representative on the A100.
    Section 4.1.1 infers these rates from microbenchmarks; they are not documented by NVIDIA and drive the IMAD-minimization design.
  • standard math The SM2 prime q = 2^256 - 2^224 - 2^96 + 2^64 - 1 has q_inv equal to 1, enabling the reduction replacement of IMADs with IADD3s.
    Section 4.2 uses this modular property, which follows from q being congruent to 1 modulo 2^32; the paper states q_inv=1 but does not prove it.

how reviews work

0 comments
Cite this review

Pith. "Pith review of gECC: A GPU-based high-throughput framework for Elliptic Curve Cryptography." pith.science (2026). https://pith.science/paper/HPWZCHYD

@misc{pith2026250103245,
  author       = {Pith},
  title        = {Pith review of: gECC: A GPU-based high-throughput framework for Elliptic Curve Cryptography},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HPWZCHYD}},
  note         = {Machine review of arXiv:2501.03245}
}
read the original abstract

Elliptic Curve Cryptography (ECC) is an encryption method that provides security comparable to traditional techniques like Rivest-Shamir-Adleman (RSA) but with lower computational complexity and smaller key sizes, making it a competitive option for applications such as blockchain, secure multi-party computation, and database security. However, the throughput of ECC is still hindered by the significant performance overhead associated with elliptic curve (EC) operations. This paper presents gECC, a versatile framework for ECC optimized for GPU architectures, specifically engineered to achieve high-throughput performance in EC operations. gECC incorporates batch-based execution of EC operations and microarchitecture-level optimization of modular arithmetic. It employs Montgomery's trick to enable batch EC computation and incorporates novel computation parallelization and memory management techniques to maximize the computation parallelism and minimize the access overhead of GPU global memory. Also, we analyze the primary bottleneck in modular multiplication by investigating how the user codes of modular multiplication are compiled into hardware instructions and what these instructions' issuance rates are. We identify that the efficiency of modular multiplication is highly dependent on the number of Integer Multiply-Add (IMAD) instructions. To eliminate this bottleneck, we propose techniques to minimize the number of IMAD instructions by leveraging predicate registers to pass the carry information and using addition and subtraction instructions (IADD3) to replace IMAD instructions. Our results show that, for ECDSA and ECDH, gECC can achieve performance improvements of 5.56x and 4.94x, respectively, compared to the state-of-the-art GPU-based system. In a real-world blockchain application, we can achieve performance improvements of 1.56x, compared to the state-of-the-art CPU-based system.

Figures

Figures reproduced from arXiv: 2501.03245 by the authors.

Figure 1
Figure 1. Overview of gECC Framework. There are recent efforts [31, 32, 33] in employing GPU to minimize the latency of individual EC operations. However, achieving the high-throughput requirements of emerging big data applications remains a challenge. To close the gap, we present a high-throughput GPU-based ECC framework, which is holistically optimized to max￾imize the data processing throughput. The optimizations consist o… view at source ↗
Figure 2
Figure 2. The example of Montgomery’s trick. In this section, we review a well-known method, called Montgomery’s Trick, which could compress n modinv operations into one modinv operation by introducing 3n modmul operations. There are three key steps in Mont￾gomery’s trick. For example, to calculate a −1 , b−1 , c−1 , d−1 from the inputs a, b, c, d, as shown in [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 2
Figure 2. To tackle this issue, we propose two significant optimizations: first, a [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figures from the paper (10 more)
Figure 3
Figure 3. Figure 3: Different mechanism of batch modular inversion on GPU and corresponding runtime execution. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png]
Figure 4
Figure 4. Figure 4: Multi-level cache management for batch PADD. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: The data layout of n EC point Cache-efficient data layout. gECC adopts a cache-efficient column-majored data layout for large integers to achieve efficient concurrent data access, improving the efficiency of global memory access. Usually, a large integer is rep￾resente…
Figure 6
Figure 6. Figure 6: An example of find-then-recompute method. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Divergent carry addition chains for odd and even word-size integer [PITH_FULL_IMAGE:figures/full_fig_p012_7.png]
Figure 8
Figure 8. Figure 8: General modmul algorithm for m=4 After customizing the one row-by-row multiplication with two mad_n func￾tions, we still need to pay attention to the IMAD order when applying it to the integer multiplication stage of the modmul operation because regis￾ter move and bank…
Figure 9
Figure 9. Figure 9: Breakdown analysis of signature generation [PITH_FULL_IMAGE:figures/full_fig_p014_9.png]
Figure 10
Figure 10. Figure 10: Breakdown analysis of signature verification [PITH_FULL_IMAGE:figures/full_fig_p015_10.png]
Figure 11
Figure 11. Figure 11: Breakdown analysis of Point Multiplication [PITH_FULL_IMAGE:figures/full_fig_p016_11.png]
Figure 12
Figure 12. Figure 12: Throughput analysis of modmul operation In this section, we examine the throughput of the modmul operation, the major underlying computation within ECC. We compare against several accelerated modmul implementations. CGBN [35] is the finite field arithmetic library use…

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. M-ary Precomputation-Based Accelerated Scalar Multiplication Algorithms for Enhanced Elliptic Curve Cryptography

    cs.CR 2025-05 conditional novelty 2.0 of 10

    The claimed Θ(Q log p / log Q) speedup is a restatement of known fixed-base precomputation tradeoffs, and the supplied experiments do not validate the stated memory and timing gains.

Reference graph

Works this paper leans on

61 extracted references · 58 canonical work pages · cited by 1 Pith paper

  1. [1]

    Speeding the pollard and elliptic curve methods of factorization.Mathematics of computation, 48(177):243–264, 1987

    Peter L Montgomery. Speeding the pollard and elliptic curve methods of factorization.Mathematics of computation, 48(177):243–264, 1987

    work page 1987

  2. [2]

    Use of elliptic curves in cryptography

    Victor S Miller. Use of elliptic curves in cryptography. In Conference on the theory and application of cryptographic techniques, pages 417–426. Springer, 1985

    work page 1985

  3. [3]

    Elliptic curve cryptosystems

    Neal Koblitz. Elliptic curve cryptosystems. Mathematics of computation, 48(177):203–209, 1987

    work page 1987

  4. [4]

    Glassdb: An efficient verifiable ledger database system through transparency

    Cong Yue, Tien Tuan Anh Dinh, Zhongle Xie, Meihui Zhang, Gang Chen, Beng Chin Ooi, and Xiaokui Xiao. Glassdb: An efficient verifiable ledger database system through transparency. arXiv preprint arXiv:2207.00944, 2022

    arXiv 2022

  5. [5]

    Hybrid blockchain database systems: design and performance

    Zerui Ge, Dumitrel Loghin, Beng Chin Ooi, Pingcheng Ruan, and Tianwen Wang. Hybrid blockchain database systems: design and performance. Proceedings of the VLDB Endowment, 15(5):1092–1104, 2022

    work page 2022

  6. [6]

    The anatomy of blockchain database systems

    Dumitrel Loghin. The anatomy of blockchain database systems. Data Engineering, page 48, 2022

    work page 2022

  7. [7]

    Ledgerdb: A centralized ledger database for universal audit and verification.Proceedings of the VLDB Endowment, 13(12):3138– 3151, 2020

    Xinying Yang, Yuan Zhang, Sheng Wang, Benquan Yu, Feifei Li, Yize Li, and Wenyuan Yan. Ledgerdb: A centralized ledger database for universal audit and verification.Proceedings of the VLDB Endowment, 13(12):3138– 3151, 2020

    work page 2020

  8. [8]

    Spitz: a verifiable database system

    Meihui Zhang, Zhongle Xie, Cong Yue, and Ziyue Zhong. Spitz: a verifiable database system. Proc. VLDB Endow., 13(12):3449–3460, August 2020

    work page 2020

Show all 61 references
  1. [9]

    Elliptic curve cryptography (ecc) cipher suites for transport layer security (tls)

    Simon Blake-Wilson, Nelson Bolyard, Vipul Gupta, Chris Hawk, and Bodo Moeller. Elliptic curve cryptography (ecc) cipher suites for transport layer security (tls). Technical report, 2006. 17 A PREPRINT - JANUARY 8, 2025

    2006

  2. [10]

    The elliptic curve digital signature algorithm (ecdsa)

    Don Johnson, Alfred Menezes, and Scott Vanstone. The elliptic curve digital signature algorithm (ecdsa). International journal of information security, 1:36–63, 2001

    2001

  3. [11]

    Than Myo Zaw, Min Thant, and S. V . Bezzateev. Database security with aes encryption, elliptic curve encryption and signature. In 2019 Wave Electronics and its Application in Information and Telecommunication Systems (WECONF), pages 1–6, 2019

    2019

  4. [12]

    Secured data storage and retrieval using elliptic curve cryptography in cloud

    Pradeep Suthanthiramani, Sannasy Muthurajkumar, Ganapathy Sannasi, and Kannan Arputharaj. Secured data storage and retrieval using elliptic curve cryptography in cloud. Int. Arab J. Inf. Technol., 18(1):56–66, 2021

    2021

  5. [13]

    Spot-light: lightweight private set intersection from sparse ot extension

    Benny Pinkas, Mike Rosulek, Ni Trieu, and Avishay Yanai. Spot-light: lightweight private set intersection from sparse ot extension. In Advances in Cryptology–CRYPTO 2019: 39th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 18–22, 2019, Proceedings, ...

    2019

  6. [14]

    Unbalanced private set intersection with linear communication complexity

    Quanyu Zhao, Yuan Zhang Bingbing Jiang, Heng Wang, Yunlong Mao, and Sheng Zhong. Unbalanced private set intersection with linear communication complexity. SCIENCE CHINA Information Sciences, 67(3):132105–, 2024

    2024

  7. [15]

    Efficient secure computation from sm series cryptography

    Yibiao Lu, Zecheng Wu, Bingsheng Zhang, and Kui Ren. Efficient secure computation from sm series cryptography. Wireless Communications and Mobile Computing, 2023(1):6039034, 2023

    2023

  8. [16]

    Practical private intersection-sum protocols with good scalability

    Yuanyuan Li, Hanyue Xiao, Peng Han, and Zhihao Zhou. Practical private intersection-sum protocols with good scalability. In Jianming Zhu, Qianhong Wu, Yong Ding, Xianhua Song, and Zeguang Lu, editors, Blockchain Technology and Application, pages 49–63, Singapore, 2024. Springe...

    2024

  9. [17]

    Cryptographic primitives in blockchains

    Licheng Wang, Xiaoying Shen, Jing Li, Jun Shao, and Yixian Yang. Cryptographic primitives in blockchains. Journal of Network and Computer Applications, 127:43–58, 2019

    2019

  10. [18]

    Integridb: Verifiable sql for outsourced databases

    Yupeng Zhang, Jonathan Katz, and Charalampos Papamanthou. Integridb: Verifiable sql for outsourced databases. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pages 1480– 1491, 2015

    2015

  11. [19]

    Scalable verification for outsourced dynamic databases

    HweeHwa Pang, Jilian Zhang, and Kyriakos Mouratidis. Scalable verification for outsourced dynamic databases. Proceedings of the VLDB Endowment, 2(1):802–813, 2009

    2009

  12. [20]

    Amazon quantum ledger database, 2019

    Amazon. Amazon quantum ledger database, 2019. https://aws.amazon.com/qldb/

    2019

  13. [21]

    Sql ledger: Cryptographically verifiable data in azure sql database

    Panagiotis Antonopoulos, Raghav Kaushik, Hanuma Kodavalla, Sergio Rosales Aceves, Reilly Wong, Jason Anderson, and Jakub Szymaszek. Sql ledger: Cryptographically verifiable data in azure sql database. In Proceedings of the 2021 international conference on management of data, p...

    2021

  14. [22]

    Bitcoin: A peer-to-peer electronic cash system

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008

    2008

  15. [23]

    Ethereum: A secure decentralised generalised transaction ledger

    Gavin Wood et al. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper, 151(2014):1–32, 2014

    2014

  16. [24]

    Zerocash: Decentralized anonymous payments from bitcoin

    Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. Zerocash: Decentralized anonymous payments from bitcoin. In 2014 IEEE symposium on security and privacy, pages 459–474. IEEE, 2014

    2014

  17. [25]

    Hyperledger fabric: a distributed operating system for permissioned blockchains

    Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, et al. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceeding...

    2018

  18. [26]

    Sec 2: Recommended elliptic curve domain parameters

    Minghua Qu. Sec 2: Recommended elliptic curve domain parameters. Certicom Res., Mississauga, ON, Canada, Tech. Rep. SEC2-Ver-0.6, 1999

    1999

  19. [27]

    Digital signature standard (dss)

    National Institute of Standards and Technology (NIST). Digital signature standard (dss). Federal Information Processing Standards (FIPS) Publication 186-4, 2024. https://nvlpubs.nist.gov/nistpubs/fips/nist. fips.186-4.pdf

    2024

  20. [28]

    Provably-secure (chinese government) sm2 and simplified sm2 key exchange protocols

    Ang Yang, Junghyun Nam, Moonseong Kim, and Kim-Kwang Raymond Choo. Provably-secure (chinese government) sm2 and simplified sm2 key exchange protocols. The Scientific World Journal, 2014(1):825984, 2014

    2014

  21. [29]

    Public key cryptographic algorithm sm2 based on elliptic curves, 2016

    State Cryptography Administration of China (SCA). Public key cryptographic algorithm sm2 based on elliptic curves, 2016

    2016

  22. [30]

    Baldur: A hybrid blockchain database with fpga or gpu acceleration

    Rares Ifrim, Dumitrel Loghin, and Decebal Popescu. Baldur: A hybrid blockchain database with fpga or gpu acceleration. In Proceedings of the 1st Workshop on Verifiable Database Systems, VDBS ’23, page 19–27, New York, NY , USA, 2023. Association for Computing Machinery. 18 A P...

    2023

  23. [31]

    Dpf-ecc: Accelerating elliptic curve cryptography with floating-point computing power of gpus

    Lili Gao, Fangyu Zheng, Niall Emmart, Jiankuo Dong, Jingqiang Lin, and Charles Weems. Dpf-ecc: Accelerating elliptic curve cryptography with floating-point computing power of gpus. In 2020 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pages 494–504....

    2020

  24. [32]

    Dpf-ecc: A framework for efficient ecc with double precision floating-point computing power

    Lili Gao, Fangyu Zheng, Rong Wei, Jiankuo Dong, Niall Emmart, Yuan Ma, Jingqiang Lin, and Charles Weems. Dpf-ecc: A framework for efficient ecc with double precision floating-point computing power. IEEE Transactions on Information Forensics and Security, 16:3988–4002, 2021

    2021

  25. [33]

    Accelerating elliptic curve digital signature algorithms on gpus

    Zonghao Feng, Qipeng Xie, Qiong Luo, Yujie Chen, Haoxuan Li, Huizhong Li, and Qiang Yan. Accelerating elliptic curve digital signature algorithms on gpus. In SC22: International Conference for High Performance Computing, Networking, Storage and Analysis, pages 1–13. IEEE, 2022

    2022

  26. [34]

    Gonzalez, Yucheng Low, Haijie Gu, Danny Bickson, and Carlos Guestrin

    Joseph E. Gonzalez, Yucheng Low, Haijie Gu, Danny Bickson, and Carlos Guestrin. PowerGraph: Distributed Graph-Parallel computation on natural graphs. In 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12), pages 17–30, Hollywood, CA, October 2012. US...

    2012

  27. [35]

    Cgbn: Cuda accelerated multiple precision arithmetic (big num) using cooperative groups, 2018

    NVIDIA. Cgbn: Cuda accelerated multiple precision arithmetic (big num) using cooperative groups, 2018. https://github.com/NVlabs/CGBN

    2018

  28. [36]

    Faster modular exponentiation using double precision floating point arithmetic on the gpu

    Niall Emmart, Fangyu Zheng, and Charles Weems. Faster modular exponentiation using double precision floating point arithmetic on the gpu. In 2018 IEEE 25th Symposium on Computer Arithmetic (ARITH), pages 130–137. IEEE, 2018

    2018

  29. [37]

    Tls/ssl and crypto library, 2024

    OpenSSL Software Foundation. Tls/ssl and crypto library, 2024. https://github.com/openssl/openssl

    2024

  30. [38]

    An efficient elliptic curve cryptography signature server with gpu acceleration

    Wuqiong Pan, Fangyu Zheng, Yuan Zhao, Wen-Tao Zhu, and Jiwu Jing. An efficient elliptic curve cryptography signature server with gpu acceleration. IEEE Transactions on Information Forensics and Security, 12(1):111–122, 2017

    2017

  31. [39]

    Guide to elliptic curve cryptography

    Darrel Hankerson, Alfred J Menezes, and Scott Vanstone. Guide to elliptic curve cryptography. Springer Science & Business Media, 2006

    2006

  32. [40]

    Accelerating sm2 digital signature algorithm using modern processor features

    Long Mai, Yuan Yan, Songlin Jia, Shuran Wang, Jianqiang Wang, Juanru Li, Siqi Ma, and Dawu Gu. Accelerating sm2 digital signature algorithm using modern processor features. In International Conference on Information and Communications Security, pages 430–446. Springer, 2019

    2019

  33. [41]

    Parallel implementation of sm2 elliptic curve cryptogra- phy on intel processors with avx2

    Junhao Huang, Zhe Liu, Zhi Hu, and Johann Großschädl. Parallel implementation of sm2 elliptic curve cryptogra- phy on intel processors with avx2. In Information Security and Privacy: 25th Australasian Conference, ACISP 2020, Perth, WA, Australia, November 30–December 2, 2020, ...

    2020

  34. [42]

    Modular multiplication without trial division

    Peter L Montgomery. Modular multiplication without trial division. Mathematics of computation, 44(170):519– 521, 1985

    1985

  35. [43]

    Analyzing and comparing montgomery multiplication algorithms

    C Kaya Koc, Tolga Acar, and Burton S Kaliski. Analyzing and comparing montgomery multiplication algorithms. IEEE micro, 16(3):26–33, 1996

    1996

  36. [44]

    Fast constant-time gcd computation and modular inversion

    Daniel J Bernstein and Bo-Yin Yang. Fast constant-time gcd computation and modular inversion. IACR Transactions on Cryptographic Hardware and Embedded Systems, pages 340–398, 2019

    2019

  37. [45]

    High-assurance field inversion for curve-based cryptography

    Benjamin Salling Hvass, Diego F Aranha, and Bas Spitters. High-assurance field inversion for curve-based cryptography. In 2023 IEEE 36th Computer Security Foundations Symposium (CSF), pages 552–567. IEEE, 2023

    2023

  38. [46]

    Bernstein, Billy Bob Brumley, Ming-Shing Chen, and Nicola Tuveri

    Daniel J. Bernstein, Billy Bob Brumley, Ming-Shing Chen, and Nicola Tuveri. OpenSSLNTRU: Faster post- quantum TLS key exchange. In 31st USENIX Security Symposium (USENIX Security 22), pages 845–862, Boston, MA, August 2022. USENIX Association

    2022

  39. [47]

    sdpf-rsa: Utilizing floating-point computing power of gpus for massive digital signature computations

    Jiankuo Dong, Fangyu Zheng, Niall Emmart, Jingqiang Lin, and Charles Weems. sdpf-rsa: Utilizing floating-point computing power of gpus for massive digital signature computations. In 2018 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pages 599–609, 2018

    2018

  40. [48]

    Exploiting the potential of gpus for modular multiplication in ecc

    Fangyu Zheng, Wuqiong Pan, Jingqiang Lin, Jiwu Jing, and Yuan Zhao. Exploiting the potential of gpus for modular multiplication in ecc. In International Workshop on Information Security Applications, pages 295–306. Springer, 2014

    2014

  41. [49]

    Towards high- performance x25519/448 key agreement in general purpose gpus

    Jiankuo Dong, Fangyu Zheng, Juanjuan Cheng, Jingqiang Lin, Wuqiong Pan, and Ziyang Wang. Towards high- performance x25519/448 key agreement in general purpose gpus. In 2018 IEEE Conference on Communications and Network Security (CNS), pages 1–9. IEEE, 2018

    2018

  42. [50]

    Zero-knowledge template library, 2024

    Supranational Corp. Zero-knowledge template library, 2024. https://github.com/supranational/sppark

    2024

  43. [51]

    Accelerating the future of zero-knowledge cryptography, 2023

    ZPrize. Accelerating the future of zero-knowledge cryptography, 2023. https://www.zprize.io/. 19 A PREPRINT - JANUARY 8, 2025

    2023

  44. [52]

    Cuda c++ programming guide, 2024

    Nvidia Corp. Cuda c++ programming guide, 2024. https://docs.nvidia.com/cuda/ cuda-c-programming-guide/index.html#arithmetic-instructions

    2024

  45. [53]

    Nvidia a100 tensor core gpu architecture, 2022

    NVIDIA. Nvidia a100 tensor core gpu architecture, 2022. https://images.nvidia.com/aem-dam/en-zz/ Solutions/data-center/nvidia-ampere-architecture-whitepaper.pdf

    2022

  46. [54]

    Paul C. Kocher. Timing attacks on implementations of diffie-hellman, rsa, dss, and other systems. In Neal Koblitz, editor, Advances in Cryptology — CRYPTO ’96 , pages 104–113, Berlin, Heidelberg, 1996. Springer Berlin Heidelberg

    1996

  47. [55]

    Cuda kernel profiling using nvidia nsight compute, 2019

    Nvidia Corp. Cuda kernel profiling using nvidia nsight compute, 2019. https: //developer.download.nvidia.cn/video/gputechconf/gtc/2019/presentation/ s9345-cuda-kernel-profiling-using-nvidia-nsight-compute.pdf

    2019

  48. [56]

    Nsight compute documentation, 2024

    Nvida Corp. Nsight compute documentation, 2024. https://docs.nvidia.com/nsight-compute/2023.2/ index.html

    2024

  49. [57]

    Communication optimization on gpu: A case study of sequence alignment algorithms

    Jie Wang, Xinfeng Xie, and Jason Cong. Communication optimization on gpu: A case study of sequence alignment algorithms. In 2017 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pages 72–81. IEEE, 2017

    2017

  50. [58]

    Dissecting the nvidia volta gpu architecture via microbenchmarking

    Zhe Jia, Marco Maggioni, Benjamin Staiger, and Daniele P Scarpazza. Dissecting the nvidia volta gpu architecture via microbenchmarking. arXiv preprint arXiv:1804.06826, 2018

    2018 arXiv

  51. [59]

    Dissecting the ampere gpu architecture through microbenchmarking

    Z Jia and PV Sandt. Dissecting the ampere gpu architecture through microbenchmarking. In GTC, 2021

    2021

  52. [60]

    A high-performance elliptic curve cryptographic processor of sm2 over gf (p)

    Xianghong Hu, Xin Zheng, Shengshi Zhang, Weijun Li, Shuting Cai, and Xiaoming Xiong. A high-performance elliptic curve cryptographic processor of sm2 over gf (p). Electronics, 8(4):431, 2019

    2019

  53. [61]

    FISCO BCOS: an enterprise-level financial blockchain platform developed and open-sourced by the Financial Services Blockchain Consortium (Shenzhen) "FISCO" led by WeBank., 2024

    FISCO. FISCO BCOS: an enterprise-level financial blockchain platform developed and open-sourced by the Financial Services Blockchain Consortium (Shenzhen) "FISCO" led by WeBank., 2024. https://github.com/ FISCO-BCOS/java-sdk-demo.git . 20

    2024

Pith tools

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