papers/defense/hanzo-quantum-sensing-qkd.tex

\documentclass[11pt,letterpaper]{article}
\usepackage{hanzo-defense}

\doctitle{Quantum Key Distribution and Quantum Sensing\\Integration for Post-Quantum Blockchain\\Consensus and Threshold Cryptography}
\docid{HAI-2026-009}
\docversion{Version 1.0 --- February 27, 2026}
\docdate{February 2026}
\docauthors{Hanzo AI Research --- Hanzo Team}
\docorgs{Hanzo Industries\\[email protected]}

\begin{document}
\makecover

\begin{abstract}
We present an architecture for integrating quantum key distribution (QKD) hardware and quantum sensing devices into a production post-quantum blockchain stack. The system extends five existing production components---QuantumVM (Q-Chain), the KEM cryptographic interface, RNS mesh transport, Sovereign KMS, and the Hanzo Zero Trust fabric---with QKD-derived key material and quantum sensor attestations. A novel \emph{triple-hybrid} key derivation combines classical Diffie-Hellman (X25519), post-quantum lattice encapsulation (ML-KEM-768, \fips{203}), and physics-layer QKD shared secrets via HKDF, ensuring link security if \emph{any one} of three independent foundations holds: elliptic curve hardness, Module-LWE hardness, or the laws of quantum mechanics. Quantum sensors---atomic clocks, magnetometers, and gravimeters---feed cryptographically attested measurements into the Q-Chain via a Sensor Oracle, stamped with dual BLS/Corona threshold signatures for immutable provenance. We specify ETSI GS QKD 014 and ITU-T Y.3800 compliant interfaces, analyze integration with threshold MPC signing ceremonies, and project a 3,000--5,000 line implementation leveraging existing production interfaces. No competing blockchain system offers production post-quantum consensus, let alone QKD or quantum sensing integration.
\end{abstract}

\paragraph{Executive Summary.}
This paper is a \emph{design}, not a fielded product---it specifies how to extend an existing, in-production post-quantum system with two emerging quantum technologies, and estimates the work at roughly 3,000--5,000 lines of new code (see the roadmap table). The first technology, quantum key distribution, secures a communications link using the laws of physics: an eavesdropper cannot tap the channel without being detected. The design uses it as a \emph{third} independent lock layered on top of today's cryptography and the new quantum-resistant standards, so the link stays secure as long as any one of the three holds---belt, suspenders, and a physical law. The second, quantum sensing, lets devices that measure time, magnetic fields, or gravity with extreme precision sign their readings and anchor them to a tamper-evident record---useful for navigation and timing when GPS is jammed, and for detecting things (like submarines) that conventional sensors miss. The intended audience is defense and government technologists planning for the quantum era; the honest claim is that the production foundation it plugs into already exists, and this specifies the bridge to quantum hardware as that hardware matures.

\tableofcontents
\newpage

% ============================================================================
\section{Introduction}
% ============================================================================

Post-quantum cryptography protects against \emph{algorithmic} quantum attacks---Shor's algorithm breaking RSA and elliptic curves, Grover's algorithm weakening symmetric ciphers. However, algorithmic security rests on computational hardness \emph{assumptions} (Module-LWE, Module-SIS) that, while believed strong, lack the unconditional guarantee of physics-based security.

Quantum key distribution provides information-theoretic security grounded in the laws of quantum mechanics: an eavesdropper disturbing a quantum channel is detectable with probability approaching 1. Quantum sensing exploits quantum coherence and entanglement for measurement precision beyond classical limits.

This paper presents an architecture that layers physics-based security (QKD) atop algorithmic security (PQ crypto) atop classical security (ECDH), creating a triple-hybrid defense-in-depth unique in the blockchain and military networking landscape.

\subsection{Existing Production Foundation}

The architecture builds on five deployed systems:

