PaperlayerView exact revision on arXiv

Source-linked AI summary

AI-Assisted Design of a Post-Quantum Cryptographic Accelerator: A Deployed-Silicon Case Study

Jungmin Park, Eunha Kim, Wooseop Kim, Seongjoon Cho, Byungho Cha

arXiv:2609.04058v1cs.CRcs.AR

TL;DR

PQC hardware must meet migration timelines, yet prior studies had not reported assistant reliability across a complete deployed cryptographic-system campaign. This paper uses an artifact-based validation gate and reports both campaign-level LLM outcomes and a byte-exact deployed accelerator with zero failures in its soak.

  • Problem

    Prior LLM-for-RTL studies did not report assistant reliability across phases of a real campaign through validated, hardened operation on deployed silicon.

    Source: §I · p. 1

  • Method

    An agentic LLM assistant drove a unified PQC accelerator campaign, with artifact acceptance based on byte-exact agreement against Python FIPS 203/204 references.

    Source: F. A Reusable Protocol for Other… · p. 4, §IX · p. 13

  • Results

    Across 232 logged experiments, success was 71.6%, with 77–85% for documentation and research versus 50–53% for synthesis and bring-up; the deployed baseline had zero failures in 779,945 checks.

    Source: §I · p. 2, §IX · p. 13

  • Takeaways & Limitations

    The validation gate judges artifacts rather than authors, making trust separable from who wrote the RTL.

    Source: §IX · p. 13

    The artifact had not undergone CAVP testing or FIPS 140-3 validation, and the deployed HRNG chain lacked formal entropy-source validation.

    Source: §VIII · p. 13

Abstract

from arXiv · show

Post-quantum migration is mandated on published timelines, and silicon that ships with a defect cannot be patched remotely. The standard acceptance gate cannot detect an entire class of ML-DSA defects. Signing resamples until a candidate meets its norm bounds, so the executed path varies with the message, whereas known-answer tests (KATs) sample fixed values and reach only the depths their seeds trigger. Our accelerator passed its full KAT regression while carrying a norm check that outran block-RAM latency, leaving each candidate's final coefficients unverified; the escape surfaced at reject-loop iteration 5. The blind spot lies in the instrument, not the engineer; care cannot remove it. We replace that gate. A byte-exact golden-reference oracle paired with randomized adversarial soak drives the rejection loop past any fixed vector, closing the gap: 301,343 data-dependent signings, zero escapes. Because the gate judges artifacts and never authors, trust becomes separable from authorship, making AI authorship an answerable question. We report 232 logged experiments in which an agentic large language model drove a unified ML-KEM-768 and ML-DSA-65 accelerator with on-chip key custody from RTL to PCIe bring-up on one Kintex-7 XC7K160T, shipped at 98.5% slice occupancy. Success was 71.6%, following a hardware-coupling gradient, 77-85% for documentation and research against 50-53% for synthesis and bring-up, which observability can explain: failure concentrates where corrective signals are physical-side only. That so unreliable an author produced an artifact byte-exact across all six FIPS operations -- its deployed baseline surviving the same 779,945-check zero-failure soak -- is the claim.

I. INTRODUCTION

The introduction presents an artifact-based validation gate for rejection-sampled ML-DSA hardware, then uses it to assess an agentic LLM’s role in building a deployed PQC accelerator. It reports both the deployed artifact’s validation results and a task-success gradient across the design campaign.

Motivation

  • ML-DSA signing resamples until norm bounds are met, so message-dependent execution paths exceed the reach of fixed-vector KATs; shipped silicon defects cannot be patched remotely.PQC migration is described as a scheduled compliance obligation, making hardware acceptance consequential.Source: §I · p. 1

C1. Validation construction

  • The full KAT regression missed BUG-IDE-037: block-RAM latency left the final one or two coefficients unchecked, and the defect surfaced at reject-loop iteration 5.Affected signatures failed verification; the defect was among eight catalogued classes, each caught by a validation layer the others miss.Source: §I · p. 1

