Pith. sign in

REVIEW 4 major objections 5 minor 29 references

Bi-SamplerZ: A Hardware-Efficient Gaussian Sampler Architecture for Quantum-Resistant Falcon Signatures

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

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

Pith's one-line read Two concurrent SamplerZ datapaths with a cross-path assistance mechanism achieve the lowest latency and best area-time product among full-hardware Falcon samplers.

desk verdict Solid hardware contribution with a reproducible 59-cycle result, but the 54.1% expected-cycle reduction is a model estimate, not a measurement. read the letter →

arxiv 2505.24509 v1 pith:SWJHIVCZ submitted 2025-05-30 cs.AR

Binke Zhao , Ghada Alsuhi , Hani Saleh , Baker Mohammad This is my paper
classification cs.AR
keywords discreteGaussiansamplingFalconsignaturepost-quantumcryptographyhardwareacceleratordual-datapatharchitecturerejectionarea-timeproductASICimplementation
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 claims that Falcon's discrete Gaussian sampler, SamplerZ, can be accelerated by exploiting a structural fact: every leaf of Falcon's Fast Fourier Sampling tree invokes SamplerZ twice on independent inputs. It proposes Bi-SamplerZ, a dual-datapath hardware design that runs both calls concurrently, shares preprocessing and base-sampling hardware between the paths, and adds a cross-path assistance mechanism that lets a successful datapath help a rejected one. The paper reports 59 cycles for two SamplerZ calls versus 137 for the FalconSign full-hardware design, an expected latency of 106.08 cycles versus 230.83, and a 6.97x throughput improvement at 17.6% area overhead, yielding the best area-time product among fully hardware-based samplers. If these numbers hold, the design removes the main bottleneck in Falcon signature generation and makes post-quantum signing faster on constrained hardware.

What carries the argument

The load-bearing object is the dual-datapath architecture with a cross-path assistance mechanism. Two SamplerZ datapaths run concurrently; when exactly one datapath's Bernoulli acceptance trial fails, the successful datapath switches its mean to the rejected path's value and recomputes the For-loop inputs, so that the next retry only needs one of the two paths to succeed. The mechanism's expected benefit is derived from a geometric rejection model in which each attempt succeeds with probability p ≈ 0.5758 and the assisted retry succeeds with probability p' = 1 − (1 − p)^2 ≈ 0.823.

What would settle it

Run the official Falcon-512 reference software over many signing keys and messages, record the number of SamplerZ retries per call, and compare the observed per-attempt success probability with p = 0.5758; if the observed distribution differs, the expected-cycle figures in Table V shift. Alternatively, integrate Bi-SamplerZ into a complete Falcon signing pipeline and measure end-to-end signature latency; if the full-pipeline speedup is far below the 6.97x sampler-level figure, the headline claim does not translate to system-level signing throughput.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that the pairing of SamplerZ calls at the leaves of Falcon's ffSampling recursion is a free source of parallelism that previous hardware designs did not exploit. By instantiating two datapaths and letting the successful path recompute intermediate values for the rejected path, the architecture raises the effective acceptance probability from p ≈ 0.5758 to p' = 1 - (1-p)^2 ≈ 0.823, cutting the expected number of rejection retries while adding only about nine cycles of overhead. This is combined with an 81-bit fixed-point representation, lookup tables for the z0-dependent term, and a tri-state gate-based BaseSampler, producing what the paper reports as the lowest sampling latency and best area-time product among full-hardware SamplerZ implementations.

Load-bearing premise

The expected-latency comparisons are computed from a rejection-failure distribution quoted from another design (Table I) rather than measured on real Falcon signing runs, and the assistance mechanism's p' formula assumes the two datapaths retry independently with the same success probability on every attempt.

Editorial extensions

If this is right

  • Two SamplerZ calls complete in 59 cycles, down from 137 in FalconSign, a 54.1% cycle reduction.
  • Expected latency for two samples is 106.08 cycles, versus 111.54 without the assistance mechanism and 230.83 for FalconSign.
  • At 1.5 GHz ASIC synthesis the design yields a 6.97x throughput improvement over FalconSign with 17.6% more area, giving the best area-time product among fully hardware-based samplers.
  • Because Bi-SamplerZ reuses FalconSign's sampler interface, it can be integrated into existing Falcon signing frameworks without interface changes.
  • An FPGA implementation at 150 MHz (14.3K LUTs, 85 DSPs) also achieves the 59-cycle latency, indicating the result is not confined to ASIC technology.