\begin{enumerate}
\item \textbf{QuantumVM (Q-Chain)}: Production VM with ML-DSA-44/65/87 signing, SLH-DSA stamping, and Quasar dual-threshold consensus (BLS + Corona).
\item \textbf{KEM Interface}: Pluggable key encapsulation supporting ML-KEM-768, ML-KEM-1024, X25519, and hybrid modes.
\item \textbf{RNS Mesh Transport}: Medium-agnostic networking with hybrid PQ handshake (X25519 + ML-KEM-768 + ML-DSA-65) over LoRa, serial, TCP, and satellite.
\item \textbf{Sovereign KMS}: Enterprise key management with Shamir sharing, HPKE wrapping, transit engine, and TFHE bridge.
\item \textbf{Zero-Trust Fabric}: Identity-first overlay network with pluggable transport underlays and HSM integration.
\end{enumerate}

\subsection{What This Paper Adds}

\begin{enumerate}
\item \textbf{QKD-KEM Bridge}: ETSI GS QKD 014 client wrapping QKD-derived keys into the existing \texttt{kem.KEM} interface.
\item \textbf{Triple-Hybrid Key Derivation}: $K = \text{HKDF}(\text{X25519\_ss} \| \text{ML-KEM\_ss} \| \text{QKD\_key})$.
\item \textbf{Sensor Oracle}: New transaction type in QuantumVM for quantum sensor attestations with dual-threshold signatures.
\item \textbf{QRNG Integration}: Drop-in replacement of \texttt{crypto/rand} with quantum random number generator hardware.
\item \textbf{QKD Network Manager}: ITU-T Y.3800 compliant key pool orchestration across multiple QKD links.
\end{enumerate}

\subsection{Strategic Context}

The distinction this paper draws---between a deployed foundation and a specified extension---is itself the strategic point. The five systems in Section~1.1 (QuantumVM, the KEM interface, RNS mesh transport, the sovereign KMS, and the zero-trust fabric) are in production today; the QKD and quantum-sensing layers described here are a forward-looking architecture, projected at roughly 3,000--5,000 lines that implement existing interfaces without modifying the production code. Being able to make that separation credibly depends on owning the whole stack. Hanzo (American-owned, Techstars~'17, founded 2014) builds both the post-quantum cryptography in production and the \emph{Zen} frontier AI that runs on it, and its founder is a recognized expert in both AI/ML and cryptography---which is what lets a quantum-hardware bridge be specified against real, owned interfaces rather than sketched in the abstract. The wider context is sovereignty: with American frontier AI consolidated into a closed two-vendor duopoly and the open frontier ecosystem now largely offshore, Hanzo is the American open-source alternative that owns the model and the cryptography together. This roadmap extends that sovereign, auditable foundation toward the quantum era---honestly labeled as a roadmap, on top of a foundation that already runs.

% ============================================================================
\section{Quantum Key Distribution Integration}
% ============================================================================

\subsection{QKD Protocol Support}

The architecture supports all major QKD protocol families via the ETSI standardized hardware interface:

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}llrrl@{}}
\toprule
\textbf{Protocol} & \textbf{Type} & \textbf{Range} & \textbf{Rate} & \textbf{Vendors} \\
\midrule
BB84 & DV, prepare-measure & $<$100 km & $\sim$1 Mbps & ID Quantique \\
CV-QKD & Continuous-variable & $<$50 km & $\sim$10 Mbps & Toshiba \\
MDI-QKD & Measurement-device-indep. & $<$400 km & $\sim$100 kbps & QuantumCTek \\
TF-QKD & Twin-field & $<$600 km & $\sim$10 kbps & Toshiba, USTC \\
E91 & Entanglement-based & $<$100 km & $\sim$10 kbps & Research \\
\bottomrule
\end{tabular}
\caption{Supported QKD protocols via ETSI hardware interface.}
\label{tab:qkd-protocols}
\end{table}

\subsection{ETSI GS QKD 014 Client}

All QKD hardware interaction uses the ETSI GS QKD 014 REST API, the industry standard key delivery interface:

\begin{lstlisting}[caption={ETSI QKD 014 key request flow.}]
// Request quantum-derived key material
GET /api/v1/keys/{slave_SAE_ID}/status
  -> { "source_KME_ID": "kme-alpha",
       "key_count": 42,
       "max_key_size": 256 }

POST /api/v1/keys/{slave_SAE_ID}/enc_keys
  body: { "number": 1, "size": 256 }
  -> { "keys": [
         { "key_ID": "a1b2c3d4-...",
           "key": "base64(256-bit key)" }
       ]}

