whitepaper.tex

\documentclass[10pt,twocolumn]{article}

\usepackage[margin=0.75in,top=1in,bottom=1in]{geometry}
\usepackage{amsmath,amssymb}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{listings}
\usepackage{booktabs}
\usepackage{tikz}
\usepackage{bytefield}
\usepackage{xcolor}
\usepackage{algorithm}
\usepackage{algpseudocode}
\usepackage{enumitem}
\usepackage{fancyhdr}
\usepackage{titlesec}
\usepackage{abstract}
\usepackage{authblk}
\usepackage{microtype}
\usepackage{parskip}
\usepackage{caption}
\usepackage{float}

\usetikzlibrary{arrows.meta,positioning,shapes.geometric,fit,calc}

% tight lists
\setlist{nosep,leftmargin=1.2em}

% compact captions
\captionsetup{font=small,labelfont=bf,skip=6pt}

% section formatting - bold, slightly larger
\titleformat{\section}{\large\bfseries}{\thesection.}{0.5em}{}
\titleformat{\subsection}{\normalsize\bfseries}{\thesubsection}{0.5em}{}
\titlespacing*{\section}{0pt}{1.5ex plus 0.5ex}{0.8ex plus 0.2ex}
\titlespacing*{\subsection}{0pt}{1.2ex plus 0.3ex}{0.5ex plus 0.1ex}

% abstract formatting
\renewcommand{\abstractnamefont}{\normalfont\bfseries\small}
\renewcommand{\abstracttextfont}{\normalfont\small}

% code style
\definecolor{codegreen}{rgb}{0.2,0.6,0.2}
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
\definecolor{codepurple}{rgb}{0.58,0,0.82}
\definecolor{backcolour}{rgb}{0.97,0.97,0.97}

\lstdefinestyle{whispr}{
    backgroundcolor=\color{backcolour},
    commentstyle=\color{codegreen},
    keywordstyle=\color{codepurple},
    numberstyle=\tiny\color{codegray},
    basicstyle=\ttfamily\scriptsize,
    breaklines=true,
    frame=single,
    framerule=0.4pt,
    rulecolor=\color{codegray},
    aboveskip=6pt,
    belowskip=6pt,
}
\lstset{style=whispr}

\hypersetup{
    colorlinks=true,
    linkcolor=blue!60!black,
    citecolor=blue!60!black,
    urlcolor=blue!60!black,
}

% header/footer
\pagestyle{fancy}
\fancyhf{}
\fancyhead[L]{\small\textit{whispr: post-quantum group encryption with amortized MLS}}
\fancyhead[R]{\small\thepage}
\renewcommand{\headrulewidth}{0.4pt}

% ============================================================================
% title block
% ============================================================================

\title{%
    \vspace{-1.5em}%
    \LARGE\textbf{whispr: Post-Quantum Group Encryption\\
    with Amortized MLS}\\[0.3em]
    \normalsize Protocol Specification v1.0.0
}