Research gap

  • Prior LLM-for-RTL studies evaluated snippets, modules, or tool-in-the-loop flows, but none reported phase-by-phase assistant reliability across a deployed, hardened cryptographic system.The introduction contrasts LLM4PQC and Liao et al., which compared LLMs with HLS, with its broader campaign-level scope.Source: §I · pp. 1–2

Study scope

  • An agentic LLM assistant drove design, verification, synthesis, host-software development, silicon bring-up, and security hardening of the unified accelerator.The campaign logged 232 experiments on an XC7K160T over PCIe Gen2 ×8.Source: §I · pp. 1–2

Campaign constraints

  • The campaign faced binding area and timing limits alongside an observability problem: a stale command register could wedge DMA about once in 20 runs while the soak harness self-healed it.Timing recovery required a placement seed sweep; the assistant made a confident but incorrect diagnosis in ten logged episodes.Source: §I · p. 2

C1. Validation construction

  • The replacement gate paired a byte-exact golden-reference oracle with randomized adversarial soak, recording 301,343 data-dependent signings with zero escapes.The soak drives the rejection loop beyond any fixed vector’s reach, and the construction applies to ML-DSA hardware efforts regardless of authorship.Source: §I · pp. 1–2

C2. Hardware-coupling gradient

  • Across 232 logs, success was 77–85% for documentation and research versus 50–53% for synthesis and bring-up, with failures concentrated where corrective information was physically unobservable.The study covered 40 task categories and 76 milestones; the proposed remedy is to make the physical side readable.Source: §I · p. 2

C3. Silicon existence proof under binding constraints

  • All six FIPS operations were byte-exact, and deployed baseline v88 passed 779,945 checks with zero failures; the unified accelerator and custody HSM occupied 98.5% of slices.It combined ML-KEM-768 and ML-DSA-65 on one XC7K160T.Source: §I · p. 2

II. BACKGROUND

The background introduces the shared mathematical primitives behind ML-KEM-768 and ML-DSA-65, reviews LLM-assisted hardware design, and describes the assistant’s toolchain and persistent project context. The methodology depicts a validation spine, while the context system includes feedback and a roadmap whose effect on success is not claimed.

A. Preliminaries

  • ML-KEM-768 is a rank-3 Module-LWE key-encapsulation mechanism, while ML-DSA-65 is a Fiat–Shamir-with-aborts lattice signature; both share the polynomial-ring structure and Keccak primitive.The shared NTT form and Keccak permutation make resource sharing natural for the two schemes.Source: A. Preliminaries · p. 2

B. LLM-Assisted Hardware Design: A Brief Primer

  • Prior work showed LLMs generating Verilog, using simulation feedback, and assisting verification or security-sensitive RTL repair, but the paper reports no prior full-path deployed-system study with campaign-level outcomes.The full path includes RTL generation, synthesis, host software, live-hardware bring-up, and iterative hardening.Source: B. LLM-Assisted Hardware Design: A… · p. 2

III. METHODOLOGY: AN AGENTIC LLM-ASSISTED DESIGN LOOP

  • Figure 1 depicts candidates passing human review before climbing the byte-exact golden-reference validation spine.Byte-exact agreement with Python FIPS 203/204 references is the stated acceptance criterion for every artifact.Source: §III · p. 3

A. The Assistant and Its Toolchain

  • Claude Code supplied file-system and shell tools; the assistant used Verilog, Icarus simulation, Vivado synthesis and implementation, Python reference comparisons, and PCIe host libraries.A separate agent thread performed adversarial review of critical design premises.Source: A. The Assistant and Its Toolchain · p. 3

B. Context Architecture: The Persistent Markdown Stack

  • Four persistent context layers comprised project guidance, typed memory, specialist-agent definitions, and procedural skills; feedback files distilled failure lessons into reusable rules.The authors say this feedback layer carried the most methodological value and allowed work to resume after total context loss without re-teaching.Source: B. Context Architecture: The… · p. 3
  • A 76-entry milestone roadmap tracked the campaign through bring-up, custody, and productization, but its role is described as structural, with no claim that it raised per-task success.The fixed milestones extended through v1.0; later entries covered unanticipated work, and the campaign closed with FIPS-final firmware v89 and release v1.1.Source: B. Context Architecture: The… · p. 3