// Peer retrieves same key by ID
POST /api/v1/keys/{master_SAE_ID}/dec_keys
  body: { "key_IDs": ["a1b2c3d4-..."] }
  -> { "keys": [
         { "key_ID": "a1b2c3d4-...",
           "key": "base64(same 256-bit key)" }
       ]}
\end{lstlisting}

The ETSI 014 abstraction makes the architecture hardware-agnostic: BB84, CV-QKD, or TF-QKD appliances from any vendor present the same REST interface.

\subsection{QKD-KEM Bridge}

The QKD-KEM bridge implements the existing \texttt{kem.KEM} interface, enabling QKD to slot into any component that uses key encapsulation:

\begin{lstlisting}[language=Go,caption={QKD-KEM bridge implementing existing KEM interface.}]
type QKDKEM struct {
    client *etsi014.Client
    peerID string
}

func (q *QKDKEM) Encapsulate() (ct, ss []byte, err error) {
    // Request key from local QKD node
    key, err := q.client.GetKey(q.peerID, 256)
    if err != nil { return nil, nil, err }
    // "ciphertext" is just the key_ID (peer fetches same key)
    return []byte(key.KeyID), key.Material, nil
}

func (q *QKDKEM) Decapsulate(ct []byte) (ss []byte, err error) {
    keyID := string(ct)
    key, err := q.client.GetKeyByID(q.peerID, keyID)
    return key.Material, err
}
\end{lstlisting}

This plugs directly into the RNS link handshake at \texttt{rns\_link.go} where ML-KEM ciphertexts are exchanged. The QKD-KEM has zero ciphertext overhead---the key is delivered out-of-band by the quantum channel.

% ============================================================================
\section{Triple-Hybrid Key Derivation}
% ============================================================================

\subsection{Security Model}

\begin{definition}[Triple-Hybrid Security]
A key exchange is triple-hybrid secure if the derived session key $K$ is indistinguishable from random under the assumption that \emph{at least one} of the following holds:
\begin{enumerate}
\item The Computational Diffie-Hellman problem on Curve25519 is hard (classical).
\item The Module-LWE problem with ML-KEM-768 parameters is hard (post-quantum algorithmic).
\item The laws of quantum mechanics prevent undetected eavesdropping on the QKD channel (physics-layer).
\end{enumerate}
\end{definition}

\subsection{Protocol}

\begin{algorithm}[H]
\caption{Triple-Hybrid Key Exchange}
\begin{algorithmic}[1]
\State \textbf{Layer 1 --- Classical ECDH}:
\State \quad $\text{ss}_1 \gets \text{X25519.DH}(\text{ek}_A, \text{epk}_B)$ \quad (32 bytes)
\Statex
\State \textbf{Layer 2 --- Post-Quantum KEM}:
\State \quad $(\text{ct}_2, \text{ss}_2) \gets \text{ML-KEM-768.Encaps}(\text{epk}_B^M)$ \quad (32 bytes)
\Statex
\State \textbf{Layer 3 --- Physics-Layer QKD}:
\State \quad $\text{ss}_3 \gets \text{QKD.GetKey}(\text{peer\_ID}, 256)$ \quad (32 bytes)
\State \quad $\text{key\_ID} \gets \text{QKD.KeyID}(\text{ss}_3)$
\Statex
\State \textbf{Combine}: $K \gets \text{HKDF-SHA256}(\text{salt}, \text{ss}_1 \| \text{ss}_2 \| \text{ss}_3)$
\State \textbf{Derive}: $K_{\text{send}}, K_{\text{recv}} \gets \text{HKDF-Expand}(K, \text{``triple-hybrid-v1''})$
\State \textbf{Exchange}: Send $\text{epk}_A^X \| \text{ct}_2 \| \text{key\_ID}$ to peer
\State \textbf{Session}: AES-256-GCM with derived keys
\end{algorithmic}
\end{algorithm}