\author[1]{whispr project}
\affil[1]{\small\texttt{https://github.com/whisprchat}}
\date{\small March 2026}

\begin{document}

\twocolumn[
    \maketitle
    \thispagestyle{empty}

    \begin{onecolabstract}
    \noindent
    whispr is a decentralized, end-to-end encrypted messaging system built on
    \textbf{amortized post-quantum MLS} (APQ-MLS) --- a hybrid protocol that
    combines a post-quantum MLS session (ML-KEM-768, ML-DSA-65) with a
    traditional MLS session (DHKEM X25519, Ed25519) linked via periodic PSK
    export. messages are encrypted in the traditional session for efficiency,
    while the PQ session provides quantum-resistant key material at a
    configurable amortization ratio (default 1:50). the system uses
    \textbf{sealed sender} via BBS+ anonymous credentials to hide message
    authorship from the relay, a \textbf{hybrid PQ transport} combining
    ML-KEM-768 and X25519 for relay connections, and \textbf{SHA3-256
    fingerprints} over composite key bundles for identity verification.
    the protocol supports encrypted message editing, deletion, emoji reactions,
    typing indicators, a capability-based permission model, direct messages,
    multi-relay federation, and a server discovery directory.
    all wire communication uses CBOR encoding over hybrid-encrypted TCP
    connections. this paper specifies the APQ-MLS cryptographic protocol,
    sealed sender construction, wire format, transport security, relay
    architecture, identity system, and trust model.

    \vspace{0.5em}
    \noindent\textbf{Keywords:} post-quantum cryptography, MLS, ML-KEM,
    ML-DSA, group encryption, sealed sender, BBS+, anonymous credentials,
    forward secrecy, post-compromise security, SHA3, CBOR
    \end{onecolabstract}
    \vspace{1.5em}
]

% ============================================================================
\section{Introduction}
\label{sec:intro}
% ============================================================================

Secure group messaging requires balancing forward secrecy, post-compromise
security, group membership changes, and practical performance. The emergence
of cryptographically relevant quantum computers threatens all protocols built
on classical assumptions alone.

\textbf{Signal Protocol (Sender Keys).} Signal's group messaging uses sender
keys --- each sender maintains a symmetric ratchet chain shared with all group
members. This provides forward secrecy within a sender's chain but not across
senders. A compromised sender key reveals all future messages from that sender
until re-keying occurs~\cite{signal-sender-keys}.

\textbf{MLS/TreeKEM.} The Messaging Layer Security protocol (RFC~9420) uses
tree-based key agreement (TreeKEM) to achieve $O(\log N)$ key updates with
strong forward secrecy and post-compromise security. However, the base
specification uses only classical primitives (DHKEM, Ed25519/ECDSA), leaving
it vulnerable to harvest-now-decrypt-later attacks by quantum
adversaries~\cite{mls-rfc9420}.

\textbf{Post-quantum MLS.} Replacing MLS's KEM with ML-KEM (FIPS~203) and
signatures with ML-DSA (FIPS~204) provides quantum resistance, but at
significant cost: ML-KEM-768 ciphertexts are ${\sim}1,088$ bytes (vs.\ 32
for X25519), and ML-DSA-65 signatures are ${\sim}3,309$ bytes (vs.\ 64 for
Ed25519). Fully post-quantum MLS commits are $5{-}10\times$ larger than
classical ones.

\textbf{APQ-MLS (this work).} Amortized post-quantum MLS, based on the
construction of Hale et~al.~\cite{apq-mls-paper}, addresses this by
maintaining two parallel MLS sessions:

\begin{itemize}
    \item \textbf{Session A (PQ):} ML-KEM-768 for KEM, ML-DSA-65 for signing,
        AES-256-GCM for AEAD. Provides quantum-resistant key material.
    \item \textbf{Session B (traditional):} DHKEM X25519, Ed25519,
        ChaCha20-Poly1305. Handles all application messages.
\end{itemize}

Periodically (every $R$ commits, default $R=50$), session~A performs a
\emph{full update}: commit, export \texttt{exporter\_secret} as a PSK, and
inject it into session~B via an external PSK proposal + commit. Between full
updates, session~B performs \emph{partial updates} (standard TreeKEM commits)
that provide classical forward secrecy and PCS.

This yields:
\begin{itemize}
    \item \textbf{Post-quantum confidentiality} (amortized) --- PQ key
        material flows into session~B every $R$ epochs
    \item \textbf{$O(\log N)$ overhead per commit} --- TreeKEM scaling
        replaces the previous $O(N)$ per-message wrapping
    \item \textbf{Configurable security/performance tradeoff} --- lower $R$
        means more frequent PQ updates at higher bandwidth cost
    \item \textbf{Sealed sender} --- BBS+ anonymous credentials hide message
        authorship from the relay
    \item \textbf{Hybrid PQ transport} --- ML-KEM-768 + X25519 handshake
        for relay connections
\end{itemize}

The amortization ratio $R=50$ is optimal per the analysis in~\cite{apq-mls-paper}
(section~4), providing quantum resistance with only ${\sim}2\%$ bandwidth
overhead compared to purely classical MLS.

% ============================================================================
\section{System Architecture}
\label{sec:arch}
% ============================================================================

whispr consists of four components (Figure~\ref{fig:arch}): a desktop client
(React + Tauri + Rust sidecar), a relay server for message fan-out, and an
identity server for authentication and profiles.

\begin{figure}[t]
\centering
\begin{tikzpicture}[
    component/.style={draw, rounded corners=4pt, minimum width=2.4cm,
        minimum height=0.85cm, align=center, font=\scriptsize,
        line width=0.5pt},
    server/.style={component, fill=gray!8},
    client/.style={component, fill=blue!5},
    arrow/.style={-{Stealth[length=2.5mm]}, semithick, color=black!60},
    lbl/.style={font=\tiny\sffamily, midway, fill=white, inner sep=1.5pt},
    scale=0.88, transform shape,
]
    \node[client] (react) at (0,1.6) {React frontend\\[-1pt]\tiny Zustand stores};
    \node[client] (tauri) at (0,0) {Tauri 2.0\\[-1pt]\tiny Rust shell};
    \node[client, fill=blue!12] (sidecar) at (0,-1.6)
        {Rust sidecar\\[-1pt]\tiny APQ-MLS + BBS+};

    \node[server] (relay) at (5,0.4) {Relay server\\[-1pt]\tiny sealed fan-out};
    \node[server] (identity) at (5,-1.2) {Identity server\\[-1pt]\tiny auth + KeyPkgs};

    \node[draw, dashed, rounded corners=5pt, color=black!40,
        fit=(tauri)(react)(sidecar), inner sep=7pt,
        label={[font=\sffamily\tiny, color=black!50]above:desktop client}] {};

    \draw[arrow] (react) -- (tauri) node[lbl, right] {invoke};
    \draw[arrow] (tauri) -- (sidecar) node[lbl, right] {JSON-lines};
    \draw[arrow, <->] (sidecar.east) -- ++(0.5,0) |- (relay.west)
        node[lbl, above, pos=0.3] {CBOR/TCP};
    \draw[arrow, <->] (sidecar.east) -- ++(0.5,0) |- (identity.west)
        node[lbl, below, pos=0.3] {HTTP/JSON};
\end{tikzpicture}
\caption{System architecture.  Cryptographic keys never leave the Rust
sidecar process.  The relay is metadata-blind (sealed sender); it verifies
BBS+ membership proofs but cannot identify the sender.}
\label{fig:arch}
\end{figure}

\subsection{Desktop Client}

The desktop application uses a three-layer architecture:

\begin{enumerate}
    \item \textbf{React frontend} --- thin UI layer using Zustand for state
        management across composable store slices (identity, groups, channels,
        messages, members, connection, UI, status, typing, notifications,
        backend operations). Communicates with the Rust shell via Tauri's
        \texttt{invoke()} API.

    \item \textbf{Tauri 2.0 shell} --- Rust process that spawns the sidecar
        as a subprocess and bridges IPC. Uses macro-generated command wrappers
        for type-safe invocation.

    \item \textbf{Rust sidecar} --- handles all cryptographic operations
        (APQ-MLS sessions, sealed sender credentials, PQ transport), relay
        connections, state management, and persistence via JSON-lines over
        stdin/stdout.
\end{enumerate}

The sidecar architecture ensures that cryptographic keys never enter the
frontend process. On startup, the sidecar performs automatic setup: if a
persisted identity exists, it performs challenge-response login, connects to
the relay via hybrid PQ handshake, replays stored state from SQLite, subscribes
to all known groups, and emits \texttt{auth:ready} and
\texttt{connection:status} events.

\subsection{Relay Server}

The relay is a metadata-blind fan-out server. It accepts hybrid PQ-encrypted
TCP connections, stores sealed entries grouped by topic (group UUID), and
broadcasts new entries to all subscribers. The relay cannot decrypt message
content \emph{or} determine message authorship --- it verifies only BBS+
group membership proofs. The relay maintains its own Ed25519 keypair for
transport authentication, persisted to \texttt{relay-key.bin}.

\textbf{MaybeNot compatibility.} The wire format includes padding fields
for future traffic analysis defense via the MaybeNot
framework~\cite{maybenot}. Message size classes enable traffic shaping
without protocol changes.

\subsection{Identity Server}

The identity server provides user registration, Ed25519 challenge-response
authentication, composite key bundle distribution (Ed25519 + ML-DSA-65 +
ML-KEM-768), MLS KeyPackage upload/fetch, user profiles, avatars, presence
status, device management, and a server discovery directory over HTTP/JSON.

% ============================================================================
\section{Cryptographic Protocol: APQ-MLS}
\label{sec:apq}
% ============================================================================

Amortized post-quantum MLS builds on the Messaging Layer Security protocol
(RFC~9420~\cite{mls-rfc9420}) with dual parallel sessions linked by PSK
export, per the construction of Hale et~al.~\cite{apq-mls-paper}.

\subsection{Identity and Key Bundles}
\label{sec:identity}

Each user generates a composite key bundle on registration:

\begin{enumerate}
    \item \textbf{Ed25519 signing key} (RFC~8032~\cite{rfc8032}) --- 32-byte
        seed producing a 32-byte public key. Serves as the persistent identity
        and is used for challenge-response authentication.
    \item \textbf{ML-DSA-65 signing key} (FIPS~204~\cite{fips204}) ---
        post-quantum lattice-based signature. Verifying key is ${\sim}1,952$
        bytes; signing key is ${\sim}4,032$ bytes.
    \item \textbf{ML-KEM-768 KEM key} (FIPS~203~\cite{fips203}) ---
        post-quantum lattice-based key encapsulation. Encapsulation key is
        ${\sim}1,184$ bytes; decapsulation key is ${\sim}2,400$ bytes.
\end{enumerate}

The key bundle is distributed via the identity server. Each user also
generates MLS KeyPackages for both ciphersuites:

\begin{itemize}
    \item \textbf{PQ KeyPackage:} ML-KEM-768 HPKE init key, ML-DSA-65
        signature, AES-256-GCM AEAD
    \item \textbf{Traditional KeyPackage:} DHKEM X25519 init key, Ed25519
        signature, ChaCha20-Poly1305 AEAD
\end{itemize}

KeyPackages are uploaded to the identity server and consumed on use (one-time).

\subsection{SHA3 Fingerprints}
\label{sec:fingerprint}

Identity verification uses a SHA3-256 fingerprint computed over the full
composite key bundle:

\begin{equation}
    \text{FP} = \text{SHA3-256}(\mathit{pk}_{\text{ed}} \| \mathit{pk}_{\text{dsa}}
        \| \mathit{pk}_{\text{kem}})
\end{equation}

\noindent where $\mathit{pk}_{\text{ed}}$ is the Ed25519 public key,
$\mathit{pk}_{\text{dsa}}$ is the ML-DSA-65 verifying key, and
$\mathit{pk}_{\text{kem}}$ is the ML-KEM-768 encapsulation key.

The fingerprint is displayed as the first 32 hex characters grouped in
4-character blocks:

\begin{center}
\small\texttt{XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX}
\end{center}

Users verify fingerprints out-of-band to detect identity server MITM attacks.
The fingerprint binds all three key types, so substituting any single key
produces a completely different fingerprint.

\subsection{APQ Dual-Session Architecture}
\label{sec:dual-session}

The core of the protocol is two parallel MLS groups maintained for each
whispr group (Figure~\ref{fig:apq}):

\begin{figure}[t]
\centering
\begin{tikzpicture}[
    session/.style={draw, rounded corners=5pt, minimum width=3cm,
        minimum height=1.5cm, align=center, font=\scriptsize,
        line width=0.6pt},
    arrow/.style={-{Stealth[length=2.5mm]}, semithick},
    scale=0.88, transform shape,
]
    % session boxes
    \node[session, fill=blue!8, text=black] (pq) at (0,0) {%
        \textbf{Session A} (PQ)\\[2pt]
        {\tiny KEM:} {\tiny ML-KEM-768}\\
        {\tiny Sig:} {\tiny ML-DSA-65}\\
        {\tiny AEAD:} {\tiny AES-256-GCM}};
    \node[session, fill=green!8, text=black] (trad) at (5,0) {%
        \textbf{Session B} (trad)\\[2pt]
        {\tiny KEM:} {\tiny DHKEM X25519}\\
        {\tiny Sig:} {\tiny Ed25519}\\
        {\tiny AEAD:} {\tiny ChaCha20-Poly1305}};

    % PSK arrow
    \draw[arrow, dashed, color=blue!70, line width=0.8pt]
        (pq.east) -- (trad.west)
        node[above, font=\tiny\sffamily, color=blue!80, pos=0.5]
            {PSK export}
        node[below, font=\tiny\itshape, color=black!50, pos=0.5]
            {every $R{=}50$ epochs};

    % labels below
    \node[font=\tiny\sffamily, color=black!40, below=4pt of pq]
        {quantum-resistant keying};
    \node[font=\tiny\sffamily, color=black!40, below=4pt of trad]
        {application messages};

    % partial/full update annotations
    \draw[arrow, color=blue!50, line width=0.5pt]
        ([xshift=-4pt]pq.south west) ++(0,-0.55) --
        node[below, font=\tiny\sffamily, color=blue!60] {full update}
        ++(-0.8,0);
    \draw[arrow, color=green!60!black, line width=0.5pt]
        ([xshift=4pt]trad.south east) ++(0,-0.55) --
        node[below, font=\tiny\sffamily, color=green!60!black] {partial update}
        ++(0.9,0);
\end{tikzpicture}
\caption{APQ dual-session architecture.  Session~A exports PQ key
material into Session~B via PSK.  Full updates commit in both
sessions; partial updates advance Session~B only.}
\label{fig:apq}
\end{figure}

\textbf{Session A (PQ ciphersuite):}
\begin{itemize}
    \item KEM: ML-KEM-768 (NIST security level 3)
    \item Signature: ML-DSA-65 / Ed25519 (conf+auth mode)
    \item AEAD: AES-256-GCM
    \item Purpose: provide quantum-resistant key material
\end{itemize}

\textbf{Session B (traditional ciphersuite):}
\begin{itemize}
    \item KEM: DHKEM X25519
    \item Signature: Ed25519
    \item AEAD: ChaCha20-Poly1305
    \item Purpose: all application message encryption
\end{itemize}

\textbf{Full update} (every $R$ epochs):
\begin{enumerate}
    \item Session A performs \texttt{self\_update} (TreeKEM commit)
    \item Export: $\mathit{psk} \leftarrow \text{ExportSecret}(A,
        \texttt{"Combiner"}, \text{GroupContext}(A), 32)$
    \item Create \texttt{PreSharedKeyId} from $\mathit{psk}$
    \item Session B: \texttt{propose\_external\_psk}($\mathit{psk\_id}$)
    \item Session B: \texttt{commit\_to\_pending\_proposals}()
\end{enumerate}

\textbf{Partial update} (between full updates):
\begin{enumerate}
    \item Session B performs \texttt{self\_update} (standard TreeKEM commit)
    \item Provides classical forward secrecy and PCS
\end{enumerate}

\textbf{Amortization ratio:} Default $R = 50$ (one full commit per 50 partial
commits). This is the optimal ratio per~\cite{apq-mls-paper} section~4,
balancing PQ security refresh frequency against bandwidth overhead.

\textbf{Application messages:} Encrypted exclusively in session B using MLS
\texttt{create\_message()}. Recipients decrypt via their local session B state.
Sender identity is included in the MLS application message ciphertext.

\subsection{Group Operations}
\label{sec:group-ops}

All group operations use standard MLS mechanisms, replacing the previous
custom PRGE protocol:

\textbf{Member addition:}
\begin{enumerate}
    \item Fetch target user's PQ and traditional KeyPackages from identity
        server
    \item Session A: \texttt{add\_members}(PQ KeyPackages) $\rightarrow$
        (Commit, Welcome)
    \item Session B: \texttt{add\_members}(traditional KeyPackages)
        $\rightarrow$ (Commit, Welcome)
    \item Fan out both Welcome messages to the new member
    \item New member joins both sessions from their respective Welcomes
\end{enumerate}

This replaces the previous two-phase authenticated key exchange. MLS Welcome
messages contain all state needed to join, with $O(\log N)$ overhead from
TreeKEM (vs.\ $O(N)$ pairwise sessions in PRGE).

\textbf{Member removal:}
\begin{enumerate}
    \item Session A: \texttt{remove\_members}(leaf indices) $\rightarrow$
        Commit
    \item Session B: \texttt{remove\_members}(leaf indices) $\rightarrow$
        Commit
    \item Both sessions ratchet forward, excluding the removed member
\end{enumerate}

\textbf{Key update (PCS):}
\begin{enumerate}
    \item Any member performs \texttt{self\_update} on session B (partial)
    \item Periodically, the group owner triggers a full update via session A
\end{enumerate}

This replaces the previous ratchet step operations. TreeKEM self-updates
provide equivalent post-compromise security with $O(\log N)$ overhead.

% ============================================================================
\section{Sealed Sender}
\label{sec:sealed}
% ============================================================================

The sealed sender construction hides message authorship from the relay server
using BBS+ anonymous credentials~\cite{bbs-signatures}.

\subsection{Anonymous Credentials via BBS+}

\textbf{Credential issuance:}
\begin{enumerate}
    \item Group creator generates a BBS+ issuer keypair tied to the group UUID
    \item The issuer public key is stored on the relay, associated with the
        group
    \item On member addition (after MLS Welcome is processed), the group admin
        issues a BBS+ credential attesting group membership
    \item The credential is blinded --- it proves ``holder is a member of group
        $X$'' without revealing which member
\end{enumerate}

\textbf{Proof generation:}
\begin{itemize}
    \item Constant-size proofs (${\sim}200$ bytes) regardless of group size
    \item Zero-knowledge: relay learns nothing about the sender beyond valid
        group membership
    \item Unlinkable: multiple proofs from the same member cannot be correlated
\end{itemize}

\subsection{Sealed Entry Format}
\label{sec:sealed-entry}

The previous \texttt{SignedEntry} format included the author's Ed25519 public
key in cleartext. The new \texttt{SealedEntry} removes this:

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Field} & \textbf{Old (SignedEntry)} & \textbf{New (SealedEntry)} \\
\midrule
ID & SHA-256 (32B) & SHA-256 (32B) \\
Author & Ed25519 pubkey (32B) & \emph{removed} \\
GroupMembershipProof & \emph{n/a} & BBS+ ZK proof (${\sim}200$B) \\
Content & CBOR payload & MLS ciphertext \\
CreatedAt & Unix timestamp (8B) & Unix timestamp (8B) \\
Signature & Ed25519 (64B) & \emph{removed} \\
\bottomrule
\end{tabular}
\caption{Entry format comparison. Sender identity moves inside MLS ciphertext.}
\label{tab:entry-format}
\end{table}

Sender identity is placed inside the MLS application message ciphertext.
Only group members who successfully decrypt the MLS message learn the author.
The relay sees only the BBS+ group membership proof and the encrypted content.

MLS provides internal authentication via TreeKEM --- each message is
authenticated by the sender's leaf node signature key, eliminating the need
for a separate Ed25519 signature on each entry.

\subsection{Relay Verification}

\begin{enumerate}
    \item Client publishes a \texttt{SealedEntry} with a BBS+ membership proof
    \item Relay looks up the group's BBS+ issuer public key
    \item Relay verifies the ZK proof: valid $\rightarrow$ accept and fan out;
        invalid $\rightarrow$ reject with error 403
    \item Relay cannot determine \emph{which} member sent the entry
    \item Subscription also requires a valid BBS+ credential proof
\end{enumerate}

% ============================================================================
\section{Member Addition}
\label{sec:member-add}
% ============================================================================

Adding a member to a group involves identity resolution, MLS Welcome messages
for both sessions, BBS+ credential issuance, and a capability grant:

\begin{algorithm}[H]
\caption{Member addition flow (APQ-MLS)}
\label{alg:member-add}
\begin{algorithmic}[1]
\Statex \textbf{Initiator} (group admin):
\State $\mathit{KB}_R \leftarrow \text{IdSrv.Lookup}(\mathit{handle})$
\State $\mathit{KP}_{pq} \leftarrow \text{IdSrv.FetchKP}(\mathit{handle}, \text{PQ})$
\State $\mathit{KP}_{st} \leftarrow \text{IdSrv.FetchKP}(\mathit{handle}, \text{trad})$
\State $(C_A, W_A) \leftarrow \text{SessA.Add}(\mathit{KP}_{pq})$
\State $(C_B, W_B) \leftarrow \text{SessB.Add}(\mathit{KP}_{st})$
\State $\mathit{cred} \leftarrow \text{BBS+.Issue}(\mathit{isk}, \mathit{PK}_R, \mathit{grp})$
\State publish $W_A, W_B, C_A, C_B, \mathit{cred}$
\State publish \texttt{Capability}($\mathit{group}$, read/write access)
\Statex
\Statex \textbf{New member} (joining):
\State join session A from $W_A$
\State join session B from $W_B$
\State store BBS+ credential for future sealed sending
\State begin participating in encrypted group messaging
\end{algorithmic}
\end{algorithm}

After completion, the new member has both MLS session states and a BBS+
credential for sealed sending. The entire flow is a single round-trip
(vs.\ the previous two-phase key exchange).

% ============================================================================
\section{Message Operations}
\label{sec:msg-ops}
% ============================================================================

Beyond sending and receiving, the protocol supports editing, deleting, and
reacting to messages. All mutable operations reference a target message by
its entry ID (32-byte SHA-256 hash).

\subsection{Message Encryption}

Group message encryption uses MLS session B:

\begin{algorithm}[H]
\caption{Group message encryption (APQ-MLS)}
\label{alg:msg}
\begin{algorithmic}[1]
\Function{SendMessage}{$\mathit{pt}, \mathit{group}$}
    \State $\mathit{payload} \leftarrow \text{CBOR}(\mathit{author\_id} \| \mathit{pt})$
    \State $\mathit{ct} \leftarrow \text{SessionB.CreateMessage}(\mathit{payload})$
    \State $\mathit{proof} \leftarrow \text{BBS+.Prove}(\mathit{cred}, \mathit{group})$
    \State publish \texttt{SealedEntry}($\mathit{ct}, \mathit{proof}$)
\EndFunction
\Statex
\Function{ReceiveMessage}{$\mathit{ct}, \mathit{proof}$}
    \State $\mathit{payload} \leftarrow \text{SessionB.ProcessMessage}(\mathit{ct})$
    \State $(\mathit{author}, \mathit{pt}) \leftarrow \text{CBOR.Decode}(\mathit{payload})$
    \State \Return $(\mathit{author}, \mathit{pt})$
\EndFunction
\end{algorithmic}
\end{algorithm}

The author identity is inside the MLS ciphertext. The relay and any network
observer see only the BBS+ membership proof and encrypted content.

MLS provides $O(\log N)$ overhead per message (TreeKEM path), compared to
the previous $O(N)$ key envelope approach. A 50-member group produces
${\sim}6$ TreeKEM path nodes ($\lceil \log_2 50 \rceil$) vs.\ 49 key
envelopes.

\subsection{Message Editing}

Edits create a new \texttt{MessageEdit} operation referencing the original
entry ID. The new plaintext is encrypted as a fresh MLS application message.
Recipients locate the original message by \texttt{TargetID}, replace the
content, and set an \texttt{EditedAt} timestamp.

\subsection{Message Deletion}

Deletions create a \texttt{MessageDelete} operation with the target entry ID.
No content is included. Recipients mark the message as deleted and clear
the decrypted text. The original sealed entry remains in relay storage.

\subsection{Reactions}

Reactions create a \texttt{Reaction} operation with the target entry ID, an
emoji string, and a boolean \texttt{Remove} flag. Reactions are encrypted
within MLS application messages (unlike the previous protocol where reactions
were unencrypted). The author of the reaction is revealed only to group
members upon decryption.

% ============================================================================
\section{Capabilities}
\label{sec:capabilities}
% ============================================================================

The protocol includes a capability-based permission model. A
\texttt{Capability} operation grants specific permissions to a user:

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}lp{5cm}@{}}
\toprule
\textbf{Field} & \textbf{Description} \\
\midrule
TargetEntityType & entity type this capability applies to
    (Group, Channel, Identity, etc.) \\
