papers/hanzo-pq-crypto/sections/03-ml-kem-for-key-exchange.tex

\section{ML-KEM for Key Exchange}

\label{sec:mlkem}
% ============================================================================

ML-KEM (FIPS 203) replaces ECDH key exchange. It is based on the Module
Learning with Errors (MLWE) problem.

\begin{definition}[ML-KEM]
ML-KEM consists of three algorithms:
\begin{itemize}[leftmargin=1.1em]
    \item $\texttt{KeyGen}() \to (ek, dk)$: Generate encapsulation and
    decapsulation keys.
    \item $\texttt{Encaps}(ek) \to (K, c)$: Produce shared secret $K$ and
    ciphertext $c$.
    \item $\texttt{Decaps}(dk, c) \to K$: Recover shared secret from
    ciphertext.
\end{itemize}
\end{definition}

We deploy ML-KEM-768 (NIST Security Level 3, equivalent to AES-192):

\begin{table}[H]
\centering
\small
\begin{tabular}{lrrr}
\toprule
\textbf{Parameter} & \textbf{ML-KEM-768} & \textbf{X25519} & \textbf{Ratio} \\
\midrule
Public key (bytes) & 1,184 & 32 & 37$\times$ \\
Ciphertext (bytes) & 1,088 & 32 & 34$\times$ \\
Shared secret (bytes) & 32 & 32 & 1$\times$ \\
KeyGen ($\mu$s) & 28 & 48 & 0.6$\times$ \\
Encaps ($\mu$s) & 35 & 48 & 0.7$\times$ \\
Decaps ($\mu$s) & 32 & 48 & 0.7$\times$ \\
\bottomrule
\end{tabular}
\caption{ML-KEM-768 vs X25519 parameter comparison. ML-KEM is computationally
faster but has larger key/ciphertext sizes.}
\label{tab:mlkem}
\end{table}

\subsection{Hybrid Key Exchange}

During the transition period, we use hybrid key exchange combining X25519 and
ML-KEM-768:
\begin{equation}
K_{\text{hybrid}} = \texttt{HKDF-SHA256}(K_{\text{X25519}} \| K_{\text{ML-KEM}}),
\end{equation}
ensuring security if either scheme is broken. This follows the IETF hybrid
approach~\cite{hybridtls}.

\subsection{TLS Integration}

Hanzo Gateway~\cite{hanzogateway} implements hybrid TLS 1.3 with the
\texttt{X25519MLKEM768} named group:
\begin{enumerate}[leftmargin=1.4em]
    \item \texttt{ClientHello} includes both X25519 and ML-KEM-768 key shares
    (total 1,248 bytes vs.\ 32 bytes for X25519 alone).
    \item \texttt{ServerHello} includes both encapsulated keys.
    \item The handshake shared secret combines both derivations.
    \item Application data is encrypted with AES-256-GCM (quantum-safe at
    128-bit security via Grover's bound).
\end{enumerate}

\begin{remark}
The larger ClientHello (1,248 vs.\ 32 bytes) fits within a single TCP segment
and does not require an additional round trip. Measured TLS handshake overhead:
1.2ms additional latency (from 3.1ms to 4.3ms for a cold connection).
\end{remark}

\subsection{KMS Key Wrapping}

Hanzo KMS~\cite{hanzokms} envelope encryption currently wraps data encryption
keys (DEKs) using ECDH-derived keys. The post-quantum migration replaces the
key wrapping:
\begin{enumerate}[leftmargin=1.4em]
    \item Master KEK is derived via ML-KEM encapsulation.
    \item DEK encryption uses AES-256-GCM with the ML-KEM-derived key.
    \item Existing secrets are re-wrapped during the next rotation cycle
    (within 90 days per KMS rotation policy).
\end{enumerate}

% ============================================================================