{"id":"996e010e-c8e0-4e85-ab16-69ae29200822","arxiv_id":"2508.11082","paper_version":1,"verdict":"UNVERDICTED","confidence":"LOW","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A constant-time CSIDH-512 hardware architecture performs a key exchange in about 515 ms on a 200 MHz FPGA and 591 ms on a 180 nm ASIC.","lead":"This paper describes a constant-time hardware design for the CSIDH post-quantum key exchange, with a pipelined arithmetic unit that speeds up 512-bit finite-field math. It reports what it calls the first public performance baseline for CSIDH on both FPGA and ASIC, though only the abstract was available for this review.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Constant-time claim may cover only the ALU; no evidence shows the isogeny walk's control flow or memory access is data-independent, so the headline security property is unverified.","rationale":"The reader's weakest assumption correctly identifies the most load-bearing concern: the abstract's constant-time claim covers the whole CSIDH key-generation, but only the ALU's fixed-latency operations are concretely described. This is not an internal inconsistency in the abstract; it is an unverified premise essential to the central security claim. Because the full text is unavailable, I cannot confirm whether the paper addresses this, and the reader's UNVERDICTED verdict with low confidence is appropriate. My proposed check would settle the concern if the design artifacts were released. The novelty/firstness claim is also hedged ('to our knowledge') and is not load-bearing for the correctness or security of the architecture. No ad hominem is intended; the concern is about the argument's evidence, not the authors' conduct.","tokens_in":1139,"tokens_out":2382,"duration_ms":30053,"concrete_test":"Obtain the RTL, netlist, or cycle-accurate simulation model and run two full key generations whose secret keys differ only in the number of isogeny steps performed in at least one direction (e.g., exponent vectors differing by one in one prime). Compare (a) total cycle count from start to completion and (b) the sequence of memory/BRAM addresses and FSM states at every cycle. If either differs, the constant-time claim is disproven. In addition, inspect the isogeny-walk FSM to verify that loop bounds and branch conditions are compile-time constants or explicitly padded with dummy operations so that control flow and address streams are independent of all secret inputs.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central advertised property is a 'constant-time CSIDH-512 design' (abstract). For CSIDH, constant-time operation requires the entire key-generation flow to have secret-independent execution time and memory-access patterns, not just the 512-bit field arithmetic. The class group action is normally implemented as a sequence of isogeny steps whose count and direction depend on a secret exponent vector. If the top-level FSM's loop bounds, branch decisions, or curve/memory indexing vary with those secret values, two different secret keys will produce distinguishable cycle counts or address traces, leaking the secret. The abstract describes a uniform ALU and a top-level FSM, but gives no statement, let alone proof, that the FSM's control flow is data-independent: there is no mention of fixed iteration counts for each prime, dummy isogeny evaluations, or address masking. If the authors only ensured the ALU has no secret-dependent timing (e.g., fixed 22-cycle multiplication and 87-cycle Montgomery), that is insufficient; data-dependent branching or memory access in the isogeny walk leaks even if every modular multiplication is constant-time. Thus the headline property rests on an unverified premise, and the performance figures could be accurate while the constant-time claim is false.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a hardware architecture for CSIDH-512 key generation, claiming to be the first comprehensive hardware study of CSIDH. The design uses a top-level FSM orchestrating a deeply pipelined ALU, with a 512x512-bit schoolbook multiplier completing in 22 cycles and a full Montgomery multiplication in 87 cycles. The abstract reports 1.03e8 FPGA cycles (515 ms at 200 MHz) and 1.065e8 ASIC cycles (591 ms at ~180 MHz), and asserts that the implementation is constant-time.","tokens_in":1269,"tokens_out":2110,"duration_ms":25116,"significance":"If the claims hold, this would be a valuable contribution: it provides concrete, cross-platform performance metrics for CSIDH-512, a protocol of strong post-quantum interest but notorious computational cost. The architectural choices are standard and plausible, and the arithmetic consistency of the cycle counts is sound. The main significance hinges on the constant-time claim, which is the central security property and is asserted but not supported in the abstract. The 'first public hardware metrics' framing is an important literature contribution if substantiated by a proper comparison with prior work.","major_comments":[{"comment":"The abstract's headline claim is a 'constant-time CSIDH-512 design.' Constant-time operation for CSIDH requires secret-independent execution time and memory-access patterns for the entire key-generation flow, including the isogeny walk: fixed loop bounds, dummy operations for skipped primes, and data-independent addressing. The abstract only describes a uniform ALU and a top-level FSM, with no mention of how secret-dependent branches or memory indexing are eliminated. Without this information, the constant-time claim is unverified, even if all arithmetic operations have fixed latency. Please state the protocol-level constant-time measures or explicitly scope the claim to the ALU only.","section":"Abstract"},{"comment":"The novelty assertions—'first comprehensive hardware study of CSIDH' and 'first public hardware performance metrics'—are load-bearing for the paper's contribution. The abstract provides no references or comparison to prior CSIDH hardware implementations (e.g., any existing FPGA or ASIC accelerators). To establish this as a baseline, the full paper must include a literature review and competitive positioning. Please add explicit comparison and citation.","section":"Abstract"}],"minor_comments":[{"comment":"The cycle counts are reported as '1.03×10^8' and '1.065×10^8' without stating whether these are per key generation or per full key exchange. Clarify the exact operation counted.","section":"Abstract"},{"comment":"Use '180 nm' rather than '180nm' for the ASIC process node.","section":"Abstract"},{"comment":"The abstract does not report hardware resource utilization (LUTs, FFs, BRAM, or ASIC area/power). For a hardware study, these are standard metrics and would strengthen the benchmark value.","section":"Abstract"}],"recommendation":"uncertain","confidential_remarks":"This is an abstract-only review, so the assessment is necessarily provisional. The constant-time claim and the novelty claims need substantive support in the full manuscript. I recommend a full review of the complete text, particularly the FSM/control-flow description and the side-channel analysis, before a decision can be made. The arithmetic consistency is fine, but the security claim is the crux."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things about this paper. First, the performance figures are concrete and internally consistent: 1.03e8 cycles at 200 MHz gives 515 ms on FPGA, and 1.065e8 cycles at ~180 MHz gives 591 ms on ASIC. The 22-cycle 512-bit multiplier and 87-cycle Montgomery multiplication are specific engineering results that, if the implementation is real, give the isogeny hardware community a useful baseline. Second, the central advertised property—constant-time CSIDH-512—is asserted but not supported in the abstract. That is the soft spot that matters.\n\nThe paper is an implementation study, and the specific numbers are new. A pipelined ALU with a parallelized schoolbook multiplier, Montgomery reduction, and a top-level FSM is a standard recipe, but the measured/simulated cycle counts for this particular architecture are not in the prior literature as far as the abstract tells us. The abstract's arithmetic checks out, which is a good sign for the engineering narrative.\n\nNow the soft spots, in proportion. The constant-time claim is load-bearing, and the abstract gives no evidence for it. For CSIDH, constant-time means the whole key-generation flow—the class group action, the isogeny walk—must execute in secret-independent time and with data-independent memory access. A constant-time ALU only covers the field arithmetic. The abstract mentions a top-level FSM but says nothing about fixed iteration counts, dummy isogeny evaluations, or address masking. If the FSM's loop bounds or branches depend on the secret exponent vector, the cycle counts would leak regardless of the uniform multiplication time. The stress-test note lands on this: the abstract's own words do not rule it out.\n\nThere are two smaller issues. The 'first comprehensive hardware study' / 'first public metrics' claim is hedged with 'to our knowledge,' but it still sits uneasily with existing isogeny hardware literature; the authors should calibrate that. And there is no mention of HDL or measured traces, so reproducibility is limited from the abstract alone. The full text may address all of this, but we only have the abstract.\n\nWho gets value from this: hardware researchers working on isogeny-based PQC who want a reference point for cycle counts and platform trade-offs. It deserves a serious referee if the full text shows evidence about the full isogeny walk—not just the ALU—and ideally ships or links to the hardware description. If that evidence is missing, the authors should soften the constant-time claim. I'd send it to review, but the reviewer should be told to focus on the gap between ALU-level constant time and protocol-level constant time.","headline":"Concrete CSIDH-512 hardware numbers that are internally consistent, but the headline constant-time claim is unverified because the abstract says nothing about the isogeny walk's control flow or memory access.","tokens_in":831,"tokens_out":878,"would_cite":false,"duration_ms":26225,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A hardware architecture for the post-quantum CSIDH key-exchange protocol claims constant-time operation, completing key generation in about half a second on both FPGA and ASIC.","keywords":["CSIDH","post-quantum cryptography","isogeny-based key exchange","constant-time implementation","FPGA","ASIC","hardware accelerator","Montgomery multiplication"],"falsifier":"Run the same hardware design with different secret keys but identical public inputs on an FPGA and measure power, electromagnetic emanations, or instruction-cycle counts; if any secret-dependent variation appears in the timing or power trace of the full key-generation flow, the constant-time claim is falsified.","tokens_in":910,"feed_emoji":"🔐","tokens_out":3367,"duration_ms":33808,"temperature":0.7,"pith_summary":"This paper aims to show that CSIDH-512, a post-quantum key-exchange protocol built on isogenies between supersingular elliptic curves, can be implemented in dedicated hardware that runs in constant time. It reports what the authors believe to be the first public hardware performance baseline for CSIDH, using a top-level finite-state machine to drive a deeply pipelined arithmetic unit. On a Xilinx Zynq UltraScale+ FPGA the design runs at 200 MHz and generates one key in 515 ms; on a 180 nm ASIC it runs at about 180 MHz and generates a key in 591 ms. If the claims hold, this gives the field a concrete reference point for how fast a side-channel-hardened CSIDH accelerator can be.","feed_headline":"CSIDH key exchange runs in 515 ms on a constant-time core","feed_subtitle":"A 512-bit post-quantum key-exchange accelerator reports 1.03e8 cycles per key on FPGA and ASIC.","key_machinery":"The central object is a top-level finite-state machine (FSM) that controls a deeply pipelined arithmetic logic unit (ALU) for 512-bit finite-field operations. Within the ALU, a parallelized schoolbook multiplier does the heavy lifting: it completes a 512x512-bit multiplication in 22 clock cycles, enabling a Montgomery modular multiplication in 87 cycles. The FSM sequences the CSIDH class-group walk so that the entire key-generation run is meant to be data-independent in time.","core_discovery":"The paper's central claim is that a constant-time CSIDH-512 accelerator is feasible with a unified architecture on both FPGA and ASIC, and that its performance can be captured in concrete cycle counts. The architecture centers on a deeply pipelined arithmetic logic unit whose parallelized schoolbook multiplier completes a 512x512-bit product in 22 clock cycles and a full Montgomery modular multiplication in 87 cycles. The complete key-generation flow, orchestrated by a top-level finite-state machine, requires 1.03e8 clock cycles on the FPGA and 1.065e8 on the ASIC, yielding 515 ms and 591 ms latencies respectively. The authors position these numbers as the first public hardware performance m","pith_inferences":["If the constant-time guarantee holds only at the arithmetic level and not for the secret-dependent exponent walk, the reported figure would not reflect the true security of the complete protocol; a full side-channel evaluation would settle this.","The 22-cycle schoolbook multiplication suggests that the bottleneck for CSIDH may shift from field multiplication to the number and cost of isogeny evaluations, so algorithmic reductions in the class-group action could yield larger gains than further multiplier tuning.","One could extend the approach to other security levels or to other isogeny protocols, reusing the pipelined field arithmetic while changing only the walk-control FSM.","A direct comparison of this hardware result against a state-of-the-art constant-time software implementation would quantify the speedup contributed by the pipelined ALU; the abstract does not provide that comparison."],"forward_implications":["CSIDH-512 fits in hardware with a single unified architecture for both FPGA and ASIC, so one design can serve prototyping and production targets.","A 512x512-bit schoolbook multiplication in 22 cycles makes Montgomery modular multiplication in 87 cycles a practical building block for isogeny-based accelerators.","The reported 1.03e8 cycles per key generation gives other groups a concrete headline number to beat at similar security levels.","The 515 ms and 591 ms latency figures indicate that one-time key generation for CSIDH-512 is not prohibitively slow for some real-time applications.","These metrics can serve as a baseline for comparing future improvements to isogeny walks, field arithmetic, or pipeline design."],"supporting_citations":[],"fun_headline_variants":["First constant-time CSIDH hardware: 515 ms keygen on FPGA","CSIDH accelerator hits 515 ms keygen in constant-time silicon","Unified CSIDH ALU: 22-cycle 512-bit multiply, 87-cycle Montgomery","First FPGA/ASIC CSIDH benchmark: 515 ms and 591 ms keygen","Constant-time CSIDH core: 1.03e8 cycles per keygen"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"The constant-time property must hold for the entire isogeny walk—secret-dependent branching, memory-access patterns, and carry handling—not just for the field arithmetic, and the abstract does not present analysis showing that.","fun_headline_variants_meta":{"raw":{"variants":["First constant-time CSIDH hardware: 515 ms keygen on FPGA","CSIDH accelerator hits 515 ms keygen in constant-time silicon","Unified CSIDH ALU: 22-cycle 512-bit multiply, 87-cycle Montgomery","First FPGA/ASIC CSIDH benchmark: 515 ms and 591 ms keygen","Constant-time CSIDH core: 1.03e8 cycles per keygen"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000766,"raw_usage":{"total_tokens":3289,"prompt_tokens":857,"completion_tokens":2432,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":601,"completion_tokens_details":{"reasoning_tokens":2331}},"tokens_in":601,"tokens_out":2432,"duration_ms":16160,"temperature":1.0,"reasoning_tokens":2331,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T20:09:38.682320+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same hardware design with different secret keys but identical public inputs on an FPGA and measure power, electromagnetic emanations, or instruction-cycle counts; if any secret-dependent variation appears in the timing or power trace of the full key-generation flow, the constant-time claim is falsified.","supporting_citations":[],"review_version":1}