C. Experiment-Logging Discipline

The campaign logged significant work at experiment close and advanced artifacts through a staged byte-exact validation ladder. Human review and a reusable protocol governed the work, with transfer to other implementations remaining untested.

C. Experiment-Logging Discipline

  • Structured JSON logs recorded significant work at experiment close; the logs, milestone index, category mapping, and table-generation scripts are available from the authors.The logging schema, methodology template, and complete v89 hardware-validation transcript are supplementary material.Source: C. Experiment-Logging Discipline · p. 3

D. The Golden-Reference Validation Spine

  • The validation ladder progressed from byte-exact simulation to KAT, hardware byte-exact checks over PCIe, and adversarial soak, which caught a defect missed by earlier rungs.No RTL reached a hardware build without byte-exact agreement with the Python reference in simulation.Source: D. The Golden-Reference Validation Spine · pp. 3–4

E. Human-in-the-Loop Role

  • The developer posed tasks, reviewed and gated every generated artifact, supplied corrective feedback, chose rollbacks, and made all real hardware decisions.About 50% of edit-tracked generations needed a corrective edit.Source: E. Human-in-the-Loop Role · p. 4

F. A Reusable Protocol for Other Implementations

  • The reusable protocol requires byte-exact reference agreement for artifact acceptance and prescribes hardware-coupling-aware review, typed feedback, and promotion through every validation rung.Its transfer with a similar success profile is untested.Source: F. A Reusable Protocol for Other… · p. 4

G. The Methodology as a Reusable Template

The appendix describes a reusable repository template and reports results from a single 232-experiment campaign. Success varied across task categories with their ranked coupling to live silicon, but the association is descriptive and the corpus is limited.

G. The Methodology as a Reusable Template

  • The repository-skeleton template contains a project constitution, golden reference, typed-memory files, agent-role and skill scaffolds, and a JSON experiment-log schema.Only the constitution and reference are rewritten per target; remaining layers copy unchanged, while memory and role/skill files accrue as the project develops.Source: G. The Methodology as a Reusable… · p. 4

A. Corpus and Overall Success Rate

  • 71.6% of 232 logged experiments met their task acceptance criterion at close, after any in-experiment iteration and human edits.The corpus records 166 successes and 66 failures; abandoned or rolled-back outcomes count as failures.Source: A. Corpus and Overall Success Rate · p. 5
  • 166 logs record syntax_correct True, 107 simulation_pass True, and 106 synthesis_pass True; functional correctness passed in 118 of 127 logs containing that field.The syntax_correct count coincides with accepted logs by definition and is not an independent gate.Source: A. Corpus and Overall Success Rate · p. 5
  • Success is defined by meeting the task’s acceptance criterion at close, using functional correctness where an oracle exists and the applicable pass field otherwise.The 49.2% manual-edit rate measures intervention en route, not the success criterion itself.Source: A. Corpus and Overall Success Rate · p. 5

B. Success by Task Category

  • Success rates declined with the task ranking from documentation to integration/bring-up, with Spearman ρ ≈−0.83; the ranking reflects coupling to live silicon.The table covers success rates by task category across 232 experiments, and only documentation–synthesis/optimization intervals were disjoint.Source: B. Success by Task Category · p. 5, Table I · p. 5
  • The coupling–success pattern is descriptive, not a controlled measurement: the ranking is subjective, buckets are unequal and non-independent, and the corpus is n=1.The authors attach no significance test and cannot fully separate coupling from model quality.Source: B. Success by Task Category · p. 5
  • The ten task buckets coarse-grain 40 logged category labels by keyword, and per-bucket Wilson 95% intervals are wide at these sample sizes.Documentation’s interval is 73–92%, while synthesis/optimization’s is 37–68%.Source: B. Success by Task Category · p. 5

C. Iterations and One-Shot Rate

Most recorded tasks closed within a few generate–review–correct cycles, while human intervention extended beyond edits to rollbacks, hardware decisions, and artifact gating. The records measure these operator roles unevenly.