\begin{theorem}[Triple-Hybrid IND-CCA2]
If any one of X25519, ML-KEM-768, or the QKD key is secure (\ie unknown to the adversary), then the HKDF output $K$ is computationally indistinguishable from a uniformly random key of the same length. This follows from the extraction property of HKDF: given sufficient min-entropy in any one input, the output is pseudorandom regardless of the other inputs.
\end{theorem}

\subsection{Wire Format}

\begin{table}[H]
\centering
\begin{tabular}{@{}lrrr@{}}
\toprule
\textbf{Component} & \textbf{Classical} & \textbf{PQ Hybrid} & \textbf{Triple Hybrid} \\
\midrule
X25519 ephemeral PK & 32 B & 32 B & 32 B \\
ML-KEM-768 ciphertext & --- & 1,088 B & 1,088 B \\
QKD key\_ID (UUID) & --- & --- & 36 B \\
ML-DSA-65 signature & --- & 3,309 B & 3,309 B \\
\midrule
\textbf{Total per-direction} & \textbf{32 B} & \textbf{$\sim$4.4 KB} & \textbf{$\sim$4.5 KB} \\
\bottomrule
\end{tabular}
\caption{Wire overhead comparison: triple-hybrid adds only 36 bytes (UUID) over PQ hybrid.}
\label{tab:triple-hybrid-wire}
\end{table}

The QKD layer adds only 36 bytes (a UUID key reference) to the handshake---the actual key material is delivered by the quantum channel, not the classical network.

% ============================================================================
\section{Quantum Sensing and Attestation}
% ============================================================================

\subsection{Sensor Types}

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}llll@{}}
\toprule
\textbf{Sensor} & \textbf{Technology} & \textbf{Precision} & \textbf{Naval Application} \\
\midrule
Atomic clock & CSAC/optical lattice & $<$1 $\mu$s accuracy & GPS-denied timing \\
Magnetometer & SERF/NV-center & $<$1 fT sensitivity & Submarine detection \\
Gravimeter & Atom interferometry & $<$1 $\mu$Gal & Subsurface mapping \\
Quantum radar & Microwave photons & Enhanced SNR & Target detection \\
Quantum lidar & Entangled photons & Sub-shot-noise & Terrain mapping \\
\bottomrule
\end{tabular}
\caption{Quantum sensor types with naval applications.}
\label{tab:sensors}
\end{table}

\subsection{Sensor Oracle Architecture}

Quantum sensor measurements are ingested into the Q-Chain via a Sensor Oracle transaction type:

\begin{lstlisting}[language=Go,caption={Sensor attestation transaction.}]
type SensorAttestation struct {
    SensorType    SensorType  // AtomicClock, Magnetometer, etc.
    DeviceID      [32]byte    // Hardware attestation identity
    Timestamp     int64       // Sub-nanosecond precision
    Measurement   []byte      // Sensor-specific data format
    Uncertainty   float64     // Measurement uncertainty
    TEESignature  []byte      // TEE-signed device attestation
    MLDSASignature []byte     // ML-DSA-65 over all fields
}
\end{lstlisting}

The QuantumVM's existing \texttt{StampBlock} interface accepts arbitrary block IDs and messages---sensor attestations are stamped with the same Quasar dual-signature (BLS + Corona) that certifies consensus blocks.

\subsection{Atomic Clocks for Consensus Timing}

Chip-scale atomic clocks (CSAC) provide GPS-independent timing for DDIL environments:

\begin{itemize}
\item \textbf{Current}: QuantumVM uses \texttt{time.Now()} for block timestamps (OS clock, $\sim$1 ms accuracy).
\item \textbf{With CSAC}: Sub-microsecond timestamp ordering via PTP/1PPS interface from quantum clock.
\item \textbf{Byzantine detection}: Validators with drifted clocks produce timestamps outside the consensus window, enabling automatic identification of faulty or compromised nodes.
\item \textbf{GPS-denied operation}: Aligns with RNS mesh networking for maritime/submarine scenarios where GPS signals are unavailable or jammed.
\end{itemize}

\subsection{Magnetometers for Physical Security}

Quantum magnetometers detecting sub-femtotesla fields enable:

