\documentclass[twoside,letterpaper]{sig-alternate} \usepackage[margin=1in]{geometry} \usepackage[utf8]{inputenc} \usepackage{url} \usepackage{eurosym} \usepackage{tikz} %\usepackage{listings} %\usepackage{graphicx} %\usepackage{wrapfig} %\usepackage{caption} %\usepackage{subcaption} \usetikzlibrary{cd} %\usetikzlibrary{shapes,arrows} %\usetikzlibrary{positioning} %\usetikzlibrary{calc} \def\mathcomma{,} \def\mathperiod{.} \def\mathcomma{} \def\mathperiod{} \title{Xolotl ratchet} \subtitle{A selectively stateful mixnet format for post-quantum anonymity} \author{Jeffrey Burdges} \date{\today} \begin{document} \maketitle % \section{} % L\'aszl\'o Baba's quasi-polynomial time algorithm for graph isomorphism\cite{Babai-GI} We describe a new double ratchet construction Xolotl, inspired by the Axolotl ratchet, % \cite{Axolotl}, that integrates with the Sphinx mix network packet format \cite{Sphinx}. We argue this opens the door to compact mix network formats with truly hybrid anonymity, meaning they rest upon the stronger of the security assumptions required by the different public key primitives employed. \section{Problem} % Post-quantum key sizes Amongst the chief obstacles to deploying post-quantum cryptography are the comparatively large key sizes. As a comparison : % A recent Ring-LWE key exchange New Hope \cite[\S7, p.10]{NewHope} needs key sizes of 1824 or 2048 bytes, both of which must be ephemeral, while one McEliece-like system McBits % \cite{McBits,InitRec} needs a staggering 1MB for public keys. % Super-singular isogeny Diffie-Hellman (SIDH) \cite[p. 21]{SIDH-2016} keys are only 564 bytes, or 751 bytes uncompressed, but the key exchange requires at least 100 times as much CPU time as an ECDH key exchange with equivalent classical security. Anonymity tools like mix networks are sensitive to key size because users interact with numerous nodes and key material overhead is quadratic in the number of hops. % $n(n+1)/2$ \smallskip % \section{Sphinx key blinding} Sphinx \cite{Sphinx} is a packet format for anonymizing mix networks that is provably secure in the universal composability framework, and addresses the key material burden by mutating or reblinding a single ephemeral public key $\alpha$ with each hop, as opposed to unwrapping an unrelated public key for each hop. An ECC key is blinded by multiplication with a shared secret scalar derived from the Diffie-Hellman exchange: After selecting an initial private scalar $x_0$, public curve point $\alpha_0 = x_0 G$, and a sequence of $n$ nodes with keys $Y_i = y_i G$, we recursively define \begin{aligned} \textrm{shared secret}\quad s_i &:= x_i Y_i = y_i \alpha_i \mathcomma \\ \textrm{blinding factor}\quad b_i &:= H(\alpha_i,s_i) \mathcomma \\ \textrm{next private key}\quad x_{i+1} &:= b_i x_i \mathcomma \\ % \quad\textrm{and} \\ \textrm{next public key}\quad \alpha_{i+1} &:= b_i \alpha_i \quad\textrm{for i < n.} \\ \end{aligned} Our $i$th node replaces $\alpha_i$ by $\alpha_{i+1}$. \smallskip We therefore ask if any post-quantum public key exchanges admit suitable key blinding tricks similar to Sphinx. The answer appears to be {\bf no}, for much similar reasons to why these primitives fail to yield convenient signature schemes. There are blinding operations but they incur significant costs that are asymptotic in the number of hops. % In SIDH, a public key should not possess enough information to compute another isogeny whose kernel consumes torsion of the same prime. As a result, attempts to blind SIDH keys for signature schemes add yet another torsion prime, increasing the size of the base field. % In Ring-LWE, there is enough flexibility for blinding constructions, again increasing the key size, and indeed a primitive similar to universal reencryption exists \cite{963628}. We declare such schemes unsuitable for another reason though: % If all blinding keys $b_i$ are equally likely, then the security of elliptic curve key blinding depends only upon the security of $s_i$. % Any similar statement for Ring-LWE or SIDH appear to require invoking their underlying security assumptions in a second and perhaps different way. As a result, any hybrid variant of Sphinx still depends upon its post-quantum primitives' underlying security assumptions! % We consider this a dramatic sacrifice since both SIDH and Ring-LWE remain quite young, suggesting that either could be broken well before the invention of quantum computers. \section{Solution} We could build a hybrid protocol with naive mix network packet format that unwraps a new public key with each hop, making key material size quadratic in the number of hops. % In this vein, a circuit based approach % like Tor at least avoids transmitting unnecessary key material, but % risks exposing circuit metadata in the process. Instead, we draw inspiration from the Axolotl ratchet % \cite{Axolotl} which remains secure against Shor's algorithm if first instantiated with a single post-quantum key exchange. Axolotl itself continues using the same public key until witnessing the other side reply with it, which meshes poorly with the mix networks for several reasons. % First, we prefer to exploit the elliptic curve point already in our Sphinx header, which must change with each packet. % Second, we cannot oblige mix nodes to directly communicate with the sender, as that becomes onion routing and Tor's territory. % Instead, we hope to improve anonymity over Tor alone by judiciously exploiting high latency and not creating circuits per se. We resolve these tensions by swapping the order'' of the hash iteration ratchet and the two-step ECDH ratchet that make up Axolotl. In fact, we shall exploit the ECDH operation already in Sphinx rather than adding a typical two-step ECDH ratchet. Although the mix node's key is not ephemeral, any Sphinx mix network should already rotate node keys for constant-time replay protection. A typical rotation period should be a week or month. % sometimes faster than the reply rate seen in Pond or Signal. \smallskip \noindent {\bf Xolotl ratchet description :} \def\cn{\texttt{cn}} \def\ck{\texttt{ck}} \def\DH{\texttt{DH}} \def\lk{\texttt{lk}} \def\mk{\texttt{mk}} \def\sk{\texttt{sk}} \def\ECDH{\textrm{ECDH}} A node begins as if decoding a typical Sphinx packet by verifying the MAC, producing the shared secret $s_i$, and unwrapping one layer of the header's onion layer, but then pauses to check for a ratchet flag. If not found, then it continues with Sphinx as usual, extracting the next hop and MAC, and unwrapping a payload onion. If found, then we extract the ratchet instructions instead. These ratchet instructions consist of a chain name $\cn$ and chain index $j$, along with the length of the previous chain, or perhaps other information for closing the previous chain. We define \begin{aligned} \textrm{chain start}\quad \ck_0 &:= H(\textrm{Start''} \,||\, \sk) \mathcomma \\ \textrm{chain name}\quad \cn &:= H(\textrm{Name''} \,||\, \ck_0) \mathcomma \\ \textrm{chain keys}\quad \ck_{j+1} &:= H(\textrm{Chain''} \,||\, \ck_j) \mathcomma \\ \textrm{link keys}\quad \lk_j &:= H(\textrm{Link''} \,||\, \ck_j) \mathcomma \\ \textrm{packet keys}\quad s' &:= H(\lk_j \,||\, s_i) \mathcomma \\ % \quad\textrm{and} \\ \textrm{source keys}\quad \sk_j &:= H(\textrm{Source''} \,||\, s') \mathperiod \\ \end{aligned} In essence, there is a hash iteration ratchet named by $\cn$ % with internal state $(\ck, (a,\lk_a), \ldots, (b,\lk_b))$, from which we determine a link key $\lk$. We hash $\lk$ with the Sphinx shared secret $s_i$ to produce an altered Sphinx shared secret $s'$. We finally conclude by running Sphinx with $s'$ to produce the blinding factor $b_i$ and unwrap both the Sphinx header and body. \begin{figure}[b!]%[h!] \begin{tikzcd}[ampersand replacement=\&, column sep=small] \cdot \ar[r] \& \cdot \ar[r] \ar[d] \& \cdot \ar[r] \ar[d] \& \cdot \ar[r] \ar[d] \& \ck \ar[r, dotted] \& ? \& \\ \& \lk \ar[d] \& \lk \ar[d] \& \lk \ar[d] \& \& \& \\ \& \ECDH \ar[d] \& \ECDH \ar[d] \& \ECDH\ar[d] \& \& \& \\ \& \mk \& \mk \ar[dddll, in=90, out=270] \& \mk \ar[dddlll, dotted, in=30, out=270] \& \& \& \\ \\ \\ \cdot \ar[r] \& \cdot \ar[r] \ar[d] \& \cdot \ar[r] \ar[d] \& \cdot \ar[r] \ar[d] \& \cdot \ar[r] \ar[d] \& \ck \& \& \\ \& \lk \ar[d] \& \lk \ar[d] \& \lk \ar[d, dotted] \& \lk \ar[d] \& \& \& \\ \& \ECDH \ar[d] \& \ECDH \ar[d] \& ? \& \ECDH\ar[d] \& \& \& \\ \& \mk \& \mk \& \& \mk \& \& \& \\ \end{tikzcd} \end{figure} \smallskip Assuming an initial ratchet source was created using a post-quantum key exchange, an Xolotl ratchet retains that post-quantum security. It also provides an interesting measure of forward secrecy against a classical adversary. For these advantages, we have exposed, to the node $i$ hosting the ratchet, that all packets using this particular ratchet have either the same sender or receiver. There is no need for every hop to employ a ratchet, % though, but specific usage patterns require detailed analysis. \begin{aligned} \textrm{User} \to &\textrm{Tor} \to \textrm{Xolotl} \to \textrm{Sphinx} \to \\ \quad &\to \textrm{Xolotl} \to \textrm{Sphinx} \to \textrm{Cross} \to \cdots \end{aligned} An initial guard'' ratchet should be created anew for each session. We believe that retaining middle ratchets for longer periods could improve forward secrecy over creating them all anew with each session. There are many concerns around this point however, primarily balancing the improved forward secrecy with the risk of linking packets across different sessions, but also practical matters like ratchet storage requirements on mix nodes. On that point, Ratchet link keys must expire with node keys, capping their lifetime anyways, but source keys or chain keys could outlive them. Aside from usage patterns and ratchet longevity, there are several interesting possible enhancements worth discussing : % \begin{itemize} % \item An onion header could contain a SIDH key accessed by a single mix node, allowing for post-quantum security at one middle hop where no ratchet exists. % \item A standard hash iteration ratchet could occupy considerable space if early messages see long delays. We believe a tree-like hash ratchet configuration would be more efficient, especially if ratchets are used with SURBs. % \item Ratchets could be given away to other users, thereby allowing a collaborative form of forward secrecy, and obfuscating ownership. In principle, adversaries could not break middle ratchets without breaking all cryptography up through to the messaging layer itself, which could reasonably employ multiple post-quantum key exchanges, possibly even McBits. % \end{itemize} % \section*{Acknowledgements} % This work benefits from the financial support of the Brittany Region % (ARED 9178) and a grant from the Renewable Freedom Foundation. %\newpage \bibliographystyle{abbrv} \bibliography{mix,pq,rlwe,sidh} \end{document} \section{}