C. Iterations and One-Shot Rate

D. Human-in-the-Loop Rate and Footprint

  • Of 179 logs, 88 (49.2%) report at least one human correction; tagged interventions included 24 logic/RTL race corrections and 12 timing/placement adjustments.The largest correction classes were RTL logic/race, host-software, and timing/placement; correction counts span task types and are raw counts.Source: D. Human-in-the-Loop Rate and Footprint · p. 5
  • The measurable corrective-edit rate was 49.2%; worst-case missing-not-at-random bounds over all 232 logs were 37.9–60.8%, accounting for 53 unrecorded logs.Mean iterations were 2.12 among logs with recorded iteration counts.Source: D. Human-in-the-Loop Rate and Footprint · p. 5, C. Iterations and One-Shot Rate · p. 5
  • The human footprint also included 8 logged reverts, unlogged irreversible bitstream and timing-closure decisions, and task specification and artifact gating that were not measurable as a fraction.The operator wrote every prompt, gated every artifact entering the toolchain, and committed all changes.Source: D. Human-in-the-Loop Rate and Footprint · p. 6

E. Bug Taxonomy

The campaign catalogues instrument-specific defect detection, confident misdiagnoses, and task-dependent success, alongside measured productivity, efficiency, and accuracy. Its results include a 71.6% overall experiment success rate and a deployed artifact validated across six operations.

E. Bug Taxonomy

  • The 232-log bug taxonomy finds that each validation layer catches defect classes the others miss, including simulation-, KAT-, and synthesis-specific blind spots.Three defect families dominate the bring-up record and are analyzed separately.Source: E. Bug Taxonomy · p. 6

F. Ten Episodes of “Confidently Wrong, Then Corrected”

  • Ten episodes document confident but incorrect conclusions followed by correction; thematic coding of 232 logs yields eight lessons, including exact-string checks, timing-aware placement, adversarial review, and golden-reference simulation.One episode involved a FIFO diagnosis when approximately 1041 bytes remained in the C2H engine, not the character FIFO.Source: F. Ten Episodes of “Confidently Wrong,… · p. 6

G. Success Rate Over Time

  • The monthly trajectory is not an independent confirmation of the coupling gradient: live-hardware tasks were unavailable before the first PCIe bitstream, and model-version changes and phase effects remain confounds in this n=1 campaign.The bucket-level pattern favors a task-mix reading, but the listed confounds cannot be separated.Source: G. Success Rate Over Time · p. 6

H. Compute Cost: Token Consumption

  • 99.4% of processed tokens were prompt-cache reads and writes; the measured window included approximately 4.47 billion processed tokens and 21.6 million generated tokens.The campaign-order estimate of approximately 9 billion processed and 44 million generated tokens is extrapolated from the 49% activity window.Source: H. Compute Cost: Token Consumption · pp. 6–7

I. Measured Productivity, Efficiency, and Accuracy

  • 57.0% one-shot acceptance and a mean 2.12 iterations summarize efficiency; the assistant read approximately 207 times more tokens than it generated.The paper characterizes the compute cost as context rather than generation.Source: §I · p. 7
  • 71.6% overall experiment success, with 77–85% documentation/research versus 50–53% synthesis and bring-up, accompanied 6/6 byte-exact operations and a 779,945-check zero-failure soak.The reported productivity was one developer plus the assistant over approximately 5–6 months, with 232 logged experiments and a deployed accelerator plus HSM.Source: §I · p. 7

V. THE ARTIFACT AS EVIDENCE

The artifact is a deployed, unified ML-KEM and ML-DSA accelerator with on-chip key custody and an entropy subsystem. Its shipped v89 build fits the XC7K160T at 98.5% slice occupancy and closes timing with no failing endpoints.

V. THE ARTIFACT AS EVIDENCE

  • The artifact section identifies v88 as the frozen-corpus deployed baseline and v89 as the shipped release with FIPS-final wire formats.Full architectural exploration and side-channel analysis are out of scope.Source: §V · p. 7