TargetEntityUUID & scope --- a group UUID grants access to all
    channels within that group \\
AllowedOperations & list of permitted operation types
    (Read, Create, Update, Delete) \\
AuthorConstraint & \texttt{SELF} (own content only) or
    \texttt{ALL} (any content) \\
ValidUntil & optional expiry timestamp (uint64) \\
Grantor & UserID of the member granting the capability \\
\bottomrule
\end{tabular}
\caption{Capability fields}
\label{tab:capability}
\end{table}

During member invitation (\S\ref{sec:member-add}), the initiator publishes
a capability granting read and write access to the group, its channels, and
identity operations. Capabilities are sealed entries like all other operations,
providing an auditable permission trail.

% ============================================================================
\section{Direct Messages}
\label{sec:dm}
% ============================================================================

Direct messages (DMs) are implemented as two-member groups with a
\texttt{DirectMessage} flag. The creation flow:

\begin{enumerate}
    \item Check for existing DM group between the two users (handles
        sorted alphabetically for deterministic deduplication).
    \item If none exists, create a new group with \texttt{DirectMessage=true}
        and a single default channel.
    \item Create dual MLS sessions (PQ + traditional) and issue BBS+
        credentials to both members.
\end{enumerate}

DM groups use the same APQ-MLS encryption as regular groups but with exactly
two members. The UI hides invite, publish, and server discovery features for
DM groups.

