Quantum Daemons

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.

Key paths in the public PQC + QKD testbed A simulated QKD key source and an ML-KEM-1024 plus P-384 hybrid KEM both feed arnika, which combines them with HKDF-SHA3-256. arnika supplies the WireGuard wg0 pre-shared key and the IKEv2 post-quantum preshared key used by strongSwan, which also runs an ML-KEM-768 additional key exchange. Separately, Rosenpass keys WireGuard wg1, which runs inside wg0. arnika runs at a commit from its open pull request 51, not a release. PPK rotations on the strongSwan IKEv2 lane were measured before and after that pull request. QKD key source simulated link ETSI GS QKD 014-style API ML-KEM-1024 + P-384 hybrid KEM through HPKE (in arnika PR #51) arnika combines both key sources HKDF-SHA3-256 (QKD ‖ PQC) pinned to a commit of PR #51 WireGuard wg0 pre-shared key from arnika strongSwan IKEv2 PPK from arnika (RFC 8784) + ML-KEM-768 (RFC 9370) Rosenpass Classic McEliece 460896 + Kyber512 WireGuard wg1 keyed by Rosenpass, inside wg0 simulated measured: PPK rotations, before and after

Combined keys

  1. QKD key sourceSimulated link with an ETSI GS QKD 014-style API
  2. ML-KEM-1024 + P-384Hybrid KEM through HPKE (in arnika PR #51)
  3. arnikaCombines both sources with HKDF-SHA3-256 (QKD ‖ PQC). Pinned to commit f4cf9ba of open PR #51
  4. WireGuard wg0Pre-shared key from arnika
  5. 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

  1. RosenpassClassic McEliece 460896 + Kyber512
  2. WireGuard wg1Keyed by Rosenpass, runs inside wg0
  • running software (versions pinned in the repository)
  • simulated
  • key path
The public testbed. The VPN software, the post-quantum key exchanges and the key derivation run for real; the QKD layer is simulated. arnika runs at a commit from an open upstream pull request (#51), not a release. Live at pqc-qkd-hybrid.daemons.jp.

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.

    measured

    PPK 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.

    measured
    • 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,155
    1.54
    After4 of 14,595
    0.27

    Fail-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,155
    0
    After1,844 of 14,595
    126

    The two panels use different scales.

    Table view
    BeforeAfter
    arnika3a8cc13 (main)f4cf9ba (PR #51 as of 24 Sep 2026)
    PQC input to arnikaa PQC key filearnika's own PQC (HPKE, PR #51)
    Window (UTC)25 Sep 10:55 to 2 Oct 10:553 Oct 07:04 to 8 Oct 08:42
    Hours in the comparison168121.6 (the next 46.4 excluded, reported separately)
    PPK rotations20,15514,595
    Race condition (C3)31 (1.54 per 1,000)4 (0.27 per 1,000)
    C3 by alice's role: primary / backup31 / 00 / 4
    Fail-closed invalidation (C1)01,844 (126.3 per 1,000)
    Input divergence (C4)12 (0.60 per 1,000)0
    C2, C5, unclassified00
    All failures43 (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.

    simulated

    Re-routing around a link outage in the Cambridge quantum network

    Protocol Lab, recorded in a browser. 19 seconds, no sound.

    simulated
    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 baselinesimulated

    Error 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.

    classical baselinesimulated
    Burgers+0.029 (−0.026 to 0.080), p = 0.32
    Lid-driven cavity, Re = 10+0.027 (−0.00004 to 0.052), p = 0.11
    Table view
    Relative L2 error on uBurgersCavity, Re = 10
    Classical, parameter-matched0.1840.161
    Quantum-assisted0.1560.134
    Mean paired difference (from unrounded values)+0.029+0.027
    95% interval−0.026 to 0.080−0.00004 to 0.052
    Wilcoxon p0.320.11
    Seeds per arm1010
    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