papers/lux-sovereign-keys/sections/06-security-analysis.tex

\section{Security Analysis}

\label{sec:security}

\subsection{Post-Quantum Security}

ML-KEM-1024 provides IND-CCA2 security under the Module Learning With
Errors (MLWE) assumption at NIST Security Level 5 \cite{fips203}.  This
means a quantum adversary with access to a cryptographically relevant
quantum computer cannot distinguish ML-KEM ciphertexts from random, and
therefore cannot recover shared secrets or DEKs.

ML-DSA-87 provides EUF-CMA security under the Module Short Integer
Solution (MSIS) and MLWE assumptions at NIST Security Level 5 \cite{fips204}.

\begin{theorem}[Post-Quantum Confidentiality]
Under the MLWE assumption with parameters as specified in FIPS 203 for
ML-KEM-1024, the probability that a quantum polynomial-time adversary
$\mathcal{A}$ can distinguish the encryption of a chosen message from
random is:
\[
  \text{Adv}^{\text{IND-CCA2}}_{\text{ML-KEM-1024}}(\mathcal{A}) \leq \text{negl}(\lambda)
\]
where $\lambda$ is the security parameter (256 bits for Level 5).
\end{theorem}

\subsection{Forward Secrecy}

Each envelope uses a fresh ML-KEM encapsulation, producing an ephemeral
shared secret.  Compromise of the recipient's long-term private key
enables decryption of past envelopes (the encapsulated keys are stored
alongside ciphertexts).  True forward secrecy requires an interactive
protocol (e.g., Signal's X3DH adapted for ML-KEM), which is out of
scope for this document but planned for the Lux secure messaging layer
\cite{lux-messaging}.

For vault-level forward secrecy, periodic key rotation is supported:
the vault DEK is re-generated, all documents are re-encrypted, and the
old ML-KEM key pair is destroyed.

\subsection{Metadata Protection}

The sync protocol transmits encrypted envelopes.  The provider observes:
\begin{itemize}[nosep]
  \item Envelope size (mitigated by padding to fixed block sizes).
  \item Timing of uploads/downloads (mitigated by batching).
  \item Public keys of recipients (inherent to ML-KEM; mitigated by
        using ephemeral recipient identifiers).
\end{itemize}

The provider does not observe: plaintext content, file names, document
types, or the relationship between documents within a vault.

\subsection{Revocation}

Access revocation uses on-chain capability tokens.  Each vault access
grant is represented by an on-chain token.  Revoking access burns the
token.  The revoked party still holds the encapsulated key blob from
the previous sharing, but:
\begin{enumerate}[nosep]
  \item The vault DEK is rotated after revocation.
  \item All documents are re-encrypted with the new DEK.
  \item New envelopes are encapsulated only to remaining authorized keys.
\end{enumerate}

The revoked party retains access to data encrypted before revocation
(this is inherent to any system where decryption keys were previously
distributed).  Preventing access to historical data requires re-encryption
with key exclusion, which is performed automatically on revocation.

\subsection{Security Level Summary}

\begin{table}[h]
\centering
\small
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Threat} & \textbf{Protection} & \textbf{Assumption} \\
\midrule
Quantum key recovery       & ML-KEM-1024 Level 5 & MLWE hardness \\
Quantum signature forgery  & ML-DSA-87 Level 5   & MSIS + MLWE hardness \\
Brute-force root key       & Argon2id (64 MiB)   & Memory-hard \\
Threshold signing bypass   & CGGMP21/FROST $t$-of-$n$ & DLP on secp256k1/Ed25519 \\
Provider data access       & Envelope encryption  & Provider holds no keys \\
Single point of failure    & Social recovery      & $\geq t$ parties honest \\
\bottomrule
\end{tabular}
\caption{Threat-protection mapping.}
\label{tab:threats}
\end{table}

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