\begin{itemize}
\item \textbf{Tamper detection}: Cryptographically attested magnetic field baseline for data center physical security. Any hardware modification changes the field signature.
\item \textbf{Submarine detection}: Blockchain-attested magnetic anomaly data from distributed sensor arrays.
\item \textbf{Navigation}: Magnetic field map matching for GPS-denied underwater navigation, attested on-chain for integrity.
\end{itemize}

\subsection{Gravimeters for Subsurface Intelligence}

Atom-interferometry gravimeters provide:

\begin{itemize}
\item \textbf{Subsurface mapping}: Detect underground structures, tunnels, and voids.
\item \textbf{Immutable geological records}: Blockchain-attested gravity surveys with provenance chains.
\item \textbf{Anti-spoofing}: Ground-truth gravity data anchored to consensus prevents adversary falsification.
\end{itemize}

% ============================================================================
\section{QRNG Integration}
% ============================================================================

\subsection{Drop-In Entropy Source}

Quantum random number generators (QRNG) provide entropy from quantum vacuum fluctuations or single-photon detection:

\begin{lstlisting}[language=Go,caption={QRNG entropy source replacement.}]
// Current (QuantumSigner, line 104):
crypto.rand.Read(nonce)  // reads /dev/urandom

// With QRNG hardware:
qrng.Read(nonce)  // reads /dev/qrng0
// Fallback: crypto/rand if QRNG unavailable
\end{lstlisting}

\begin{table}[H]
\centering
\begin{tabular}{@{}llrl@{}}
\toprule
\textbf{Device} & \textbf{Interface} & \textbf{Rate} & \textbf{Standard} \\
\midrule
ID Quantique Quantis & USB/PCIe & 4--240 Mbps & NIST SP 800-90B \\
Quside FQRNG & PCIe & 400+ Mbps & NIST SP 800-22 \\
Toshiba QRNG & Integrated & 2 Gbps & MIST/BSI certified \\
\bottomrule
\end{tabular}
\caption{QRNG hardware options.}
\label{tab:qrng}
\end{table}

QRNG integration is the lowest-effort, highest-value component: a single import replacement at \texttt{rand.Read()} call sites across the key generation and nonce generation code paths.

% ============================================================================
\section{Integration with Threshold MPC}
% ============================================================================

\subsection{QKD-Authenticated DKG Ceremony}

Distributed Key Generation requires secure channels between all $n$ parties. QKD provides information-theoretically secure channels for share distribution:

\begin{algorithm}[H]
\caption{QKD-Authenticated Threshold Key Generation}
\begin{algorithmic}[1]
\State \textbf{Setup}: Each pair $(P_i, P_j)$ establishes QKD link
\State \quad $K_{ij} \gets \text{QKD.GetKey}(P_j, 256)$ (symmetric key from quantum channel)
\Statex
\State \textbf{DKG Phase 1}: Commitment broadcast
\For{each party $P_i$}
  \State Sample polynomial $f_i(x)$ of degree $t-1$
  \State Broadcast commitment $C_i = g^{f_i(0)}$ (public, signed ML-DSA-65)
  \For{each party $P_j$}
    \State Encrypt share: $e_{ij} = \text{AES-256-GCM}(K_{ij}, f_i(j))$
    \State Send $e_{ij}$ via classical channel (QKD key protects confidentiality)
  \EndFor
\EndFor
\Statex
\State \textbf{Advantage}: Share distribution is information-theoretically secure
\State Even a quantum computer cannot recover $f_i(j)$ from $e_{ij}$ without $K_{ij}$
\end{algorithmic}
\end{algorithm}

\subsection{QKD-Secured Signing Sessions}

Threshold signing messages between MPC parties use QKD-derived session keys:

\begin{itemize}
\item \textbf{CGGMP21}: Round messages encrypted with QKD keys via ZAP transport.
\item \textbf{FROST}: Commitment and response shares protected by QKD-authenticated channels.
\item \textbf{Corona}: Lattice threshold shares doubly protected---PQ algorithmic + QKD physics-layer.
\item \textbf{BLS}: Aggregate signature shares transmitted over QKD-secured links.
\end{itemize}

\subsection{Key Rotation with QKD Refresh}

Corona epoch rotation (every 10 minutes) can incorporate QKD key refresh:

\begin{enumerate}
\item At epoch boundary, validators request fresh QKD keys from all peer links.
\item New Corona threshold keys generated using QKD-authenticated DKG.
\item Old keys destroyed; forward secrecy guaranteed by both ephemeral PQ keys and QKD one-time keys.
\item Triple protection: even if lattice assumptions fail AND classical crypto breaks, QKD keys remain secure.
\end{enumerate}

% ============================================================================
\section{Integration with Consensus}
% ============================================================================

\subsection{QKD-Authenticated Validator Links}

Quasar consensus samples $k$ peers per round. QKD provides an additional authentication layer:

\begin{itemize}
\item \textbf{Pre-established QKD links}: Validators with fiber-connected QKD appliances establish shared keys.
\item \textbf{Consensus message authentication}: HMAC using QKD-derived key appended alongside BLS signatures.
\item \textbf{Sybil resistance}: QKD links are physical---an adversary cannot create virtual QKD connections without quantum hardware and fiber access.
\item \textbf{Partial deployment}: Validators without QKD hardware continue using PQ-hybrid authentication. The system degrades gracefully.
\end{itemize}

\subsection{Sensor-Attested Block Production}

Blocks can include quantum sensor attestations as special transactions:

\begin{itemize}
\item Atomic clock timestamps replace OS timestamps for sub-microsecond ordering.
\item Magnetometer readings provide physical-layer environmental context.
\item All sensor data receives Quasar dual-signature (BLS + Corona) for immutable provenance.
\item Sensor attestation chain provides tamper-evident physical security monitoring.
\end{itemize}

% ============================================================================
\section{KMS Integration}
% ============================================================================

\subsection{QKD Key Import}

The Sovereign KMS Transit Engine supports key import via \texttt{importKeyMaterial()}:

\begin{itemize}
\item QKD-derived keys imported as a new key version type: \texttt{hanzo-qkd:v\{N\}:\{base64\}}.
\item Keys stored with the same per-org isolation as algorithmic keys.
\item QKD keys can serve as root keys for Shamir splitting, providing physics-layer root-of-trust.
\item HPKE wrapping extended to include QKD key material alongside ML-KEM-768.
\end{itemize}

\subsection{Key Hierarchy with QKD Root}

\begin{table}[H]
\centering
\begin{tabular}{@{}llll@{}}
\toprule
\textbf{Layer} & \textbf{Key Source} & \textbf{Security Basis} & \textbf{Rotation} \\
\midrule
Root & QKD + Shamir & Physics + threshold & Ceremony \\
Organization & AES-256 (QKD-derived) & Physics-layer & Policy \\
Session & Triple-hybrid KDF & Classical + PQ + physics & Per-session \\
Message & ML-KEM ephemeral & Algorithmic PQ & Per-message \\
\bottomrule
\end{tabular}
\caption{Key hierarchy with QKD-anchored root of trust.}
\label{tab:key-hierarchy-qkd}
\end{table}

% ============================================================================
\section{Zero-Trust Fabric Integration}
% ============================================================================

\subsection{QKD Transport Underlay}

The Hanzo ZT fabric supports pluggable transport underlays. A QKD-authenticated underlay implements the existing \texttt{Transport.Connection} interface:

\begin{itemize}
\item \textbf{Physical link}: Fiber-optic QKD channel between zero-trust nodes.
\item \textbf{Key delivery}: ETSI GS QKD 014 provides symmetric keys.
\item \textbf{Data encryption}: AES-256-GCM using QKD-derived keys on the classical channel.
\item \textbf{Authentication}: QKD keys authenticate zero-trust identity assertions.
\item \textbf{Policy enforcement}: Zero-trust policies applied after QKD authentication---QKD provides the channel, ZT provides the authorization.
\end{itemize}