Reading between the lines

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

  • If Bi-SamplerZ replaces the sampler inside a complete Falcon signing engine, the end-to-end speedup will likely be smaller than the 6.97x sampler-level figure because SamplerZ is only about 72% of signing time; the paper does not report full-pipeline signing results.
  • The assistance mechanism's independence assumption can be tested against real Falcon signing traces; if the two datapaths' rejection events are positively correlated, the p' = 0.823 calculation overestimates the retry benefit.
  • The paired-call pattern exploited here may also appear in other lattice-based schemes with recursive Gaussian sampling, so the dual-datapath assistance idea could transfer beyond Falcon, though the paper does not claim this.
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 / 5 minor

Summary. The paper proposes Bi-SamplerZ, a hardware accelerator for Falcon's discrete Gaussian sampler SamplerZ. The key architectural idea is a dual-datapath design that executes the two SamplerZ calls made at each leaf of Falcon's ffSampling recursion in parallel, with shared preprocessing and a cross-path assistance mechanism intended to reduce the cost of rejection-sampling retries. The authors report ASIC (GF 22nm, Synopsys DC) and FPGA (Xilinx ZCU104, Vivado 2019.2) implementations, claiming the lowest sampling latency and best area-time product among fully hardware-based SamplerZ designs: 59 cycles for two SamplerZ calls versus 137 for FalconSign, an expected latency of 106.08 cycles versus 230.83, and a 6.97x throughput improvement at 17.6% area overhead.

Significance. If the reported numbers are reliable, the dual-path architecture is a genuinely useful contribution to Falcon hardware acceleration. The paper correctly identifies that the two leaf-level SamplerZ calls are independent and can be executed concurrently, and it backs the comparison by re-synthesizing FalconSign's open-source RTL in the same tool flow, which strengthens the external validity of the deterministic cycle and area comparisons. The open-source availability of the RTL is also a concrete plus. However, the headline quantitative claims—the abstract's 54.1% cycle reduction and the 5.48-cycle benefit of the assistance mechanism—are computed from a simulation model that is described in only one sentence and that relies on a rejection distribution imported from another paper. These specific numbers, and the claimed advantage of the assistance mechanism, are not yet supported by measurement or by a fully specified, validated model. The deterministic 59-cycle versus 137-cycle comparison and the area synthesis results are more robust, so the qualitative low-latency claim is credible, but the precise quantitative story needs additional work.