% ============================================================================
\section{Wire Protocol}
\label{sec:wire}
% ============================================================================

All protocol data is serialized using CBOR
(RFC~8949~\cite{cbor-rfc8949}) with integer keys for compactness.

\subsection{Sealed Entries}

The fundamental protocol unit is the \textbf{SealedEntry}:

\begin{align}
    \text{ID} &= \text{SHA-256}(\mathit{proof} \| \mathit{content}
        \| \mathit{ts}_{\text{LE8}}) \\
    \text{GroupMembershipProof} &= \text{BBS+.Prove}(\mathit{cred}, \mathit{group})
\end{align}

No author field in cleartext. No separate signature (MLS provides internal
authentication). The relay verifies the BBS+ proof before storing.

\subsection{Operation Structure}

An entry's content is MLS ciphertext. Once decrypted by group members, the
plaintext is a CBOR-encoded \textbf{Operation} with two discriminators:

\begin{itemize}
    \item \textbf{OperationType:} Read, Create, Update, Delete
    \item \textbf{EntityType:} Determines the payload schema
\end{itemize}

\subsection{Entity Type Specifications}

\begin{table}[H]
\centering
\scriptsize
\begin{tabular}{@{}lp{4.2cm}@{}}
\toprule
\textbf{Entity} & \textbf{Key Fields} \\
\midrule
Group & GroupUUID, Name, Description, DirectMessage \\
Channel & GroupUUID, ChannelUUID, Name, Description \\
ChatMessage & GroupUUID, ChannelUUID, Plaintext (inside MLS ciphertext) \\
MlsWelcome & GroupUUID, Ciphersuite, Welcome (TLS-encoded) \\
MlsCommit & GroupUUID, Ciphersuite, Commit (TLS-encoded) \\
MlsProposal & GroupUUID, Ciphersuite, Proposal (TLS-encoded) \\
Identity & GroupUUID, Nickname, AvatarURL \\
StatusUpdate & GroupUUID, StatusEntry \\
Capability & Capabilities[] (see Table~\ref{tab:capability}) \\
Reaction & GroupUUID, ChannelUUID, TargetID, Emoji, Remove \\
MessageEdit & GroupUUID, ChannelUUID, TargetID, Plaintext \\
MessageDelete & GroupUUID, ChannelUUID, TargetID \\
\bottomrule
\end{tabular}
\caption{Entity types.  \texttt{KeyExchange} and \texttt{RatchetStep} removed;
MLS Welcome/Commit/Proposal replace them.}
\label{tab:entities}
\end{table}