A. Unified Architecture

  • A shared five-stage pipelined butterfly serves both schemes’ NTT layers, while one Keccak-f[1600] core serves the scheme FSMs and custody/DRBG functions.The Keccak core’s registered two-master mux added a command-bus cycle that caused an intermediate-build wrong-tag failure caught on hardware.Source: A. Unified Architecture · p. 7
  • The entropy subsystem combines off-die Am-241 quantum entropy with an on-die ring-oscillator TRNG, conditions it with SHA3-256, then seeds a SHAKE256 DRBG that time-shares Keccak.The deployed health tests are advisory, and internal-seed mode keeps the KeyGen seed from crossing PCIe.Source: A. Unified Architecture · p. 8, Figure 3 · p. 8
  • Private keys are generated, wrapped, and used on-die; only public material and wrapped blobs cross PCIe, while the full custody protocol and security analysis are out of scope.The host outside the die boundary is untrusted for key confidentiality.Source: A. Unified Architecture · p. 8, Figure 3 · p. 8

B. Resource Utilization

  • The FIPS-final conversion raised slice occupancy from 96.9% in v87 to 98.5% in shipped v89, with LUT-as-memory, BRAM, and DSP counts unchanged.The v89 conversion added approximately 4.2 k LUTs and 370 registers over v87.Source: B. Resource Utilization · p. 8, Table III · p. 8
  • All clock domains closed with 0 failing endpoints among 178,247, and the 500 MHz userclk1 domain set worst setup slack at +0.049 ns.Worst hold slack was +0.015 ns.Source: B. Resource Utilization · p. 8

C. Throughput and Latency

The section reports host-measured throughput and latency, details how a BRAM-latency blind spot escaped KAT testing, and compares the deployed system with prior accelerators. The comparison is qualified because its system-level and core-only latency figures are not directly comparable.

C. Throughput and Latency

  • The week-1 target of at least 1,000 encapsulations/s was met with headroom, and ML-KEM KeyGen and Decaps also exceeded 1,000 operations/s.Optimized AVX2 software latencies are below or around the PCIe round-trip floor, while ML-DSA signing is rejection-dependent.Source: C. Throughput and Latency · p. 8

D. BUG-IDE-037: The Methodology’s Key Catch

  • The norm scan’s final one or two coefficients arrived after the accept/reject decision because BRAM reads take two cycles; the failing vec76 reached reject-loop iteration 5.Its sole norm-violating coefficient was last in scan order; a spec-correct signer rejects that candidate and first accepts at iteration 8.Source: D. BUG-IDE-037: The Methodology’s Key… · p. 9
  • The fixed KAT vectors did not reach the message class that triggered the blind-spot iteration, so the regression passed despite affected signatures failing verification.The later fix extended the scans by the BRAM-latency margin and the failing vector then retested 20/20 byte-exact on hardware.Source: D. BUG-IDE-037: The Methodology’s Key… · p. 9
  • A 28,801.6-second hardware soak completed 779,945 checks with zero failures, including 301,343 data-dependent sign-from-vault-to-Verify operations; ML-KEM provision had only four checks.A separate C-library soak added 186,432 checks, also with zero failures.Source: D. BUG-IDE-037: The Methodology’s Key… · p. 9

E. Comparison with Prior Work

  • A0 is roughly an order of magnitude slower per operation than prior rows, but its PCIe end-to-end latency, lower clock, and serialized NTT differ from their accelerator-core measurements.The comparison notes that AVX2 software is below the PCIe round-trip floor and frames A0’s value as CPU offload and hardware key custody.Source: E. Comparison with Prior Work · p. 9, Table IV · p. 9

VI. THE PQC–PCIE BOARD IMPLEMENTATION

The implementation is a deployed PCIe board carrying an XC7K160T, with host transport and a compact register-and-stream protocol for the cryptographic operations. Its accelerator comparisons require care because this work reports system latency while comparator rows report core latency.

VI. THE PQC–PCIE BOARD IMPLEMENTATION

  • The section links board integration and bring-up to the campaign’s 50% integration/bring-up bucket and the May 2026 success dip to 41%.The board is identified as a deployed PCIe card with a complete host stack.Source: §VI · p. 9