major comments (4)
  1. [§V.A.2, Table V, Abstract] The abstract's headline '54.1%' reduction is exactly 1 - 106.08/230.83, where 106.08 and 230.83 are outputs of a 'simulation model referencing the Bernoulli rejection distribution from Table I.' The model is described in a single sentence; no equations, pseudocode, or validation are given. Because the expected-cycle numbers in Table V are not measured on the Bi-SamplerZ hardware or on full Falcon signing runs, the paper's central quantitative claim currently rests on an unverified model. Please provide the model in full, justify the use of a constant success probability p = 0.5758 for all SamplerZ calls (the acceptance probability in Algorithm 2 depends on the leaf-specific σ' and r = µ - floor(µ)), and validate the expected-cycle numbers against actual Falcon signing traces or hardware measurements.
  2. [§III.B, §III.C, Algorithm 2] The assistance-mechanism benefit is computed from p' = 1-(1-p)^2, which assumes that after one datapath succeeds, the next retry round has two independent attempts with the same success probability p, and that either success completes the task. This is not established. The two SamplerZ calls at a Falcon leaf have different centers µ, so their acceptance probabilities differ; Table I is an aggregate over 102,400 executions and does not support the independence or identical-distribution assumption. More seriously, §III.C states that in the ALOOP state 'as long as at least one datapath successfully passes the acceptance check, the sampling task is considered complete.' This needs to be reconciled with Algorithm 1, which requires two distinct samples z0 and z1. If the successful datapath's candidate is used to fill the failed datapath's output slot, the output distribution is not the required one; if instead only the rejected datapath's retry counts, the probability is p, not p'. The paper must clarify the semantics of the assistance mechanism and either prove distributional correctness or verify it by simulation against the reference Falcon software.
  3. [§IV.A, Lemma 2] The proof that the 81-bit fixed-point format preserves double precision across multiplications is flawed. The paper states that if both operands have binary exponents ex, ey ≥ -20, then no precision is lost, but the derived condition for a product to retain 53 bits is ex+ey ≥ -20, not ex ≥ -20 and ey ≥ -20. For example, two operands with ex = ey = -15 would have a product with exponent -30, whose 53-bit significand extends to 2^-82—below the 2^-72 LSB of the proposed format—so bits are lost. The paper's range analysis does not rule out such products. Please correct the proof by adding the missing range conditions, or provide an empirical error analysis comparing Bi-SamplerZ outputs against the reference Falcon software over the full parameter space.
  4. [§IV, §V, Abstract] The paper uses three different latency metrics without clearly distinguishing them: deterministic cycles for two samplings without rejection (59 vs 137, a 56.9% reduction), expected cycles including rejection from the simulation model (106.08 vs 230.83, a 54.1% reduction), and time-normalized latency using the different clock frequencies (1.88x normalized latency for FPGA, a 46.8% reduction). The abstract's '54.1%' matches the expected-cycle metric, but Table IV's 'Cycles' column and the throughput ratio of 6.97x are based on different definitions. Please state explicitly which quantity the abstract's and Section V's claims refer to, and present the time-normalized numbers consistently so readers can compare cycle counts and wall-clock latency without ambiguity.
minor comments (5)
  1. [Table I, §III.B] The provenance of the failure statistics in Table I is ambiguous: the caption cites reference [23], while the text in §III.B says the statistics are 'reported in [19]'. Please reconcile the citation.
  2. [§V.A.2] The text says 'Using an average rejection probability of approximately 0.5758'; 0.5758 is the success probability, not the rejection probability. Please fix the terminology.
  3. [§III.B, §III.C, §V.A.2] The overhead of the assistance mechanism is reported as 9 cycles in §III.B and §V.A.2 but as approximately 7 cycles in §III.C. Please align these numbers.
  4. [Table IV] The FPGA ATP columns contain multiple normalized values (LUT-based, FF-based, DSP-based) with no formula given. Please define the ATP metric unambiguously and state which normalized value is used for the claim of 'best ATP'.
  5. [Tables IV and V] The relationship between the deterministic 'Cycles (2 samplings)' column in Table IV and the 'Expected Cycles' column in Table V is not explained. Please state that the former excludes rejection retries and that the latter includes the modeled rejection distribution, and make the distinction visible in the table captions.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the performance comparisons use re-synthesized external RTL and an externally attributed rejection distribution, and the expected-latency numbers are transparent model outputs rather than fitted parameters renamed as predictions.

full rationale

The paper's central hardware claims do not reduce to their own inputs. The deterministic cycle-count comparison (59 vs. 137 in Table IV) is benchmarked against FalconSign's open-source RTL, which the authors state was re-synthesized with the same EDA toolchain and technology node, making the comparison external and reproducible rather than self-referential. The probabilistic latency numbers in Table V are explicitly computed from a simulation model, as the paper states: 'we designed a simulation model referencing the Bernoulli rejection distribution from Table I' and 'using an average rejection probability of approximately 0.5758, we computed the expected number of cycles required to generate two accepted samples.' The 54.1% expected-cycle reduction is therefore a transparent computation from stated inputs, not a parameter fitted to the claimed result. The assistance-mechanism probability p' = 1-(1-p)^2 is a mathematical consequence of the stated Bernoulli and independence assumptions; although those assumptions are not verified against full Falcon signing runs, this is an unvalidated modeling assumption and an evidence-quality limitation, not a circular reduction. No load-bearing step is justified by self-citation: Table I is attributed to [23] and in-text to [19], both external works, and no author-overlap result is invoked to force the design choice. The provenance ambiguity and unverified constant-p/independence assumptions may affect the strength of the 5.48-cycle assistance benefit, but they do not make the derivation circular. Under the hard rules, circularity requires an exhibited specific reduction of a claimed result to its own inputs; none is present here.

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

The central claim rests on imported rejection statistics (p=0.5758), on the structural independence of Falcon's paired leaf-level SamplerZ calls, on a fixed-point precision argument that is asserted rather than formally proved, and on synthesis numbers. There are no invented cryptanalytic or physical entities. The free parameters are mainly the external success probability and the assistance-cycle overhead. The 54.1% cycle reduction and 6.97x throughput figures are direct synthesis/cycle-count comparisons, not derived from fitted constants, which keeps the ledger relatively clean for an engineering paper.

free parameters (4)
  • Success probability p used for latency modeling = 0.5758
    Taken from Table I, itself quoted from reference [19]. Used to compute expected cycles for two acceptances and the assistance-mechanism benefit in Table V. If this is not the true sampling success distribution, the expected-latency numbers change. It is a fitted/imported statistic, not measured in this paper.
  • z0 range (z0 <= 18) = 18 (index set 0..18 per Table 10 z0)
    Used to size the LUT T[z0] and the 9-bit fixed-point range. Chosen from Falcon's parameter set, not derived from first principles in the paper.
  • Design time constants sigma_min, sigma_max = Falcon parameter values, implied values sigma_min and sigma_max from [8]
    Standard Falcon parameters used as inputs; treated as constants from the prior Falcon specification, but they set the ccs and LUT range.
  • K-factor / cycle overhead for assistance mechanism = 9 cycles (7 in one section, 9 in Table V)
    The paper states the assistance overhead is 9 cycles in Table V, and Section III.B says 9, while Section V.A.2 says 9 and Section III.C says approximately 7. The 5.48-cycle expected-latency benefit is sensitive to this fitted value.
assumptions (5)
  • domain assumption The two leaf-level SamplerZ calls in ffSampling are truly independent and can be executed concurrently without changing the Falcon distribution.
    Section II.B, lines 6-7 of Algorithm 1. This is the enabler of the whole dual-datapath idea. It is correct for the leaf case, but the paper's claim depends on all two-call pairs being independent, which holds structurally in Falcon.
  • domain assumption Table I's Bernoulli rejection statistics from reference [19] are representative of Falcon signing workloads and of this design's behavior.
    Section III.B uses Table I 'reported in [19]' to justify the assistance mechanism, and Section V.A.2 uses the same 0.5758 success probability to compute expected latencies. The paper does not measure the rejection distribution of its own hardware on Falcon signing traces.
  • domain assumption Independence of rejection outcomes on the two datapaths
    The probability model p' = 1 - (1-p)^2 assumes the two paths' rejection events are independent Bernoulli trials with the same p. Section III.B. The design shares ChaCha20 randomness and some logic, which could induce correlation, and the paper does not test this.
  • ad hoc to paper All SamplerZ intermediate and input values have binary exponents >= -20, and (z-r)^2 < 512, so the 81-bit fixed-point format preserves double precision.
    Section IV.A, Lemmas 1-2 and Theorem 1. The authors justify this with a range bound and an argument that Falcon test vectors show |mu| > 10, but the bound max(z-r)^2 ≈ 361 ignores the 2 sigma'^2 denominator, and the precision proof is informal. This is load-bearing for the correctness of the fixed-point arithmetic.
  • domain assumption Tri-state-based BaseSampler is functionally equivalent to the reference BaseSampler and safe in ASIC synthesis.
    Section IV.C. The monotonic RCDT property guarantees at most one 1-to-0 transition. The paper does not report simulation results comparing the tri-state version's distribution against the reference implementation's distribution.
invented entities (1)
  • No new physical or mathematical entities are invented. The assistance mechanism is a hardware scheduling policy, not a new primitive.
    purpose: Nothing to audit under this category. The only new objects are architectural modules (Pre_samp, Bef_loop, For_loop, CMP, Fpr_adder, Basesampler, tri-state gate array).
    Correctly, this paper does not postulate a new particle, force, dimension, or mathematical object. The invented entities are hardware structures, and their evidence is the synthesis/simulation results in the paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Bi-SamplerZ: A Hardware-Efficient Gaussian Sampler Architecture for Quantum-Resistant Falcon Signatures." pith.science (2026). https://pith.science/paper/SWJHIVCZ

@misc{pith2026250524509,
  author       = {Pith},
  title        = {Pith review of: Bi-SamplerZ: A Hardware-Efficient Gaussian Sampler Architecture for Quantum-Resistant Falcon Signatures},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SWJHIVCZ}},
  note         = {Machine review of arXiv:2505.24509}
}
read the original abstract