Note: \texttt{KeyEnvelope}, \texttt{KeyExchange}, and \texttt{RatchetStep}
entity types are removed. MLS handles key agreement internally via TreeKEM.

\subsection{Wire Message Types}

Client-relay communication uses tagged CBOR messages:

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}cll@{}}
\toprule
\textbf{Tag} & \textbf{Type} & \textbf{Description} \\
\midrule
1 & Handshake & hybrid PQ transport handshake \\
2 & Encrypted & encrypted wrapper \\
3 & Subscribe & join group (with BBS+ proof) \\
4 & Unsubscribe & leave group topic \\
5 & Publish & store + broadcast (sealed entry) \\
6 & Sync & request history \\
7 & EntryNotify & new entry broadcast \\
8 & SyncResponse & history batch \\
9 & Error & error response \\
10 & TypingIndicator & ephemeral typing \\
\bottomrule
\end{tabular}
\caption{Wire message types (CBOR integer keys)}
\label{tab:wire}
\end{table}

Key changes from the previous protocol:
\begin{itemize}
    \item \textbf{Handshake:} Now includes PQ ciphertext and PQ public key
        fields for hybrid ML-KEM + X25519 key exchange
    \item \textbf{Subscribe:} Now requires a BBS+ group membership proof
    \item \textbf{Publish:} Accepts \texttt{SealedEntry} (no author/signature
        in cleartext)
\end{itemize}

\subsection{IPC Protocol}

The Rust sidecar communicates with the Tauri shell via JSON-lines over
stdin/stdout:

\begin{lstlisting}[language={},xleftmargin=0pt]
req:   {"id":"r1","method":"send_message",
        "params":{...}}
resp:  {"id":"r1","result":{...}}
event: {"event":"message:received",
        "data":{...}}
\end{lstlisting}

Requests are correlated by ID (monotonic counter). Events are unsolicited
pushes from the sidecar. The Tauri shell routes responses to pending
callers via oneshot channels and forwards events to the React frontend
via the Tauri event system.

\textbf{IPC methods} (36 total):

\begin{table}[H]
\centering
\scriptsize
\begin{tabular}{@{}lp{4.5cm}@{}}
\toprule
\textbf{Category} & \textbf{Methods} \\
\midrule
Auth & register, login, get\_identity \\
Relay & connect\_relay, disconnect\_relay, connection\_status \\
Groups & create\_group, list\_groups, update\_group, join\_group \\
Channels & create\_channel, list\_channels \\
Messages & send\_message, get\_messages, edit\_message, delete\_message, search\_messages \\
Reactions & add\_reaction, remove\_reaction \\
Members & invite\_member, list\_members \\
Profile & set\_nickname, set\_status, get\_status, get\_bulk\_status, update\_profile, get\_user\_profile, get\_avatar\_url, upload\_avatar, get\_banner\_url, upload\_banner \\
Typing & send\_typing \\
Discovery & publish\_server, browse\_servers, get\_invite\_link \\
DMs & start\_dm \\
\bottomrule
\end{tabular}
\caption{Sidecar IPC method taxonomy (unchanged)}
\label{tab:ipc}
\end{table}

\textbf{Event types} pushed by the sidecar:

\begin{itemize}
    \item \texttt{message:received} --- new message in any subscribed group
    \item \texttt{message:edited} --- message edit applied
    \item \texttt{message:deleted} --- message marked deleted
    \item \texttt{message:reaction} --- reaction added/removed
    \item \texttt{connection:status} --- relay connection state change
    \item \texttt{group:updated} --- group metadata changed
    \item \texttt{typing:indicator} --- typing state from another user
    \item \texttt{auth:ready} --- auto-login completed
\end{itemize}

% ============================================================================
\section{Transport Security}
\label{sec:transport}
% ============================================================================

Client-relay communication is encrypted at the transport layer using a
hybrid post-quantum handshake, independent of APQ-MLS message-layer encryption.
This provides double encryption: transport-layer confidentiality protects
metadata (group UUIDs, subscription operations) while APQ-MLS protects
message content.

\subsection{Hybrid PQ Handshake}
\label{sec:handshake}

\begin{algorithm}[H]
\caption{Hybrid ML-KEM + X25519 transport handshake}
\label{alg:handshake}
\begin{algorithmic}[1]
\Statex \textbf{Client:}
\State $(x_c, X_c) \leftarrow \text{X25519.Gen}()$
\State $(dk_c, ek_c) \leftarrow \text{ML-KEM-768.KeyGen}()$
\State $\sigma_c \leftarrow \text{Ed25519.Sign}(sk_c, X_c \| ek_c)$
\State send $(PK_c, X_c, \sigma_c, ek_c)$
\Statex
\Statex \textbf{Server:}
\State verify $\sigma_c$
\State $(x_s, X_s) \leftarrow \text{X25519.Gen}()$
\State $(dk_s, ek_s) \leftarrow \text{ML-KEM-768.KeyGen}()$
\State $\sigma_s \leftarrow \text{Ed25519.Sign}(sk_s, X_s \| ek_s)$
\State $S_1 \leftarrow \text{ECDH}(x_s, X_c)$
\State $(ct_s, S_2) \leftarrow \text{ML-KEM.Encaps}(ek_c)$
\State send $(PK_s, X_s, \sigma_s, ek_s, ct_s)$
\Statex
\Statex \textbf{Client:}
\State verify $\sigma_s$
\State $S_1 \leftarrow \text{ECDH}(x_c, X_s)$
\State $S_2 \leftarrow \text{ML-KEM.Decaps}(dk_c, ct_s)$
\State $(ct_c, S_3) \leftarrow \text{ML-KEM.Encaps}(ek_s)$
\State send $ct_c$
\Statex
\Statex \textbf{Both:}
\State $S_3 \leftarrow \text{ML-KEM.Decaps}(dk_s, ct_c)$ \Comment{server}
\State $K \leftarrow \text{HKDF}(S_1 \| S_2 \| S_3,$
\Statex \hspace{2em}$\texttt{"whispr-transport-v2"}, \varnothing, 32)$
\end{algorithmic}
\end{algorithm}

