Quantum-safe networking, checked in public.
Quantum Daemons is a one-person research organization in Japan. I measure and test hybrid post-quantum (PQC) and quantum key distribution (QKD) setups in open-source VPN and key-management software, and publish the code and the counting rules behind each result so that others can check it.
It is not a consultancy. Each result states what was tested, in which versions and configuration, and how it was evidenced.
Combined keys
- QKD key sourceSimulated link with an ETSI GS QKD 014-style API
- ML-KEM-1024 + P-384Hybrid KEM through HPKE (in arnika PR #51)
- arnikaCombines both sources with HKDF-SHA3-256 (QKD ‖ PQC). Pinned to commit f4cf9ba of open PR #51
- WireGuard wg0Pre-shared key from arnika
- strongSwan IKEv2PPK (RFC 8784) from arnika, plus an ML-KEM-768 additional key exchange (RFC 9370). PPK rotations measured before and after PR #51
Separate post-quantum handshake
- RosenpassClassic McEliece 460896 + Kyber512
- WireGuard wg1Keyed by Rosenpass, runs inside wg0
- running software (versions pinned in the repository)
- simulated
- key path
What you can check today
Each item links to the place where it can be verified.
-
Three fixes merged into arnika
arnika is the open-source tool that combines QKD and post-quantum keys for VPN tunnels. I am a member of the arnika-project GitHub organization (invited by the maintainers, August 2026).
merged upstream -
Before and after: arnika PR #51
PPK rotations on the IPsec (strongSwan) lane, recorded for 168 hours on each side of an open pull request and compared under rules fixed before the runs. The counting script and the counts are published; the container logs, which carry credential IDs and host identities, are withheld. The numbers were posted on the pull request on 12 October 2026.
measuredPPK rotation failures per 1,000 rotations, before and after arnika PR #51
strongSwan IKEv2 lane of the public testbed. Two of the failure classes are shown; the table view lists all of them.
- Before: arnika 3a8cc13 (main), 25 Sep–2 Oct 2026, 168 h
- After: arnika f4cf9ba (PR #51 as of 24 Sep), 3–8 Oct 2026, 121.6 h
Race condition (C3)
The comparison fixed before the runs. One-sided p = 9.04 × 10−5, exact conditional binomial test.
Before31 of 20,1551.54After4 of 14,5950.27Fail-closed invalidation (C1)
Not part of the fixed comparison. In each, a backup interval of the node alice ended with a random PPK, and her next IKE_AUTH failed once.
Before0 of 20,1550After1,844 of 14,595126The two panels use different scales.
Table view
Before After arnika 3a8cc13 (main) f4cf9ba (PR #51 as of 24 Sep 2026) PQC input to arnika a PQC key file arnika's own PQC (HPKE, PR #51) Window (UTC) 25 Sep 10:55 to 2 Oct 10:55 3 Oct 07:04 to 8 Oct 08:42 Hours in the comparison 168 121.6 (the next 46.4 excluded, reported separately) PPK rotations 20,155 14,595 Race condition (C3) 31 (1.54 per 1,000) 4 (0.27 per 1,000) C3 by alice's role: primary / backup 31 / 0 0 / 4 Fail-closed invalidation (C1) 0 1,844 (126.3 per 1,000) Input divergence (C4) 12 (0.60 per 1,000) 0 C2, C5, unclassified 0 0 All failures 43 (2.13 per 1,000) 1,848 (126.6 per 1,000) Only the C3 total was compared under a test fixed before the runs; every other row is descriptive.
Counted from the two IPsec nodes' logs with the published script. Only the arnika commit and its PQC input changed between the arms, as fixed before the runs. The after arm also ran for 168 h; its last 46.4 h, from the start of an interval-number mismatch between the nodes, are excluded under the rule fixed before the runs and reported separately.
Race conditions became rarer: all 31 before were in intervals where alice was the primary, and the 4 after in intervals where she was the backup (tests by role were not fixed beforehand). 1,844 rotations failed after a fail-closed invalidation that the earlier code could not produce; such invalidations grew as the offset between the two nodes' interval boundaries widened from −30 ms to −15 s. The numbers were posted on the pull request on 12 October 2026. The container logs, which carry credential IDs and host identities, are withheld.
Source: the measurement report and its fixed comparison.
-
The public PQC + QKD testbed
WireGuard with Rosenpass, and strongSwan IKEv2 with ML-KEM-768 and a post-quantum preshared key, with keys from arnika. Source under Apache-2.0.
runningQKD simulated -
Protocol Lab
Trusted-node QKD key relay, simulated in the browser over five networks described in four journal papers and a preprint: Cambridge, SECOQC Vienna, the Tokyo QKD Network, MadQCI and Thuringia. Reported values and model values sit in separate columns, with the source and licence of each network.
simulatedRe-routing around a link outage in the Cambridge quantum network
Protocol Lab, recorded in a browser. 19 seconds, no sound.
100G encryptors between TREL and CAPE (two line-card pairs in the paper) use keys from a store that is refilled over one-time-pad tunnels along the active route (thick line). When the CAPE–TREL link goes down (red), the route goes round the ring through ENGI, which acts as a trusted relay; when the link is restored, the route returns. The order of the routes follows Dynes et al., npj Quantum Information 5, 101 (2019), doi:10.1038/s41534-019-0221-4, licensed CC BY 4.0. The drawing is this project's layout, and the timing and the rates are simulated. -
Merged work in quantum computing software
Through unitaryHACK 2026: three merged pull requests (two in NVIDIA CUDA-Q, one in QuEST) and two bounties, $200 in total. CUDA-Q #4693 adds unitary synthesis for 3- to 5-qubit custom operations; QuEST #783 is a GPU optimization.
merged upstream -
A classical baseline for quantum-assisted PINNs
Submission to the WISER Summer Program 2026 BQP Challenge (finalist). Quantum-assisted physics-informed neural networks against parameter-matched classical networks, 10 seeds each: no statistically significant difference in the two headline cases (Wilcoxon p = 0.32 and 0.11). Report, code and results are public under MIT.
classical baselinesimulatedError difference: parameter-matched classical network minus quantum-assisted network
Relative L2 error on u, 10 seeds per arm. Dot: mean of the paired differences. Line: 95% paired bootstrap interval.
Burgers+0.029 (−0.026 to 0.080), p = 0.32Lid-driven cavity, Re = 10+0.027 (−0.00004 to 0.052), p = 0.11Table view
Relative L2 error on u Burgers Cavity, Re = 10 Classical, parameter-matched 0.184 0.161 Quantum-assisted 0.156 0.134 Mean paired difference (from unrounded values) +0.029 +0.027 95% interval −0.026 to 0.080 −0.00004 to 0.052 Wilcoxon p 0.32 0.11 Seeds per arm 10 10 Right of zero means that the quantum-assisted network (about 670 parameters) had a lower mean error than a classical network with the same parameter budget. Both intervals include zero (the cavity's only just), and neither Wilcoxon test reaches p < 0.05. A 6.7k-parameter classical PINN does better on Burgers (0.095 against 0.156). In the cavity at Re = 100, the matched classical network wins from a cold start (0.39 against 0.86), and the quantum-assisted network wins when both are warm-started from Re = 10 (0.19 against 0.25). The quantum layer ran only in statevector simulation; no quantum hardware was used. Source: the significance table and the README of the repository.
The same method is used for quantum sensing and quantum computing benchmarks. Those results will be listed here as they are published.
How each claim is labelled
Results and reports carry one of these labels per layer, so a reader can see what kind of evidence stands behind each statement.
- merged upstream
- The change is in the project's main code, and the pull request is linked.
- measured
- Counted from logs in a stated time window, with the counting script and the counts published. Raw logs that carry credential IDs or host identities are withheld. Nothing is claimed outside that window.
- running
- The component runs in the public testbed at the version pinned in its repository. This shows that it works there, not that it is correct or released.
- official vectors
- Output matches test vectors published by the owner of the standard, such as NIST ACVP.
- computed from the spec
- Implemented from the specification where no official vectors exist. A passing self-test here is not proof of correctness.
- two implementations agree
- Independent implementations produce the same result. This shows consistency, not correctness.
- classical baseline
- Compared with a classical method given the same budget, with seeds and statistics published. The result is reported whichever way it falls.
- simulated
- Physics or networks are modelled from published data, not measured. The QKD layer of the testbed is simulated.
What this is not
- Not a consultancy: no advisory engagements, no meetings as a product, no priority support.
- No certification or compliance statements. A result covers the versions, configuration and time window it names.
- No quantum hardware. The QKD layer in the testbed is simulated.
- No claims of quantum advantage.
In preparation
Re-runnable test reports for the software versions and configurations an organization actually runs, each with a cryptographic bill of materials (CBOM).
Not available yet. The open testbed, the measurements and the upstream work stay public either way.
About
Quantum Daemons is the sole proprietorship of Amon Koike, an independent quantum research engineer in Japan, registered in August 2026. Background in CAE and simulation software.
- IBM Certified Quantum Computation using Qiskit v2.X Developer - Associate
- unitaryHACK 2026: three merged pull requests and two bounties
- WISER Summer Program 2026, BQP Challenge: finalist
- Qiskit Advocate since February 2026, and mentor at the Qiskit Global Summer School 2026
Contact
- Questions about a result: open an issue on the repository that holds it.
- Anything else: a message on LinkedIn.
- Email: amon.koike@daemons.jp