% ============================================================================
\section{Standards Compliance}
% ============================================================================

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}llp{5cm}@{}}
\toprule
\textbf{Standard} & \textbf{Scope} & \textbf{Compliance} \\
\midrule
ETSI GS QKD 004 & Session-based key delivery & Client implementation \\
ETSI GS QKD 014 & REST key delivery API & Client implementation \\
ITU-T Y.3800 & QKD network overview & Functional architecture \\
ITU-T Y.3802 & QKD functional architecture & Key management layer \\
NIST SP 800-90B & Entropy source validation & QRNG qualification \\
\fips{203} (ML-KEM) & Key encapsulation & Production (existing) \\
\fips{204} (ML-DSA) & Digital signatures & Production (existing) \\
\fips{205} (SLH-DSA) & Hash-based signatures & Production (existing) \\
CNSA 2.0 & NSA algorithm suite & Full compliance \\
\bottomrule
\end{tabular}
\caption{Standards compliance matrix.}
\label{tab:standards}
\end{table}

% ============================================================================
\section{Naval Deployment Scenarios}
% ============================================================================

\subsection{Shore-to-Ship QKD via Submarine Fiber}

\begin{itemize}
\item QKD appliances at shore facility and pier-side ship terminal.
\item Pre-load QKD key pool before departure (keys consumed during deployment).
\item Triple-hybrid key derivation for all ship-to-shore encrypted communications.
\item Key pool size determines operational endurance without QKD refresh.
\end{itemize}

\subsection{Satellite QKD for Global Coverage}

\begin{itemize}
\item Satellite-based QKD (demonstrated by Micius satellite at 1,200 km) for global key distribution.
\item Trusted-node relay architecture for intercontinental links.
\item QKD keys distributed to fleet units via satellite pass windows.
\item Stored keys consumed for consensus authentication between passes.
\end{itemize}

\subsection{Submarine Quantum Sensing Array}

\begin{itemize}
\item Distributed quantum magnetometer array for ASW (anti-submarine warfare).
\item Sensor attestations transmitted via RNS mesh (acoustic/ELF radio).
\item Blockchain-anchored magnetic anomaly data for post-mission analysis.
\item Tamper-evident sensor chain prevents adversary data injection.
\end{itemize}

\subsection{GPS-Denied Navigation}

\begin{itemize}
\item Quantum atomic clocks provide autonomous timing without GPS.
\item Quantum gravimeters enable terrain-referenced navigation underwater.
\item Quantum magnetometers support magnetic-field navigation.
\item All sensor data attested on Q-Chain with dual-threshold signatures.
\end{itemize}

% ============================================================================
\section{Implementation Roadmap}
% ============================================================================

\begin{table}[H]
\centering
\begin{tabular}{@{}llrl@{}}
\toprule
\textbf{Phase} & \textbf{Component} & \textbf{LOC} & \textbf{Timeline} \\
\midrule
1 & QRNG entropy integration & $\sim$200 & Q2 2026 (planned) \\
2 & ETSI GS QKD 014 client & $\sim$800 & Q3 2026 (planned) \\
3 & QKD-KEM bridge & $\sim$400 & Q3 2026 (planned) \\
4 & Triple-hybrid key derivation & $\sim$300 & Q3 2026 (planned) \\
5 & Sensor Oracle (QuantumVM) & $\sim$1,000 & Q4 2026 (planned) \\
6 & QKD Network Manager & $\sim$1,500 & Q1 2027 (planned) \\
7 & Zero-trust QKD underlay & $\sim$800 & Q1 2027 (planned) \\
\midrule
& \textbf{Total} & \textbf{$\sim$5,000} & \\
\bottomrule
\end{tabular}
\caption{Implementation roadmap: 5,000 lines of Go leveraging existing interfaces.}
\label{tab:roadmap}
\end{table}

All components are additive---they implement existing interfaces (\texttt{kem.KEM}, \texttt{Transaction}, \texttt{crypto/rand}, \texttt{Transport.Connection}) without modifying production code.

% ============================================================================
\section{Competitive Analysis}
% ============================================================================

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}lcccc@{}}
\toprule
\textbf{Capability} & \textbf{Ours} & \textbf{QAN} & \textbf{IOTA} & \textbf{Algorand} \\
\midrule
PQ signatures (prod) & \checkmark & Planned & -- & Partial \\
PQ key exchange (prod) & \checkmark & -- & -- & -- \\
Threshold PQ (Corona) & \checkmark & -- & -- & -- \\
QKD integration & Design & -- & -- & -- \\
Quantum sensing & Design & -- & -- & -- \\
Triple-hybrid KDF & Design & -- & -- & -- \\
Mesh/DDIL transport & \checkmark & -- & Partial & -- \\
Zero-trust fabric & \checkmark & -- & -- & -- \\
\bottomrule
\end{tabular}
\caption{Competitive landscape: no competitor has PQ consensus, let alone QKD/sensing.}
\label{tab:competitive}
\end{table}