FALCON is a standardized quantum-resistant digital signature scheme that offers advantages over other schemes, but features more complex signature generation process. This paper presents Bi-Samplerz, a fully hardware-implemented, high-efficiency dual-path discrete Gaussian sampler designed to accelerate Falcon signature generation. Observing that the SamplerZ subroutine is consistently invoked in pairs during each signature generation, we propose a dual-datapath architecture capable of generating two sampling results simultaneously. To make the best use of coefficient correlation and the inherent properties of rejection sampling, we introduce an assistance mechanism that enables effective collaboration between the two datapaths, rather than simply duplicating the sampling process. Additionally, we incorporate several architectural optimizations over existing designs to further enhance speed, area efficiency, and resource utilization. Experimental results demonstrate that Bi-SamplerZ achieves the lowest sampling latency to date among existing designs, benefiting from fine-grained pipeline optimization and efficient control coordination. Compared with the state-of-the-art full hardware implementations, Bi-SamplerZ reduces the sampling cycle count by 54.1\% while incurring only a moderate increase in hardware resource consumption, thereby achieving the best-known area-time product (ATP) for fully hardware-based sampler designs. In addition, to facilitate comparison with existing works, we provide both ASIC and FPGA implementations. Together, these results highlight the suitability of Bi-SamplerZ as a high-performance sampling engine in standardized post-quantum cryptographic systems such as Falcon.