The combined shared secret $K$ requires compromising \emph{both} X25519 and
ML-KEM to break --- an attacker with only a quantum computer (breaking X25519)
or only a classical computer (unable to break ML-KEM) cannot derive $K$.

\subsection{Message Framing}

After the handshake, all communication uses the \texttt{EncryptedConn}
wrapper. Each frame:

\vspace{-0.3em}
\begin{center}
\small
\begin{tabular}{|c|c|}
\hline
bytes 0--7 & bytes 8--$N$ \\
\hline
size (LE64) & AEAD-encrypted CBOR payload \\
\hline
\end{tabular}
\end{center}
\vspace{0.3em}

The symmetric cipher for transport encryption is XChaCha20-Poly1305
(extended nonce variant, 24-byte nonces).

\subsection{Nonce Construction}

The 24-byte nonce for XChaCha20-Poly1305 transport encryption:

\vspace{-0.3em}
\begin{center}
\small
\begin{tabular}{|c|c|c|}
\hline
bytes 0--7 & byte 8 & bytes 9--23 \\
\hline
counter (LE64) & direction & zero \\
\hline
\end{tabular}
\end{center}
\vspace{0.3em}

Direction: \texttt{0x00} = client$\rightarrow$server,
\texttt{0x01} = server$\rightarrow$client. This prevents nonce collision
when both sides share one key. Each side maintains an independent send
counter, incremented per message.

% ============================================================================
\section{Identity and Authentication}
\label{sec:identity-auth}
% ============================================================================

\subsection{Registration}

Users register with a handle (3--32 chars, regex
\texttt{\textasciicircum[a-z0-9\_]\{3,32\}\$}) and their full key bundle:
Ed25519 public key (32B), ML-DSA-65 verifying key (${\sim}1,952$B), and
ML-KEM-768 encapsulation key (${\sim}1,184$B). Handles are unique. The
identity server stores the composite key bundle and computes the SHA3-256
fingerprint.

\subsection{Challenge-Response Authentication}

Authentication remains Ed25519-based (the identity binding is the Ed25519
signing key):

\begin{enumerate}
    \item \textbf{Challenge:} Client sends handle. Server generates 32 random
        bytes, stores in-memory with 5-minute TTL.
    \item \textbf{Sign:} Client signs the challenge nonce with Ed25519
        private key.
    \item \textbf{Verify:} Server checks signature against account's Ed25519
        public key, consumes challenge, generates session token (32 random
        bytes, hex-encoded, 24-hour TTL).
\end{enumerate}

\subsection{KeyPackage Distribution}

\textbf{Upload:} \texttt{POST /api/users/\{handle\}/key-packages} ---
authenticated endpoint accepting TLS-serialized MLS KeyPackages. Clients
upload batches of KeyPackages for both ciphersuites (PQ and traditional).

\textbf{Fetch:} {\small\texttt{GET /api/users/\{handle\}/\allowbreak key-packages?ciphersuite=...}} ---
returns and \emph{consumes} one KeyPackage for the requested ciphersuite.
Consumed KeyPackages cannot be reused (one-time).

\subsection{Profiles and Avatars}

Users manage:
\begin{itemize}
    \item \textbf{Display name} and \textbf{bio} --- text fields, updated
        via authenticated PUT
    \item \textbf{Avatar} --- multipart upload, max 5~MB, JPEG/PNG/WebP,
        stored at \texttt{data/avatars/\{handle\}.\{ext\}}
    \item \textbf{Banner} --- same flow, max 10~MB
\end{itemize}

\subsection{Presence and Status}

Four status values: \texttt{online}, \texttt{idle}, \texttt{dnd},
\texttt{offline}. Each user may also set a free-text custom status.

\subsection{Device Management}

Each account can register multiple devices, each with its own Ed25519
public key, ML-DSA-65 key, ML-KEM-768 key, and UUID identifier.

% ============================================================================
\section{Relay Architecture}
\label{sec:relay}
% ============================================================================

\subsection{Metadata-Blind Fan-Out}

The relay is intentionally minimal and now metadata-blind for sender identity:

\begin{itemize}
    \item \textbf{Cannot} decrypt message content (no access to MLS keys)
    \item \textbf{Cannot} determine message authorship (sealed sender)
    \item \textbf{Can} see: group UUIDs, subscriber transport keys, message
        sizes, timing
    \item \textbf{Verifies} BBS+ group membership proofs on all published
        entries and subscriptions
    \item \textbf{Does not} enforce individual-level access --- confidentiality
        relies on MLS encryption; group-level access relies on BBS+ credentials
\end{itemize}

\subsection{Group Issuer Keys}

The relay stores BBS+ issuer public keys per group:

\begin{lstlisting}[language=SQL,xleftmargin=0pt]
CREATE TABLE group_issuer_keys (
  group_id   TEXT PRIMARY KEY,
  issuer_key BLOB NOT NULL,
  created_at INTEGER NOT NULL
);
\end{lstlisting}

When a group is created, the creator registers the BBS+ issuer public key
with the relay. All subsequent publish and subscribe operations for that group
must include a valid BBS+ proof verified against this key.

\subsection{Connection and Subscription}

The relay maintains two maps:

\begin{itemize}
    \item \texttt{clients[connID]} $\rightarrow$ Client --- all connected
        clients indexed by connection identifier (transport key hash, not
        identity key)
    \item \texttt{subscribers[groupUUID][connID]} $\rightarrow$ Client ---
        per-group subscription map
\end{itemize}

Subscription requires a BBS+ group membership proof. The relay verifies the
proof against the group's issuer public key before allowing subscription.

\subsection{Sync Protocol}

Clients request historical entries since a Unix timestamp. The relay
queries SQLite and returns a \texttt{SyncResponse} containing sealed entries
and a \texttt{hasMore} boolean for pagination.

\subsection{Typing Indicators}

Typing indicators (wire tag 10) are \textbf{ephemeral} --- the relay fans
them out to all group subscribers immediately without storing them. The relay
suppresses echo. Note: typing indicators reveal activity timing to the relay
but not sender identity (the sender field is inside the encrypted indicator).

\subsection{Multi-Relay Support}

Clients can connect to multiple relays simultaneously via a
\texttt{RelayManager} that routes operations based on group-to-relay
mappings. Each relay connection uses an independent hybrid PQ handshake.

\subsection{Persistence}

\begin{lstlisting}[language=SQL,xleftmargin=0pt]
CREATE TABLE entries (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  group_id   TEXT NOT NULL,
  payload    BLOB NOT NULL,
  created_at INTEGER NOT NULL
);
CREATE INDEX idx_entries_group_since
  ON entries(group_id, created_at);
\end{lstlisting}

Entries are stored as CBOR-encoded sealed entry blobs.

% ============================================================================
\section{Server Discovery}
\label{sec:discovery}
% ============================================================================

The identity server maintains a browsable directory of published groups.

\subsection{Publishing}

Group owners publish to the directory via \texttt{POST /api/servers} with
a server UUID, relay URL, name, and description. The authenticated user
becomes the owner.

