How it integrates

The middle layer, in detail.

Dainamiq is a Key Management Entity — software you run at each site, beside the IPsec / VPN gateway you already own. Your gateway requests keys over ETSI GS QKD 014, the standard interface for quantum-safe key delivery. Same tunnel, same encryption; only where the keys come from changes.

Your firewall already speaks our API

Three commercial firewalls embed the 014 client in firmware, no agent, no sidecar.

If you run Juniper SRX/MX (Junos 22.4R1+), Fortinet FortiGate (FortiOS 7.4.2+), or Palo Alto (PAN-OS 12.1+), the ETSI 014 REST client is already in the firmware. On Juniper it is exactly “point the quantum-key-managerprofile at the KME URL” — Junos accepts any KME speaking the standard, with no allow-list and no certificate pinning. For open-source stacks (strongSwan), a lightweight daemon bridges ETSI 014 to the IPsec layer.

Three caveats we state rather than hide

Fortinet is not IKE-conformant

FortiOS negotiates with a proprietary USE_QKD notify, not RFC 8784's USE_PPK (16435). A FortiGate will not share QKD keys with a non-Fortinet peer over IPsec. It still speaks ETSI 014 to our KME.

Cisco does not speak 014

IOS-XE / IOS-XR key over Cisco's proprietary SKIP. A Cisco integration requires our KME to expose a SKIP server, separate engineering, separate SKU.

MACsec and optical are not plug-and-play

On Ciena, Nokia, ADVA and Thales/Senetas gear the 014 client lives in the vendor's key-management server, not the encryptor, and IEEE 802.1X MKA has no field to carry the ETSI 014 key_ID between peers. Treat as a solutions-engineering engagement.

The sources behind the plane

Every kind of key and signature material, treated as an interchangeable source.

Any single source is replaceable; the plane is not. Each is honest about what ships today versus what’s ahead, and all await live-hardware validation.

PQC / classical

Shipped

Per-tier ML-KEM 512/768/1024 and ML-DSA 44/65/87, crypto-agility, per-frame ML-DSA channel authentication, replay protection. The universal baseline — every source rides this layer.

QKD (BBM92)

Shipped · proof-of-concept

Full engine: HAL, BBM92, Cascade/LDPC reconciliation, privacy amplification, an ETSI 014 KMS and a finite-key bound. We built it to prove we can handle the speeds and complexity the other quantum-security applications demand — a self-healing, self-optimizing engine holding mid-40s Kbps over metro fiber. It's the proof beneath the layer, not the headline.

QDS: quantum/PQC signatures

Sign / verify shipped

/sign and /verify over ML-DSA today; the full quantum-digital-signature design is scoped. Genuinely open ground: no standard, no commercial product exists yet.

QRNG — certifiable entropy

Shipped in-software

An EntropySource abstraction with SP 800-90B continuous health tests (repetition-count and adaptive-proportion), a QRNG-Open-API hardware driver, an entropy pool and CLI pipeline. Pending only live-hardware validation.

QPV / quantum alarm / secure time-sync

Roadmap

Position-bound key delivery and related applications ride the same plane as they mature.

Check your domain →