A. Board and PCIe Subsystem

  • The deployed board pairs an XC7K160T with PCIe XDMA, one H2C and one C2H stream, and AXI4-Lite control registers across clock-domain crossings.The 500 MHz XDMA userclk1 domain closed between +0.041 and +0.049 ns.Source: A. Board and PCIe Subsystem · p. 9

Unified Kyber + Dilithium accelerators (closest comparators)

  • The comparator table’s A0 row is end-to-end system latency, whereas FPGA comparator rows are accelerator-core latency at approximately 2.7–3.75× higher clocks, so the figures are not directly comparable.A0’s reported operation latency includes host, PCIe Gen2 ×8, and DMA effects.Source: Table V · p. 10, Unified Kyber + Dilithium accelerators… · p. 10

B. Host–Device Protocol

  • The minimal protocol dispatches with a 3-bit opcode, streams inputs over H2C, and reads fixed-length results over C2H; ML-DSA Verify instead reports its result in STATUS[2].In internal-seed mode, KeyGen seed bytes drop to zero and custody provisioning returns a wrapped blob.Source: B. Host–Device Protocol · p. 10
  • Five operational disciplines encode logged silicon failures, including soft-reset plus idle polling before Verify, a warm-up burn-op, and PCIe FLR for wedged H2C recovery.The XDMA device admits one opener, so multi-client use goes through the pqcd daemon.Source: B. Host–Device Protocol · p. 10

C. The Bring-Up Record: Where the 50% Bucket Was Earned

The bring-up record shows how failures emerged at the RTL, host/RTL, and transport boundaries, while the product lineage culminated in a revalidated FIPS-final release. The supporting host stack and the corpus freeze define the scope of that record.

C. The Bring-Up Record: Where the 50% Bucket Was Earned

  • PCIe bring-up progressed from the first Gen2 ×8 build to all six operations FSM-complete, then reached byte-exactness at full back-to-back rate.The first byte-exact result followed fixes to X-initialized ROMs and Vivado BRAM dissolution.Source: C. The Bring-Up Record: Where the 50%… · p. 10
  • RTL handshake and compute-gap defects passed iverilog but failed on silicon; fixes used registered requests, sticky flags, or one-deep skid buffers.The failure families included readiness races, back-pressure pulses, target-switch duplication, and over-fetch.Source: C. The Bring-Up Record: Where the 50%… · pp. 10–11
  • Host, driver, DMA, and RTL faults produced identical boundary symptoms, so live-hardware differential A/B tests were needed to attribute failures.Three apparent RTL bugs were host-side; one apparent driver issue was RTL-behavioral.Source: C. The Bring-Up Record: Where the 50%… · p. 11
  • The transport wedge fix reduced failures from 24 to zero across 1,500 confirmation iterations, with all 12,825 operations byte-exact.The 500-iteration A/B first reduced wedges from 24 to one.Source: C. The Bring-Up Record: Where the 50%… · p. 11

D. Host Software Stack

  • The shipped host stack comprises Python and C99 libraries, a serializing daemon, an OpenSSL-3 provider, and byte-exact validation and soak suites.C/Python divergences helped localize transport bugs.Source: D. Host Software Stack · p. 11

E. Productization and Bitstream Lineage Beyond the Snapshot

  • Release v1.1’s v89 bitstream was revalidated on board with the full suite and adversarial soak, with zero failures and byte-identical FIPS-204 signatures.The release converted both schemes to final-standard encodings; external signatures were also verified directly.Source: E. Productization and Bitstream… · p. 11
  • The Section IV corpus freezes at 2026-06-26 on v88; later v1.1 is lineage evidence, not part of the analyzed corpus.Release v1.0 and its v88 update were counted in the frozen corpus.Source: E. Productization and Bitstream… · p. 11

VII. RELATED WORK

Prior LLM hardware work spans generation, tool feedback, and PQC hardware, but the cited efforts stop short of the deployed-silicon validation reported here. The paper also bounds its empirical claims by its single-operator study, device security, measurement, validation, and operating constraints.