\subsection{Browsing}

\texttt{GET /api/servers} supports keyword search (\texttt{q} parameter),
pagination (\texttt{limit} default 50, max 100; \texttt{offset}).

\subsection{Invite Links}

Groups generate invite links in the format
\texttt{whispr://relay:port/group\_uuid}. The join flow connects to the relay,
subscribes, syncs history, and processes MLS Welcome messages.

% ============================================================================
\section{Client Persistence}
\label{sec:persistence}
% ============================================================================

The Rust sidecar persists state to a local SQLite database (WAL mode).

\subsection{Schema}

\begin{lstlisting}[language=SQL,xleftmargin=0pt]
CREATE TABLE entries (
  id            BLOB(32) PRIMARY KEY,
  content       BLOB NOT NULL,
  created_at    INTEGER NOT NULL,
  group_uuid    TEXT NOT NULL,
  decrypted_text TEXT,
  decrypted_author BLOB(32)
);
CREATE INDEX idx_entries_group
  ON entries(group_uuid, created_at);

CREATE TABLE mls_groups (
  group_uuid    TEXT NOT NULL,
  ciphersuite   TEXT NOT NULL,
  group_state   BLOB NOT NULL,
  updated_at    INTEGER NOT NULL,
  PRIMARY KEY (group_uuid, ciphersuite)
);

CREATE TABLE key_bundles (
  user_id       BLOB(32) PRIMARY KEY,
  ed25519_pub   BLOB(32) NOT NULL,
  mldsa65_pub   BLOB NOT NULL,
  mlkem768_pub  BLOB NOT NULL,
  fingerprint   BLOB(32) NOT NULL,
  updated_at    INTEGER NOT NULL
);

CREATE TABLE group_credentials (
  group_uuid    TEXT NOT NULL,
  credential    BLOB NOT NULL,
  issuer_pk     BLOB NOT NULL,
  updated_at    INTEGER NOT NULL,
  PRIMARY KEY (group_uuid)
);
\end{lstlisting}

The \texttt{entries} table stores sealed entries with optional cached
\texttt{decrypted\_text} and \texttt{decrypted\_author} (extracted from MLS
ciphertext). The \texttt{mls\_groups} table stores serialized MLS group state
for both PQ and traditional sessions per group. The \texttt{key\_bundles}
table caches other users' composite key bundles. The \texttt{group\_credentials}
table stores BBS+ credentials for sealed sending.

Note: The previous \texttt{sessions} and \texttt{pending\_kx} tables are
removed --- MLS manages key agreement internally.

\subsection{State Reconstruction}

On startup, the sidecar replays stored state:

\begin{enumerate}
    \item Load MLS group states from \texttt{mls\_groups} table
    \item Load all distinct group UUIDs from entries
    \item For each group, replay entries: Group, Channel, and Identity
        operations rebuild in-memory state; ChatMessage operations restore
        message history using cached \texttt{decrypted\_text} and
        \texttt{decrypted\_author}
    \item Load BBS+ credentials from \texttt{group\_credentials}
    \item Subscribe to all groups on the relay (with BBS+ proofs) and sync
        new entries since the last known timestamp
\end{enumerate}

MLS Welcome, Commit, and Proposal operations are skipped during replay ---
MLS group state is loaded directly from the \texttt{mls\_groups} table.

% ============================================================================
\section{Trust Model and Security Properties}
\label{sec:trust}
% ============================================================================

\subsection{Threat Model}

\begin{itemize}
    \item \textbf{Relay: untrusted.} Cannot read content or determine sender
        identity (sealed sender). Can see group UUIDs, transport connection
        metadata, message sizes, and timing. Can withhold or reorder entries
        but cannot forge them (MLS authentication).
    \item \textbf{Identity server: semi-trusted.} Maps handles to key bundles.
        could serve wrong keys (MITM on MLS Welcome). Users verify SHA3
        fingerprints out-of-band.
    \item \textbf{Quantum adversary:} A future quantum computer can break
        X25519 and Ed25519 but not ML-KEM-768 or ML-DSA-65. APQ-MLS provides
        post-quantum confidentiality (amortized) via periodic PQ session
        updates.
    \item \textbf{Clients: trusted} within their security boundary.
\end{itemize}

\subsection{Security Properties}

\begin{table}[H]
\centering
\small
\begin{tabular}{@{}lp{4.8cm}@{}}
\toprule
\textbf{Property} & \textbf{Mechanism} \\
\midrule
Confidentiality & MLS TreeKEM key schedule; application messages encrypted
    in session B \\
PQ confidentiality & session A (ML-KEM-768) exports PSK into session B
    every $R$ epochs \\
Authenticity & MLS leaf node signatures (Ed25519 in session B, ML-DSA-65
    in session A) \\
Forward secrecy & TreeKEM ratchets on every commit; old epoch keys deleted \\
PCS & self-update commits inject fresh keying material into TreeKEM tree \\
Sender anonymity & BBS+ ZK proofs; relay cannot identify sender \\
Transport security & hybrid ML-KEM + X25519 handshake; XChaCha20-Poly1305 \\
Capability audit & signed capability grants inside MLS ciphertext \\
\bottomrule
\end{tabular}
\caption{Security properties summary}
\label{tab:security}
\end{table}

\subsection{Limitations}

\begin{enumerate}
    \item \textbf{Traffic analysis:} The relay sees message sizes and timing.
        MaybeNot integration (\S\ref{sec:future}) is planned to mitigate
        this.
    \item \textbf{Amortized PQ guarantee:} Between full updates, session B
        uses only classical primitives. A quantum adversary who captures
        session B state between PQ refreshes has a window of vulnerability
        (bounded by $R$ epochs).
    \item \textbf{MLS ordering:} MLS requires causal ordering of commits.
        The relay provides loose ordering; the sidecar buffers out-of-order
        commits.
    \item \textbf{BBS+ credential revocation:} Removing a member requires
        re-issuing credentials to remaining members (or using an accumulator-based
        revocation scheme, planned for future work).
    \item \textbf{Reaction privacy:} Reactions are now encrypted within MLS,
        resolving the previous limitation.
    \item \textbf{Rate limiting:} Neither relay nor identity server implements
        rate limiting. Per-transport-connection rate limits are planned.
    \item \textbf{Device revocation:} No mechanism to revoke compromised
        devices.
    \item \textbf{Account deletion:} No endpoint exists.
\end{enumerate}

% ============================================================================
\section{Cryptographic Parameters}
\label{sec:params}
% ============================================================================

\begin{table}[H]
\centering
\scriptsize
\begin{tabular}{@{}llr@{}}
\toprule
\textbf{Component} & \textbf{Algorithm} & \textbf{Size} \\
\midrule
Identity signing & Ed25519~\cite{rfc8032} & 32\,B pub \\
PQ signing & ML-DSA-65~\cite{fips204} & 1,952\,B pub \\
PQ KEM & ML-KEM-768~\cite{fips203} & 1,184\,B pub \\
Fingerprint & SHA3-256 & 32\,B \\
Sess.\ A KEM & ML-KEM-768 (HPKE) & 1,088\,B ct \\
Sess.\ A AEAD & AES-256-GCM & 32\,B key \\
Sess.\ A sig & ML-DSA-65 & 3,309\,B \\
Sess.\ B KEM & DHKEM X25519 & 32\,B ct \\
Sess.\ B AEAD & ChaCha20-Poly1305 & 32\,B key \\
Sess.\ B sig & Ed25519 & 64\,B \\
Transport KEM & ML-KEM-768 + X25519 & hybrid \\
Transport AEAD & XChaCha20-Poly1305 & 32\,B key \\
Transport nonce & counter + direction & 24\,B \\
Sealed sender & BBS+ (ZK proof) & ${\sim}$200\,B \\
Entry ID & SHA-256 & 32\,B \\
Amortization & $R$ & 50 (default) \\
\bottomrule
\end{tabular}
\caption{Cryptographic parameter summary}
\label{tab:params}
\end{table}

\textbf{MLS ciphersuites:}

\noindent Session~A: {\scriptsize\texttt{MLS\_192\_MLKEM768\_AES256GCM\_\allowbreak SHA384\_MLDSA65}} (0xFF12)

\noindent Session~B: {\scriptsize\texttt{MLS\_128\_DHKEMX25519\_CHACHA20\allowbreak POLY1305\_SHA256\_Ed25519}} (0x0003)

% ============================================================================
\section{Future Work}
\label{sec:future}
% ============================================================================

\begin{itemize}
    \item \textbf{MaybeNot traffic analysis defense:} Integrate the MaybeNot
        framework~\cite{maybenot} for probabilistic traffic shaping. The wire
        format already includes padding fields for message size classes.
    \item \textbf{Threshold credential issuance:} Replace single-admin BBS+
        issuance with threshold signatures, so no single admin can unilaterally
        issue credentials.
    \item \textbf{Accumulator-based revocation:} Replace credential re-issuance
        on member removal with a cryptographic accumulator for O(1) revocation
        checks.
    \item \textbf{Key transparency:} Verifiable key directory to detect
        identity server MITM.
    \item \textbf{Multi-device:} Per-device MLS leaf nodes with independent
        key bundles.
    \item \textbf{Device revocation:} Mechanism to invalidate compromised
        device keys via MLS Remove proposals.
    \item \textbf{Formal verification:} ProVerif/Tamarin models of APQ-MLS
        with sealed sender.
    \item \textbf{Relay federation:} Relay-to-relay protocol for
        cross-instance message routing.
    \item \textbf{Rate limiting:} Per-connection and per-group rate limits
        on relay and identity server.
    \item \textbf{Account lifecycle:} Account deletion, key rotation,
        handle migration.
    \item \textbf{Adaptive amortization:} Dynamically adjust $R$ based on
        threat level or group sensitivity.
\end{itemize}

% ============================================================================
\section{Implementation}
\label{sec:impl}
% ============================================================================

The reference implementation is open source:

\begin{itemize}
    \item Crypto library: Rust, \texttt{whispr-crypto/} crate --- APQ-MLS
        sessions, BBS+ sealed sender, SHA3 fingerprints, hybrid PQ transport
    \item Sidecar: Rust, \texttt{whispr-sidecar/} --- all IPC handlers,
        relay client, identity client, SQLite persistence
    \item Relay: Go, ${\sim}600$ lines (\texttt{relay/}) --- hybrid PQ
        handshake, BBS+ verification, sealed entry storage
    \item Identity server: Go, ${\sim}1$k lines (\texttt{identity/}) ---
        composite key bundles, KeyPackage distribution
    \item Desktop client: TypeScript/React + Rust/Tauri (\texttt{app/})
        --- 36 Tauri command wrappers, Zustand store slices
\end{itemize}

Dependencies: \texttt{openmls} (APQ-MLS fork with PQ ciphersuites),
\texttt{ml-kem} (FIPS~203), \texttt{ml-dsa} (FIPS~204), \texttt{sha3}
(SHA3-256), \texttt{zkryptium} (BBS+), \texttt{chacha20poly1305} (AEAD),
\texttt{ed25519-dalek}, \texttt{x25519-dalek}, \texttt{rusqlite} (SQLite),
\texttt{ciborium} (CBOR).

Environment variables for development and testing:
\begin{itemize}
    \item \texttt{WHISPR\_DATA\_DIR} --- separate data directories for
        multiple instances
    \item \texttt{WHISPR\_RELAY\_ADDR} --- relay address override
        (default \texttt{localhost:9090})
    \item \texttt{WHISPR\_SIDECAR\_PATH} --- sidecar binary path override
\end{itemize}

Source: \url{https://github.com/whisprchat}

% ============================================================================
% References
% ============================================================================

\begin{thebibliography}{99}
\small

\bibitem{signal-sender-keys}
Signal Foundation,
``Sender Keys,''
Signal Technical Documentation, 2016.\\
\url{https://signal.org/docs/specifications/doubleratchet/}

\bibitem{mls-rfc9420}
R.~Barnes, B.~Beurdouche, R.~Robert, J.~Millican, E.~Omara, and
K.~Cohn-Gordon,
``The Messaging Layer Security (MLS) Protocol,''
RFC~9420, Internet Engineering Task Force, Jul. 2023.\\
\url{https://doi.org/10.17487/RFC9420}

\bibitem{apq-mls-paper}
S.~Hale, K.~Tian, C.~Jacomme, and M.~Cremers,
``Amortized Post-Quantum MLS: Practical Hybrid Key Agreement for
Group Messaging,''
Cryptology ePrint Archive, Report 2026/034, 2026.\\
\url{https://eprint.iacr.org/2026/034}

\bibitem{bbs-signatures}
T.~Looker, V.~Kalos, A.~Whitehead, and M.~Lodder,
``The BBS Signature Scheme,''
Internet-Draft, draft-irtf-cfrg-bbs-signatures-07,
Internet Research Task Force, 2024.\\
\url{https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/}

\bibitem{maybenot}
T.~Pulls,
``Maybenot: A Framework for Traffic Analysis Defenses,''
Proceedings on Privacy Enhancing Technologies, 2023.\\
\url{https://github.com/maybenot-io/maybenot}

\bibitem{rfc8032}
S.~Josefsson and I.~Liusvaara,
``Edwards-Curve Digital Signature Algorithm (EdDSA),''
RFC~8032, Internet Engineering Task Force, Jan. 2017.\\
\url{https://doi.org/10.17487/RFC8032}

\bibitem{rfc8439}
Y.~Nir and A.~Langley,
``ChaCha20 and Poly1305 for IETF Protocols,''
RFC~8439, Internet Engineering Task Force, Jun. 2018.\\
\url{https://doi.org/10.17487/RFC8439}

\bibitem{rfc5869}
H.~Krawczyk and P.~Eronen,
``HMAC-based Extract-and-Expand Key Derivation Function (HKDF),''
RFC~5869, Internet Engineering Task Force, May 2010.\\
\url{https://doi.org/10.17487/RFC5869}

\bibitem{cbor-rfc8949}
C.~Bormann and P.~Hoffman,
``Concise Binary Object Representation (CBOR),''
RFC~8949, Internet Engineering Task Force, Dec. 2020.\\
\url{https://doi.org/10.17487/RFC8949}

\bibitem{fips203}
National Institute of Standards and Technology,
``Module-Lattice-Based Key-Encapsulation Mechanism Standard,''
Federal Information Processing Standards Publication 203, Aug. 2024.\\
\url{https://doi.org/10.6028/NIST.FIPS.203}

\bibitem{fips204}
National Institute of Standards and Technology,
``Module-Lattice-Based Digital Signature Standard,''
Federal Information Processing Standards Publication 204, Aug. 2024.\\
\url{https://doi.org/10.6028/NIST.FIPS.204}

\bibitem{rfc7748}
A.~Langley, M.~Hamburg, and S.~Turner,
``Elliptic Curves for Security,''
RFC~7748, Internet Engineering Task Force, Jan. 2016.\\
\url{https://doi.org/10.17487/RFC7748}

\end{thebibliography}

\end{document}