{"id":"e11cacbe-90fb-4e6e-b9f4-e4860760a21c","arxiv_id":"2501.13799","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":6,"one_line_summary":"Rudraksh is a compact MLWE-based KEM with n=64, ell=9, q=7681, using ASCON as its hash and XOF, providing over 100 bits of Core-SVP security and a low-area FPGA implementation.","lead":"The authors propose Rudraksh, a new lightweight post-quantum key-encapsulation mechanism based on module learning with errors, designed for resource-constrained IoT devices. It uses a small polynomial size and the ASCON lightweight cipher to achieve the smallest FPGA area among comparable KEMs while targeting NIST level 1 security.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Security claim hinges on a single LWE estimator for an unusual (n=64, ℓ=9) parameter set with only a 4-bit margin; an independent estimate is needed to confirm the 100-bit Core-SVP bound.","rationale":"Read in good faith, the paper is a hardware-driven design-space exploration, and its area claims from Table 5 are supported by per-module resource tables and comparisons to prior implementations. The central claim that actually bears the weight is security: 'CCA secure with more than 100-bit Core-SVP post-quantum security and NIST level I.' The weakest link is the single Leaky-LWE estimator for a parameter set far from the well-tested Kyber point (n=256, ℓ=2): n=64, ℓ=9. The margin is only 4 bits. This is not an accusation that the estimator is wrong; it is a request for an independent estimate before a new KEM is adopted. The reader identified the same weakness. The absence of open-source code and test vectors makes the hardware area numbers harder to reproduce but does not weaken the security concern. If the independent estimator confirms ≥100 bits, the conditional verdict can be upgraded; if not, the security overclaim should be corrected.","tokens_in":34420,"tokens_out":14650,"duration_ms":139774,"concrete_test":"Independently re-estimate the exact Rudraksh MLWE instance with the standard lattice-estimator (Albrecht–Player–Scott or the Ducas lattice-estimator), using the precise parameters: module dimension 9, ring degree 64, modulus 7681, and CBD η=2 secret/error (support {-2,-1,0,1,2}, σ=1) with m=576. Record the quantum Core-SVP cost and compare it with the Leaky-LWE number (104). Then, optionally, rerun the Leaky-LWE estimator with the exact CBD distribution rather than its Gaussian approximation. If both independent runs report ≥100 bits, the concern is resolved; if either reports <100 bits, the NIST-level-I/Core-SVP claim should be revised.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.6 reports Rudraksh (KEM-poly64) as having 104-bit quantum Core-SVP from the Leaky-LWE estimator [DSDGR20], only 4 bits above the 100-bit threshold claimed in the abstract. Because the same estimator was used to search the parameter space (n=64, ℓ=9, q=7681, CBD η=2), any systematic optimism in that tool—particularly at this unusual point with very small polynomial degree and large module rank—translates directly into an overclaim of NIST level I. No independent estimator, security reduction tailored to the scheme, or test vectors are provided, and the abstract's wording also conflates the heuristic Core-SVP figure with CCA security of the KEM. If the true cost is even a few bits lower (e.g., 96–99 bits), the headline security claim fails while the hardware-area results remain valid.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Rudraksh, an MLWE-based KEM with polynomial degree n=64, module rank ℓ=9, modulus q=7681, centered-binomial parameter η=2, and message encoding B=2. The parameter set is obtained from a hardware-driven exploration of polynomial size, modulus structure, polynomial multiplication, and secret/error distribution. The KEM follows a FrodoKEM-style Fujisaki–Okamoto transform and replaces Keccak with ASCON for hashing, XOF, and PRF generation. A compact FPGA implementation on Virtex-7 and Artix-7 is presented, using a single DSP and three 18K BRAMs, with claimed 2.9–3× lower area than the compact Kyber implementation of [HLLM24], higher frequency than high-throughput Kyber designs, and 104-bit quantum Core-SVP security.","tokens_in":34650,"tokens_out":6599,"duration_ms":63439,"significance":"If the security estimate is independently confirmed and the CCA claim is backed by a precise theorem, Rudraksh would be a useful data point for lightweight post-quantum KEMs: the hardware results show substantial LUT/FF/BRAM/DSP reductions versus prior Kyber implementations, and the use of ASCON as a lightweight hash/XOF is an interesting contribution. The paper contains a detailed hardware architecture, careful scheduling, and extensive comparisons, which are valuable. However, the paper does not ship test vectors, source code, or a machine-checked proof; the security estimate is reported as a single number from one estimator, the failure probability is stated without derivation, and the CCA-security claim is asserted by reference to existing FO constructions rather than proved for the exact scheme. These gaps are load-bearing for the headline claims and need to be addressed before the results can be fully accepted.","major_comments":[{"comment":"The 104-bit quantum Core-SVP estimate for KEM-poly64 has only a 4-bit margin over the claimed 100-bit NIST-level-I threshold, and it comes solely from the Leaky-LWE estimator [DSDGR20], which was also used to search the parameter space. Because the scheme operates at n=64, ℓ=9, a regime far from Kyber's n=256, ℓ=2, an estimator bias of even a few bits would invalidate the headline security claim. Please provide independent security estimates using at least one additional estimator with several attack models (e.g., the lattice-estimator), and either confirm the 104-bit number or adjust the parameter set/claim. The abstract should also distinguish the heuristic Core-SVP bound from the CCA-security property.","section":"§3.6, Table 1, Abstract"},{"comment":"The CCA-security claim is asserted by stating that the KEM 'closely follows' FrodoKEM and by citing [JZC+18], but no concrete security theorem is given for the exact construction in Fig. 3. Please state the theorem, including the QROM assumptions on G and H, the correctness bound δ required by the FO variant, and the role of Arrange_msg/Original_msg encoding. Verify explicitly that the failure probability computed in §3.6 satisfies the required δ and that instantiating G and H with ASCON is compatible with the random-oracle modeling. Without this, the abstract's claim of chosen-ciphertext security is not supported by the manuscript.","section":"§2.3, Fig. 3"},{"comment":"The claim that Rudraksh 'currently requires the least area among the PQC KEMs of similar security' is based on ENS values computed across different FPGA families (Virtex-7/Artix-7 versus Kintex-7, Zynq UltraScale+, Virtex-E) and, presumably, different synthesis tool settings. Please justify the cross-platform normalization or qualify the claim to the reported boards and toolchains; as presented, the 2.9–3× area improvement over [HLLM24] is not directly supported because the two designs are measured on different FPGA families.","section":"§5.2, Table 5"},{"comment":"The failure probability of 2^-128 for KEM-poly64 is stated without derivation, and no script or table of decryption-noise statistics is provided. Since the FO-based CCA transform in §2.3 depends on an explicit correctness bound δ, please provide the exact computation or a reproducible script for the decryption-noise distribution of the chosen parameters, including the effect of the B=2 message encoding and the compression parameters p and t.","section":"§3.6, §3.1"}],"minor_comments":[{"comment":"The statement that 'the implementation of Rudraksh is constant-time' is too broad, because the rejection sampler for the public matrix is explicitly variable time; please specify that all secret-dependent operations are constant-time and identify which operations are covered.","section":"§4.6, §6"},{"comment":"There is a typo in 'Montogomery' (should be 'Montgomery'), and Algorithm 1 would benefit from a short derivation or proof of the shift-and-add reduction identities, since it is a new building block.","section":"§4.2"},{"comment":"The KEM in Fig. 3 is called 'closely follows' FrodoKEM, but the encoding, compression, and NTT-domain operations differ; please add a precise pointer to the FrodoKEM specification and list the differences so that the claimed relationship is checkable.","section":"§2.3, Fig. 3"},{"comment":"Figure 5 has no visible axis labels or legend; the caption should explain what the arrows and colors represent and how the 'optimal point' is selected.","section":"§3.6, Fig. 5"},{"comment":"The ASCON-versus-Keccak comparison in Table 4 reports only LUT/FF and ENS; reporting the same comparison on the same FPGA and toolchain would strengthen the causal claim that replacing Keccak with ASCON is responsible for the area reduction.","section":"§5.1, Table 4"},{"comment":"The abstract's '~3× improvement' is stated for area versus [HLLM24], but Table 5 reports a 2.9× ENS reduction; the wording should be made consistent.","section":"Abstract, §5.2"}],"recommendation":"major_revision","confidential_remarks":"For the editor: the paper is within the journal's scope and the hardware engineering is solid, but the headline security claims are not yet supported to the standard expected for a new KEM. I would like to see independent security estimates and a precise CCA theorem before reconsidering. I also note the absence of test vectors and source code, which is unusual for a scheme proposal and limits reproducibility."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is a solid hardware engineering paper with a genuine novel combination: the first lattice KEM to replace Keccak with ASCON as hash and XOF, and a careful exploration of small polynomial sizes for lightweight implementations. The FPGA results are credible, and the area savings compared to compact Kyber implementations are real. The design space exploration (n=32/64/128, varying module ranks, CBD parameters) is thorough, and the hardware architecture—reconfigurable butterfly, shift-and-add reduction, careful memory organization, runtime secret generation—shows serious craft.\n\nThe main thing to scrutinize is the security margin, which is thinner than the abstract suggests. The 104-bit Core-SVP estimate comes from a single tool (Leaky-LWE) at a very unusual parameter point: polynomial size 64, module rank 9. The margin above the claimed 100-bit NIST-I threshold is only 4 bits. If that estimator is even slightly optimistic for this parameter regime—small polynomials, large rank—the headline security claim fails. I'd want a second independent estimate (e.g., the standard lattice-estimator) or a concrete attack analysis before trusting the security level. The paper also conflates Core-SVP heuristic with CCA security; the FO transform is cited but not stated as a theorem, which is acceptable practice but should be explicit.\n\nA related weakness is the lack of test vectors or open-source code. For a scheme meant to be adopted, that's a reproducibility gap.\n\nMinor issues: the comparison table mixes FPGAs and security levels, and the 'least area' claim is strong given that some competitors run on different platforms or older process points. They do flag this, but it tempers the result.\n\nOverall: this is a genuine engineering contribution that deserves peer review. The hardware results are valuable even if the security level needs independent confirmation. For a journal or conference version, I'd ask for a second security estimate, a clear statement of the FO-based CCA theorem, and test vectors. I wouldn't cite it in my own work until that's done, but I'd willingly referee a revised version.","headline":"Serious hardware-driven KEM paper with a real ASCON-based design and credible area savings, but the security claim rests on a 4-bit margin from a single estimator.","tokens_in":35165,"tokens_out":1899,"would_cite":false,"duration_ms":20285,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["94A60"],"pacs":[],"model":"deepseek-v4-flash","headline":"Rudraksh, a 64-coefficient module-LWE KEM, claims level-I post-quantum security at one-third the FPGA area of compact Kyber.","keywords":["post-quantum cryptography","key-encapsulation mechanism","module-LWE","lightweight cryptography","FPGA implementation","ASCON","number theoretic transform","IoT security"],"falsifier":"Run the same MLWE instance through a second, independent core-SVP estimator (or a direct BKZ simulation with the same sieving cost model) and check whether the predicted bit security remains above 100; if any independent estimate falls below 100 bits, the central security claim fails. A second falsification path would be demonstrating a decryption failure rate above $2^{-100}$ on the claimed parameter set.","tokens_in":34258,"feed_emoji":"🔐","tokens_out":8497,"duration_ms":69589,"temperature":0.7,"pith_summary":"This paper sets out to establish that a key-encapsulation mechanism can be made genuinely lightweight for resource-constrained devices without sacrificing post-quantum security. It proposes Rudraksh, a module-LWE KEM built from 64-coefficient polynomials, a module rank of 9, modulus 7681, and a centered binomial error distribution, and claims more than 100 bits of Core-SVP post-quantum security with chosen-ciphertext security and failure probability below $2^{-100}$. The motivation is that current lattice KEMs, designed for security and speed, are too heavy for wireless sensors and IoT peripherals, and that earlier lightweight proposals stopped short of CCA security or fell below 100-bit security. If the claims hold, Rudraksh would be the smallest-area post-quantum KEM at its security level, roughly a threefold area reduction relative to the area-optimized Kyber implementation it compares against, while running at substantially higher clock frequency.","feed_headline":"Rudraksh KEM claims level-I security at one-third Kyber's FPGA area","feed_subtitle":"ASCON and 64-coefficient polynomials shrink a quantum-safe KEM to fit constrained devices.","key_machinery":"The carrying mechanism is a hardware-driven parameter search over the module-LWE design space that fixes small power-of-two polynomial sizes ($n=32,64,128$) and searches module rank, modulus, and error width to minimize hardware resources while keeping estimated security above 100 bits and failure probability below $2^{-100}$; the chosen point is $n=64,\\ell=9,q=7681,\\eta=2$. Around that point the paper builds a reconfigurable single-butterfly unit that performs NTT, INTT, pointwise multiplication, compression, and encoding/decoding with a shift-and-add modular reduction tailored to $q=7681$, and an ASCON-based sponge that supplies all pseudorandom bits, hashes, and XOF functions. Synchronous scheduling lets ASCON's 64-bit squeeze output feed the NTT in lockstep, enabling runtime secret generation and reducing memory to three 18K BRAMs. The comparison metric that carries the area claims is the equivalent number of slices (ENS), a normalized gate-area estimate used to compare FPGA implementations across vendors.","core_discovery":"On its own terms, the paper's central discovery is the parameter and hardware co-design of Rudraksh: an MLWE KEM with polynomial size $n=64$, module rank $\\ell=9$, prime modulus $q=7681$, and centered binomial distribution $\\eta=2$ that, according to the Leaky-LWE estimator, offers more than 100 bits of Core-SVP post-quantum security and belongs to the AES-128-equivalent level-I category while remaining CCA secure. The design replaces Keccak with the lightweight sponge ASCON for hashing and pseudorandom generation, uses complete NTT multiplication with a shift-and-add modular reduction, stores only two 18K BRAMs for NTT and one for the public key, and reports FPGA implementations on Virtex-7 and Artix-7 whose equivalent slice counts are lower than those of previously published Kyber, Saber, NewHope, Frodo, and NTRU implementations at comparable security. The paper states that Rudraksh 'currently requires the least area among the PQC KEMs of similar security,' with about a $3\\times$ area reduction versus the area-optimized Kyber of [HLLM24], $63\\%$-$76\\%$ higher frequency than high-throughput Kyber, and roughly $2\\times$ better time-area product than the compact Kyber of [ZLZ+22].","pith_inferences":["An independent lattice-security estimate for the specific $n=64,\\ell=9,q=7681,\\eta=2$ instance would be the fastest check on the central claim; the paper relies on a single estimator, and small-polynomial/large-module-rank regimes are exactly where estimator optimism is most plausible.","The same design recipe—small polynomial size, large module rank, lightweight sponge, shift-and-add reduction—could plausibly be transplanted to NTRU-based KEMs or hybrid LWE/LWR schemes, and to lattice signatures, but those extensions are not demonstrated here.","Because ASCON currently offers at most 128-bit security, replacing it with Keccak for higher security levels would erase part of the area advantage; the scheme's lightweight benefit is thus specific to level-I (AES-128-equivalent) targets.","The paper's own side-channel discussion suggests a masked Rudraksh would likely be cheaper than masked Kyber because ASCON is cheaper to mask than Keccak, but the authors explicitly leave this claim unverified."],"forward_implications":["If the security estimate holds, lightweight IoT endpoints can run quantum-resistant key establishment with roughly one-third the FPGA area of the most area-optimized Kyber implementation, making the transition to post-quantum cryptography practical on sensors and peripherals.","Swapping Keccak for ASCON as the hash and pseudorandom source demonstrates a standardized lightweight sponge can serve a lattice KEM, reducing LUT and flip-flop counts without making the XOF the operational bottleneck.","The parameter choice shows the unexplored module-lattice region (small $n$, larger $\\ell$) contains viable operating points, so future KEMs need not default to $n=256$ polynomials to reach level-I security.","CCA security with failure probability at most $2^{-100}$ and constant-time arithmetic keeps Rudraksh compatible with Fujisaki-Okamoto-style transforms and with timing side-channel resistance, which earlier lightweight lattice proposals lacked.","The ability to generate and transmit one polynomial at a time supports interleaved communication and computation, trading total bandwidth for a lower instantaneous bandwidth requirement in gateway-peripheral settings."],"supporting_citations":[{"why":"Leaky-LWE estimator; supplies the Core-SVP security estimates that underpin the more-than-100-bit and level-I claims.","marker":"[DSDGR20]"},{"why":"CRYSTALS-Kyber specification; the reference parameter set and design template the authors keep 'Kyber-esque' and the main baseline for security and comparison.","marker":"[ABD+21]"},{"why":"Area-optimized Kyber FPGA implementation; baseline for the roughly 3x area reduction and the 'least area' comparison.","marker":"[HLLM24]"},{"why":"ASCON lightweight authenticated encryption and hash family; replacement for Keccak that provides the XOF, PRF, and hash functions in Rudraksh.","marker":"[DEMS12]"},{"why":"Fujisaki-Okamoto-style transform; gives the IND-CCA security conversion and failure-probability requirement used for the KEM.","marker":"[HHK17]"},{"why":"NTT multiplication and k-reduction method; foundation for the reconfigurable butterfly and the shift-and-add reduction.","marker":"[LN16]"},{"why":"Compact Kyber hardware implementation; comparison baseline and the Keccak area numbers used to justify the ASCON swap.","marker":"[XL21]"},{"why":"Compact Kyber implementation from HPEC 2022; baseline for the time-area-product improvement claim.","marker":"[ZLZ+22]"},{"why":"Keccak sponge; the module whose area and state size motivate replacing it with ASCON.","marker":"[BDPV13]"},{"why":"Hardware implementations of the MLWR-based Scabbard KEMs (Espada, Sable, Florete); comparison points for the least-area claim among similar-security KEMs.","marker":"[KNK+24]"}],"fun_headline_variants":["Rudraksh KEM: one-third Kyber's area, level-I secure","Lightweight MLWE KEM cuts FPGA area 3x vs Kyber","ASCON-based KEM uses 64-coefficient polynomials for IoT","Post-quantum KEM Rudraksh fits constrained devices","Rudraksh: compact PQC KEM with 100-bit security"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The security claim rests entirely on what one software estimator predicts for an unusual lattice instance (64-coefficient polynomials, a 9-by-9 module structure, modulus 7681, and a narrow error distribution), with no independent check that the prediction is not optimistic.","fun_headline_variants_meta":{"raw":{"variants":["Rudraksh KEM: one-third Kyber's area, level-I secure","Lightweight MLWE KEM cuts FPGA area 3x vs Kyber","ASCON-based KEM uses 64-coefficient polynomials for IoT","Post-quantum KEM Rudraksh fits constrained devices","Rudraksh: compact PQC KEM with 100-bit security"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000197,"raw_usage":{"total_tokens":1492,"prompt_tokens":1200,"completion_tokens":292,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":816,"completion_tokens_details":{"reasoning_tokens":190}},"tokens_in":816,"tokens_out":292,"duration_ms":3028,"temperature":1.0,"reasoning_tokens":190,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T15:36:04.929418+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same MLWE instance through a second, independent core-SVP estimator (or a direct BKZ simulation with the same sieving cost model) and check whether the predicted bit security remains above 100; if any independent estimate falls below 100 bits, the central security claim fails. A second falsification path would be demonstrating a decryption failure rate above $2^{-100}$ on the claimed parameter set.","supporting_citations":[],"review_version":1}