A. LLMs for RTL Generation and Hardware Benchmarking

  • RTL-generation benchmarks and models covered snippets, modules, or a shuttle core, without hardened in-service silicon and longitudinal outcomes.Examples include Thakur et al., VerilogEval, RTLCoder, ChipNeMo [38], and Chip-Chat.Source: A. LLMs for RTL Generation and… · p. 11

B. Agentic and Feedback-Driven LLM Hardware Flows

  • Tool-in-the-loop systems added testbench feedback, repair, debugging, assertions, and EDA orchestration, but the cited efforts did not reach validated deployed-silicon operation.QiMeng [41] reached demonstrator bring-up, but its tapeout preceded the LLM pipeline.Source: B. Agentic and Feedback-Driven LLM… · p. 11

C. LLMs for Hardware Security

  • The cited LLM security work repairs existing RTL rather than synthesizing cryptographic hardware; the authors knew of no cryptographic-end-goal LLM design validated on real silicon.The claim is qualified as “to our knowledge.”Source: C. LLMs for Hardware Security · p. 11

D. Closest Prior Art: LLMs for PQC Hardware

  • The two closest 2026 PQC-hardware LLM works stop short of validated operation, while this work continues through byte-exact silicon and adversarial soak.Liao et al. report up to 2.6× kernel speedup over an HLS baseline.Source: D. Closest Prior Art: LLMs for PQC… · p. 11

E. ML-KEM/ML-DSA Hardware Accelerators

  • Among unified accelerators, the paper distinguishes its mid-range Kintex-7 platform, on-chip custody and key generation, and end-to-end PCIe measurements; it makes no side-channel claim.Prior unified designs receive seeds and keys over the host bus; related commercial silicon and accelerator approaches are also surveyed.Source: E. ML-KEM/ML-DSA Hardware Accelerators · p. 12

VIII. THREATS TO VALIDITY AND LIMITATIONS

  • The n=1, single-operator Claude study uses self-reported, incompletely covered logs; acceptance stringency varies by task bucket, limiting interpretation of its gradient.The authors say generalizability to other models, toolchains, operators, or task mixes is unknown.Source: §VIII · p. 12
  • The embedded KEK SALT is not assumed secret against a physical adversary, and the accelerator has neither CAVP testing nor FIPS 140-3 validation.The deployed HRNG chain also lacks formal entropy-source validation; the source’s min-entropy characterization does not establish that validation.Source: §VIII · p. 13
  • Reported operations-per-second use peak fast-path measurements, while default resets add about 1 ms; signing benchmarks use a fixed low-rejection message, and only one operation runs at a time.No masking is applied to the NTT, Keccak, or sampling datapaths; BUG-IDE-037 is fail-detectable, not a forgery vulnerability.Source: §VIII · p. 13

IX. CONCLUSION

The conclusion pairs a validation-gated deployed accelerator with a hardware-coupling pattern in the LLM-driven campaign, while treating that pattern as a hypothesis rather than a calibrated constant. It identifies replication and further security and deployment work as future directions.

IX. CONCLUSION

  • The deployed v89 accelerator is byte-exact across all six FIPS operations and passed a re-soaked validation, while the n=1 campaign’s coupling gradient remains a hypothesis.The campaign reports 71.6% success across 232 experiments, with 77–85% in documentation/research and 50–53% in synthesis/bring-up; the artifact uses one XC7K160T at 98.5% slice occupancy.Source: §IX · p. 13
  • Future work includes multi-operator and multimodel replication, at-rest key secrecy, side-channel hardening, higher-throughput NTTs, and FIPS 140-3 and CAVP validation.The paper calls for claims to remain bounded by the validation rung achieved.Source: §IX · p. 13

AUTHOR CONTRIBUTIONS AND ACKNOWLEDGMENTS

  • The 232-experiment campaign was conducted by J. Park as the single operator, who also wrote the manuscript; Anthropic Claude models served as the LLM assistant.E. Kim, W. Kim, and S. Cho supported the board platform, and B. Cha reviewed and revised the manuscript.Source: AUTHOR CONTRIBUTIONS AND ACKNOWLEDGMENTS · p. 13
Loading 2609.04058v1…