% ============================================================================
\section{Conclusion}
% ============================================================================

We have presented an architecture for integrating quantum key distribution and quantum sensing into a production post-quantum blockchain stack. The triple-hybrid key derivation---combining classical ECDH, lattice-based KEM, and physics-layer QKD---provides defense-in-depth across three independent security foundations.

The architecture is uniquely feasible because the production stack already provides the integration surfaces: a pluggable KEM interface for QKD keys, a QuantumVM for sensor attestations, a mesh transport for DDIL deployment, and a zero-trust fabric for QKD-authenticated channels. The estimated 5,000 lines of new code leverage these existing interfaces without modifying production systems.

No competing blockchain or military networking system offers this combination of production post-quantum cryptography, QKD integration architecture, and quantum sensor attestation---let alone over a delay-tolerant mesh network operating on LoRa, packet radio, and satellite links.

% ============================================================================
\begin{thebibliography}{20}

\bibitem{fips203} NIST, ``ML-KEM Standard,'' FIPS 203, 2024.

\bibitem{fips204} NIST, ``ML-DSA Standard,'' FIPS 204, 2024.

\bibitem{fips205} NIST, ``SLH-DSA Standard,'' FIPS 205, 2024.

\bibitem{cnsa2} NSA, ``CNSA Suite 2.0,'' 2022.

\bibitem{etsi014} ETSI, ``QKD; Protocol and data format of REST-based key delivery API,'' GS QKD 014 V1.1.1, 2019.

\bibitem{etsi004} ETSI, ``QKD; Application Interface,'' GS QKD 004 V2.1.1, 2020.

\bibitem{ituy3800} ITU-T, ``Overview on Networks Supporting Quantum Key Distribution,'' Y.3800, 2019.

\bibitem{ituy3802} ITU-T, ``Quantum Key Distribution Networks -- Functional Architecture,'' Y.3802, 2020.

\bibitem{nist90b} NIST, ``Recommendation for the Entropy Sources Used for Random Bit Generation,'' SP 800-90B, 2018.

\bibitem{bb84} C. Bennett, G. Brassard, ``Quantum Cryptography: Public Key Distribution and Coin Tossing,'' TCS 2014 (orig.\ 1984).

\bibitem{tfqkd} M. Lucamarini \etal, ``Overcoming the Rate-Distance Limit of QKD without Quantum Repeaters,'' Nature 557, 2018.

\bibitem{micius} S.-K. Liao \etal, ``Satellite-to-Ground Quantum Key Distribution,'' Nature 549, 2017.

\bibitem{qkdblockchain} ``Quantum Secured Blockchain Framework,'' Nature Scientific Reports, 2025.

\bibitem{tfqkdbc} ``Protecting Distributed Blockchain with Twin-Field QKD,'' arXiv:2603.14826, 2026.

\bibitem{corona} ``Practical Two-Round Threshold Signature from LWE,'' IACR ePrint 2024/1113.

\bibitem{quasar} Hanzo Team, ``Quasar Consensus,'' Hanzo, 2025.

\bibitem{infleqtion} Infleqtion, ``Tiqker Quantum Atomic Clock,'' CES 2026.

\bibitem{shamir} A. Shamir, ``How to Share a Secret,'' CACM, 1979.

\end{thebibliography}

\section*{Reproducibility}
\textbf{Source code.} \texttt{github.com/hanzoai/crypto} (commit \texttt{TBD}).\\
\textbf{Build.} cargo build --release; hardware integration TBD on QKD/atomic-clock partners.\\
\textbf{Hardware tested.} QKD hardware: vendor-supplied; classical post-processing on x86\_64 Linux.\\
\textbf{Standards referenced.} ETSI QKD, NIST PQC, FIPS 203/204.\\
\textbf{Contact.} [email protected].

\end{document}