Figures

Figures reproduced from arXiv: 2505.24509 by the authors.

Figure 1
Figure 1. Overview of the SamplerZ functional decomposition and datapath connections. [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. State Transfer Diagram of Bi-SamplerZ intermediate values that remain invariant across re￾jection loops are precomputed by the Pre samp and Bef loop modules. This setup minimizes redundant computations during the sampling loops. • NREG State (Intermediate Storage): Following preprocessing, the system enters the NREG (Normal Register) state. In this phase, key intermediate data, such as precomputed constants and part… view at source ↗
Figure 3
Figure 3. Tri-state gate-based logic for optimized BaseSampler [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

29 extracted references · 28 canonical work pages

  1. [23]

    Falconsign: An efficient and high-throughput hardware architecture for falcon signature generation,

    Y . Ouyang, Y . Zhu, W. Zhu, B. Yang, Z. Zhang, H. Wang, Q. Tao, M. Zhu, S. Wei, and L. Liu, “Falconsign: An efficient and high-throughput hardware architecture for falcon signature generation,” IACR Transactions on Cryptographic Hardware and Embedded Systems , vol. 2025, no. 1, pp. 203–226, Dec. 2024. [Online]. Available: https://tches.iacr.org/index.php...

    work page 2025

  2. [19]

    An efficient hardware/software co-design for falcon on low-end embedded systems,

    Y . Lee, J. Youn, K. Nam, H. H. Jung, M. Cho, J. Na, J.-Y . Park, S. Jeon, B. G. Kang, H. Oh, and Y . Paek, “An efficient hardware/software co-design for falcon on low-end embedded systems,” IEEE Access, vol. 12, pp. 57 947–57 958, 2024

    work page 2024

  3. [1]

    Efficient tensor network simulation of ibm’s largest quantum processors,

    S. Patra, S. S. Jahromi, S. Singh, and R. Or ´us, “Efficient tensor network simulation of ibm’s largest quantum processors,” Physical Review Research, vol. 6, no. 1, p. 013326, 2024

    work page 2024

  4. [2]

    Algorithms for quantum computation: discrete logarithms and factoring,

    P. W. Shor, “Algorithms for quantum computation: discrete logarithms and factoring,” inProceedings 35th annual symposium on foundations of computer science . Ieee, 1994, pp. 124–134

    work page 1994

  5. [3]

    A fast quantum mechanical algorithm for database search,

    L. K. Grover, “A fast quantum mechanical algorithm for database search,” in Proceedings of the twenty-eighth annual ACM sym- posium on Theory of computing , 1996, pp. 212–219

    work page 1996

  6. [4]

    A method for obtaining digital signatures and public-key cryptosystems,

    R. L. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digital signatures and public-key cryptosystems,” Com- munications of the ACM , vol. 21, no. 2, pp. 120–126, 1978

    work page 1978

  7. [5]

    A public key cryptosystem and a signature scheme based on discrete logarithms,

    T. ElGamal, “A public key cryptosystem and a signature scheme based on discrete logarithms,” IEEE transactions on information theory, vol. 31, no. 4, pp. 469–472, 1985

    work page 1985

  8. [6]

    Survey on asymmetric crypto- graphic algorithms in embedded systems,

    N. J. G. Saho and E. C. Ezin, “Survey on asymmetric crypto- graphic algorithms in embedded systems,” IJISRT, vol. 5, pp. 544–554, 2020

    work page 2020

Show all 29 references
  1. [7]

    L. Chen, L. Chen, S. Jordan, Y .-K. Liu, D. Moody, R. Peralta, R. A. Perlner, and D. Smith-Tone, Report on post-quantum cryptography. US Department of Commerce, National Institute of Standards and Technology . . . , 2016, vol. 12

    2016

  2. [8]

    Falcon: Fast-fourier lattice-based compact signatures over ntru,

    P.-A. Fouque, J. Hoffstein, P. Kirchner, V . Lyubashevsky, T. Pornin, T. Prest, T. Ricosset, G. Seiler, W. Whyte, Z. Zhang et al. , “Falcon: Fast-fourier lattice-based compact signatures over ntru,” Submission to the NIST’s post-quantum cryptography standardization process, vo...

    2018

  3. [9]

    On practical discrete gaussian samplers for lattice-based cryp- tography,

    J. Howe, A. Khalid, C. Rafferty, F. Regazzoni, and M. O’Neill, “On practical discrete gaussian samplers for lattice-based cryp- tography,” IEEE Transactions on Computers , vol. 67, no. 3, pp. 322–334, 2016

    2016

  4. [10]

    Area optimization of lightweight lattice-based encryption on reconfigurable hardware,

    T. P ¨oppelmann and T. G ¨uneysu, “Area optimization of lightweight lattice-based encryption on reconfigurable hardware,” in 2014 IEEE international symposium on circuits and systems (ISCAS). IEEE, 2014, pp. 2796–2799

    2014

  5. [11]

    Towards efficient discrete gaussian sampling for lattice-based cryptography,

    C. Du and G. Bai, “Towards efficient discrete gaussian sampling for lattice-based cryptography,” in 2015 25th International Con- ference on Field Programmable Logic and Applications (FPL) . IEEE, 2015, pp. 1–6

    2015

  6. [12]

    Towards practical lattice-based public-key encryption on reconfigurable hardware,

    T. P ¨oppelmann and T. G ¨uneysu, “Towards practical lattice-based public-key encryption on reconfigurable hardware,” in Interna- tional Conference on Selected Areas in Cryptography . Springer, 2013, pp. 68–85

    2013

  7. [13]

    Standard lattice- based key encapsulation on embedded devices,

    J. Howe, T. Oder, M. Krausz, and T. G ¨uneysu, “Standard lattice- based key encapsulation on embedded devices,” Cryptology ePrint Archive, 2018

    2018

  8. [14]

    Merge-exchange sort based discrete gaussian sampler with fixed memory access pattern,

    S. Tian, W. Wang, and J. Szefer, “Merge-exchange sort based discrete gaussian sampler with fixed memory access pattern,” in 2019 International Conference on Field-Programmable Technol- ogy (ICFPT). IEEE, 2019, pp. 126–134

    2019

  9. [15]

    Efficient, flexible, and constant-time gaussian sampling hardware for lattice cryptogra- phy,

    E. Karabulut, E. Alkim, and A. Aysu, “Efficient, flexible, and constant-time gaussian sampling hardware for lattice cryptogra- phy,” IEEE Transactions on Computers, vol. 71, no. 8, pp. 1810– 1823, 2021

    2021

  10. [16]

    Post-quantum sig- natures on risc-v with hardware acceleration,

    P. Karl, J. Schupp, T. Fritzmann, and G. Sigl, “Post-quantum sig- natures on risc-v with hardware acceleration,” ACM Transactions on Embedded Computing Systems, vol. 23, no. 2, pp. 1–23, 2024

    2024

  11. [17]

    Falcon—a flexible architecture for accelerating cryptography,

    K. Kiningham, P. Levis, M. Anderson, D. Boneh, M. Horowitz, and M. Shih, “Falcon—a flexible architecture for accelerating cryptography,” in 2019 IEEE 16th International Conference on Mobile Ad Hoc and Sensor Systems (MASS) . IEEE, 2019, pp. 136–144

    2019

  12. [18]

    A hardware-software co-design for the discrete gaussian sampling of falcon digital signature,

    E. Karabulut and A. Aysu, “A hardware-software co-design for the discrete gaussian sampling of falcon digital signature,” in 2024 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) , 2024, pp. 90–100

    2024

  13. [20]

    Fal- con takes off-a hardware implementation of the falcon signature scheme,

    M. Schmid, D. Amiet, J. Wendler, P. Zbinden, and T. Wei, “Fal- con takes off-a hardware implementation of the falcon signature scheme,” Cryptology ePrint Archive , 2023

    2023

  14. [21]

    Rvce-fal: A risc-v scalar-vector custom extension for faster falcon digital signature,

    X. Yu, Y . Sun, Y . Zhao, H. Kuang, and J. Han, “Rvce-fal: A risc-v scalar-vector custom extension for faster falcon digital signature,” in 2024 Design, Automation & Test in Europe Conference & Exhibition (DATE), 2024, pp. 1–6

    2024

  15. [22]

    Enhancing risc-v vector extension for efficient applica- tion of post-quantum cryptography,

    Y . Zhao, H. Kuang, Y . Sun, Z. Yang, C. Chen, J. Meng, and J. Han, “Enhancing risc-v vector extension for efficient applica- tion of post-quantum cryptography,” in 2023 IEEE 34th Interna- tional Conference on Application-specific Systems, Architectures and Processors (ASAP) ....

    2023

  16. [24]

    Hardware accelerators for digital signature algorithms dilithium and falcon,

    L. Beckwith, D. T. Nguyen, and K. Gaj, “Hardware accelerators for digital signature algorithms dilithium and falcon,” IEEE Design & Test, 2023

    2023

  17. [25]

    Crystals-dilithium,

    V . Lyubashevsky, L. Ducas, E. Kiltz, T. Lepoint, P. Schwabe, G. Seiler, D. Stehl ´e, and S. Bai, “Crystals-dilithium,” Algorithm Specifications and Supporting Documentation , 2020

    2020

  18. [26]

    The sphincs+ signature framework,

    D. J. Bernstein, A. H ¨ulsing, S. K ¨olbl, R. Niederhagen, J. Rijn- eveld, and P. Schwabe, “The sphincs+ signature framework,” in Proceedings of the 2019 ACM SIGSAC conference on computer and communications security , 2019, pp. 2129–2146

    2019

  19. [27]

    Crystals-kyber: a cca-secure module-lattice-based kem,

    J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V . Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler, and D. Stehl ´e, “Crystals-kyber: a cca-secure module-lattice-based kem,” in 2018 IEEE European Symposium on Security and Privacy (EuroS&P) . IEEE, 2018, pp. 353–367

    2018

  20. [28]

    13. various techniques used in connection with random digits,

    J. V on Neumann, “13. various techniques used in connection with random digits,” Appl. Math Ser , vol. 12, no. 36-38, p. 3, 1951

    1951

  21. [29]

    An efficient and parallel gaussian sampler for lat- tices,

    C. Peikert, “An efficient and parallel gaussian sampler for lat- tices,” in Annual Cryptology Conference . Springer, 2010, pp. 80–97. IEEE TRANSACTIONS ON EMERGING TOPICS IN COMPUTING, VOL. 18, NO. 9, SEPTEMBER 2020 13 Binke Zhao is currently an undergraduate student in the Sc...

    2019

Pith tools

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