%!TeX program=pdflatex
%!TeX encoding=utf8
%!TeX spellcheck = en_US
%!TeX root = ../../messageVortex.tex
\partepigraph{Occurrences in this domain are beyond the reach of exact prediction because of the variety of factors in operation, not because of any lack of order in nature.}{Albert Einstein}
\part{Operational concerns}\label{sec:operation}
In this part we cover operational aspects of our system. Chapter~\ref{sec:genOperationalConcerns} covers some general operational concerns such as \VortexNode{} types, or the handling of lifetimes. Chapter~\ref{sec:routingConcerns} covers routing concerns and introduces a simplified algorithm for building routing blocks. Chapter~\ref{sec:keyDistribution} addresses the problem of obtaining keys of routing nodes and bootstrapping a network. Finally, \cref{sec:realWorldProblems} focuses on problems encountered when working with real-world infrastructures.

\chapter{General Operational Concerns}\label{sec:genOperationalConcerns}
\section{Hardware}
We require no specialized hardware for running \VortexNodes. Instead, we designed \MessageVortex{} in such a way that ordinary mobile phones may act as \VortexNodes. It is however recommended to have a node always connected to the Internet. A mobile phone may disconnect from time to time based on the availability of the network. For our experiments, we used a RaspberryPi Zero W. It is however recommended to use a faster, newer model due to the proof-of-work algorithms' memory requirements. The hardware currently requires a network interface and a fully functional JSE VM to run the reference implementation.

\section{Addressing \VortexNodes}
From the beginning, we were searching for an addressing scheme suitable for transparent addressing.

A \MessageVortex{} address is built as follows: 

\begin{lstlisting}[language=EBNF]
	localPart         = <local part of address>
	domain            = <domain part of address>
	email             = localPart "@" domain
	keySpec           = <BASE64 encoded AsymmetricKey [DER encoded]>
	smtpAlternateSpec = localPart ".." [ keySpec ] ".." domain "@localhost"
	smtpUrl           = "vortexsmtp://" smtpAlternateSpec
\end{lstlisting}

To allow storage of \MessageVortex{} addresses in standard messaging programs such as Outlook or Thunderbird, we introduced $smtpAlternateSpec$. 

The suffix ``@localhost'' ensures that any non-participating server does not route a \VortexMessage{} unintentionally. The doubly dotted notation is not RFC-compliant but was accepted by all tested client address books. However, the address is not a valid SMTP address due to its double-dotted notation. We selected this representation to differentiate \MessageVortex{} addresses from valid email addresses.

The main disadvantage of \MessageVortex{} addresses is that they are no longer readable by a human. The main reason for this is the required public key. We may abstract this further by allowing cleartext requests on the primary email address for the public key. The \MessageVortex{} account must answer such requests with the valid \MessageVortex{} address.

The $smtpUrl$ represents the address in a standard way, which makes it suitable for QR codes and intent filters on Android.

The public key of an address is encoded as follows:
\begin{enumerate}
	\item The asymmetric key is encoded as specified in the \texttt{AsymmetricKey} in ASN.1
	\item The ASN.1 DER representation is then encoded with BASE64
\end{enumerate}    

The \texttt{keySpec} may be omitted and inserted later from an address list. The quad-dotted resulting address is illegal in a standard mail system and offers a possibility for identification. Such a keyless address may furthermore be used as a synonym for the receivers' real address as any potential receiver may send an unsolicited \texttt{HeaderRequestReplaceIdentity}.

\section{Client}
We did not create a \MessageVortex{} client for sending messages. Instead, we used a standard Thunderbird email client pointing to a local SMTP and IMAP server provided by a \MessageVortex{} proxy. On the SMTP side, \MessageVortex{} encapsulates where possible mails into a \VortexMessage{} and builds an automated route to the recipient. The SMTP part of \VortexMessage{} may be used to automatically encapsulate all messages with a known \MessageVortex{} identity into a \VortexMessage. On the IMAP side, it merges a local \VortexMessage{} store with the standard email repository building a combined view.

Using \MessageVortex{} this way offers us the advantages of a known client in addition to the anonymity \MessageVortex{} offers.

Using a proxy has certain disadvantages. At the moment, the \MessageVortex{} client only has a local store. Such a local store makes it impossible to handle multiple simultaneously connected clients to use \MessageVortex. However, this limitation is just a lack of the current implementation and not of the protocol itself. We may safely use IMAP storage for centrally storing \VortexMessages{}. This statement is true as long as:
\begin{itemize}
	\item The storage is not identifiable as such.\\
	This requires:
	\begin{itemize}
		\item A non-identifiable folder/message structure
		\item A storage not identifiable by access patterns
		\item The stored messages have the same strength as the transmitted messages in terms of detectability
	\end{itemize}
	\item A secured key\\
	Either the host key is secured sufficiently with a KDF and a passphrase (or similar), or the host key remains off-storage.
\end{itemize}

\subsection{\MessageVortex{} Accounts}
By definition, any transport layer address may represent a \MessageVortex{} identity. This fact may make people believe that their current email or Jabber address is suitable as a \MessageVortex address. This statement is technically perfectly true but it should not be done for the following reasons:
\begin{itemize}
	\item If an address is identified as a \MessageVortex{} address, it may be blocked (directly or indirectly) by an adversary. Such blocking would lead to the blocking of regular email traffic as well.
	\item If a \VortexNode{} is malfunctioning, non-\VortexMessages{} should remain unaffected. Isolation is far better if we keep non-\VortexMessages{} in a separate account.
	\item If a user no longer wants to maintain his \MessageVortex{} address, he may give up his \MessageVortex transport accounts. If he had been using his regular messaging account for \MessageVortex, he would receive mixed messages that are difficult to filter even with a known host key.
\end{itemize}

\subsection{\VortexNode{} Types}\label{sec:vortexNodeTypes}
Depending on the type of adversary within a jurisdiction, a \VortexNode{} may require different properties. In \cref{sec:adversary}, we defined observing and censoring adversaries. In environments with an observing adversary, the presence of a \VortexNode{} is not something that we have to keep hidden. In jurisdictions with a censoring adversary, we have to hide our nodes from the censor as their existence may be considered illegal.

\subsubsection{Public \VortexNode}
Public nodes are nodes, which advertise themselves as standard mixes. Just like all nodes, they may be an endpoint or a mix. Typically, they accept all requests precisely as outlined in \cref{tab:protoReplyCrit}. As an immediate result of the publicly available information about such a node, the owner may be the target of our censoring adversary. An adversary may oppose pressure to close down such a node. However, since we do not need a specific account, we may safely close down one transport account and open up a different one. Such account reopenings are even possible on the same infrastructure. We are even able to notify other users of the move and remain reachable, as a user may send a \texttt{HeaderRequestIdentity} request using the old identity. 

\subsubsection{Stealth \VortexNode}\label{sec:stealthNode}
This node does not answer any cleartext requests. As an immediate result, the node is only usable by other nodes knowing the node's public key. The node is therefore only reachable on a known secrets' basis. A sender may use this node type in environments with a censoring adversary. People may form closed routing groups that route and anonymize themselves. We have to state that putting trust into the routing nodes violates the \defref{zero trust} principle. It is however currently the only way to outcurve a censoring adversary. Means such as using distribution lists as endpoints seemed to be of some value at first but turned out to shift the problem of detection from the routing to the less secure transport layer.

\subsubsection{Hidden \VortexNode}\label{sec:hiddenNode}
A hidden node is a special form of a stealth node. It has a predefined set of identities. Only these already known identities are processed. This behavior has certain drawbacks. A sender may not change an existing identity, and he may not create new, unlinked  \defref{eID}s. As an immediate result, traffic may become pseudonymity. To counter this effect at least partially, we may use the same local identity for multiple senders. To remove clashes in the workspace, we may use preassigned IDs in the workspace. The sender is only one of all senders with knowledge of the private key of an identity. The advantage of such a node is that identities have unlimited quotas on such nodes, no longer bothering about accounting and refreshing identities. /Such behavior seems to be a valuable option when using bulletproof providers.

\chapter{Routing}\label{sec:routingConcerns}
Routing (as described in \cref{sec:routingLayer}) contributes heavily to the security of \MessageVortex. In our system, we typically have one node identity (node key). While this identity is relatively constant (but may be exchanged and notified by a \texttt{HeaderRequestReplaceIdentity} request), the involved transport nodes may be more mobile. In general, an incoming transport address changes relatively infrequently (unless advertised to friends with the header request mentioned above). The sending endpoint is irrelevant in the routing, and any routing node may, apart from the protocol type, freely choose this endpoint. 

While having routing capabilities is mandatory, as every repeated pattern in routing leads to the possibility of identifying a node of an anonymity system, it adds significantly to the systems' complexity.

The following sections emphasize the operational aspects of the routing. We introduce a detailed pseudo-code for creating a routing block and elaborate on this implementation's pros and cons regarding complexity and anonymity.

\section{Strategies for Composing Routing Blocks}\label{sec:routingStrategies}
We have to follow certain rules when building routing blocks. The rules are:
\begin{itemize}
	\item Valid chain of operations\\
	Assuming an adversary has partial or full insight into a \defref{routing graph} (except for the sender and the final recipient), all operations must be valid. This means that no operation may be applied and an inverse operation with different parameters  (i.e., $D^{K_b}\left(E^{K_a}\left(\textbf{X}\right)\right)$).
	\item No pattern is repeated within the protocol. This constraint applies to:
	\begin{itemize}
		\item Timing patterns in messages.\\
		Assuming we define fixed patterns of how a message has to be delivered (e.g., a message has to be delivered within a certain time or a payload block expires in a workspace within a certain amount of time) and publish these as general rules, in that case, we allow an attacker to identify such timing patterns of the net and draw precise lines which observed transport messages might be involved in a message transfer. By omitting such definitions and allowing each \defref{RBB} to define these values to themselves without communicating them, we make it more difficult to analyze the system by timing patterns.
		\item Operation patterns.\\
		By defining operations used in a fixed pattern (e.g., first, distribute a message over five independent message paths sized $n$), we would provide an adversary with clues to where in this pattern he is located and how close he is in regards to the beginning or end. A difference in the patterns for message traffic and decoy traffic may result in the identification of decoy traffic.
		\item Message patterns.\\
		Always communicating in the same pattern of messages (regardless of the timing). For example, always creating a full communication mesh with all parties of the anonymity set is an identifiable property that an adversary may use to identify involved \VortexNodes{} from the outside.
		\item Patterns in size or content of the payloads.\\
		Always sending similar patterns in size or content allows an inside observer to match similar sized payloads suspecting that they might have a connection and thus breaking the anonymity generated by an intermediate, honest node. Having the same pattern in the content on two different nodes (even as an ``intermediate result'') breaks all anonymization steps taken between the two workspaces as two collaborating nodes may identify this content as the same and thus conclude with certainty that they belong to the same message.
		\item Applies the same patterns on decoy routes as on message routes.\\
		When applying different patterns on message and decoy routes, an adversary might notice such different behavior and thus exclude all in decoy traffic involved nodes from the anonymity set. 
	\end{itemize}
	\item Sufficient anonymity set\\
	We assumed not to trust others' traffic. This means that an RBB has to pick a sufficiently large set for its anonymity needs by itself. Overlapping traffic will add to the anonymity, but an RBB should not rely on that assumption.
\end{itemize}

We may use several strategies depending on our anonymity needs. 

Strategies may include:
\begin{itemize}
	\item Focusing on the redundancy of paths.\\
	In this scenario, we build \defref{routing graph}s that have a minimum sized set of $u$ independent paths expressed by the involved nodes. Such a \defref{routing graph} can guarantee that a message will arrive when fewer than $u$ nodes fail.
	\item Focusing on involved jurisdictions.\\
	By focusing on the jurisdiction, an RBB may decrease the likeliness of analysis. As with each jurisdiction involved in the routing of a \VortexMessage{}, the likeliness increases that a non-collaborating jurisdiction is involved. By making educated guesses (e.g., that two opposing countries or organizations are unlikely to collaborate), the risk that a path may be thoroughly analyzed from the sending node to the receiving node is less likely.
	\item Focusing on the speed of delivery.\\
	The smaller we define the time windows for routing a message from the sender to the final recipient, the simpler the analysis for an adversary as there are fewer messages involved in a possible routing (assuming that an adversary has the means to magically identify all \VortexMessages). Inversely, if the speed of a message may be generally slow, an adversary has to take far more messages into account.
	\item Focusing on the size of the anonymity set.\\
	The more involved the nodes and transport protocols in a routing block are, the more complex observation of the protocol is. By increasing the anonymity set, the likelihood of overlapping \defref{routing graph}s increases significantly. Furthermore, the regular message traffic of the transport protocol may further increase the complexity for an outside observer.
	\item Focusing on anonymity of the \defref{eID}s.\\
	By using only short-term \defref{eID}s whereever possible, we increase the complexity for an adversary as we reduce the number of overlapping routing points for the same identity. While the original sending identity may remain the same, the changing \defref{eID}s make it impossible to identify anonymity groups over time.
	\item Focusing on the distribution of the message parts.\\
	A sender applying an $addRedundancy(m,n)$ operation to a message before sending is safe, unless $n-m$ nodes in independent message paths collaborate and have full knowledge of all keys and operations (including the ones applied on the senders' node) as the resulting equation system would have any possible solution (in length and appearance) up to the size of all $n-m$ blocks.
	\item Focusing on diagnosability.\\
	By deploying diagnosis payload blocks on subsequent nodes instead of just leaving them in the workspace of a node, the possibility of falsifying the result of a diagnosis based on the assumption that the first delivered block belongs to a message and diagnosis is made retrospectively when detecting a problem is eradicated. 
\end{itemize}

The algorithm itself does not really matter as long as it guarantees the properties at the beginning of this section.

\section{Strategies for Minimizing Impact and Maximizing Effect when Routing Foreign Messages}
Keeping a single node alive can be crucial. If we assume that the a message is received and sent through the same transport account, it is relatively easy for an adversary to observe this. By sending it to a recipient transport address, he learns that a \VortexNode{} is connected to that address. Conversely, any mail coming from such an address is potentially a \VortexMessage{}.

Any node may reduce the traceability by following a couple of additional rules. First of all, transport addresses for sending should be kept separate from receiving transport addresses. This way, an adversary needs to carry out man-in-the-middle (MitM) attacks in the respective access protocols or gain direct access to the transport infrastructure to learn what transport addresses are used by the \VortexNode{}. If NAT is involved in the client access, as it is the normal case when using the targeted infrastructure for a \VortexNode, it just adds to the complexity an adversary has to solve. While this is no true gain in anonymity, it contributes heavily to the complexity an adversary has to handle. In a more advanced scenario, we would use an anonymization technology such as ToR to further hide the accessing source (\VortexNode) from the transport infrastructure. However, the use of such technology will make access suspicious and possibly lead to the identification of the transport account.

A supposedly compromised transport layer recipient endpoint address may be migrated using a \texttt{HeaderRequestReplaceIdentity} request as outlined in \cref{sec:replaceID}. Such a request leaves no trace to the transport endpoint owner but allows any subset of known \VortexNode{} to advertise the migration in a cryptographically secured way. Additionally, this request allows by omitting the new address to bind an ephemeral identity to a true transport address identifying the sender of a message. Such an ephemeral identity may be assigned with an infinite quota by the owner to spare the costs of recreating and re-authenticating the sender. If such binding of identity is carried out, it is vital that this identity is not used for routing but only as an endpoint. Otherwise, a malicious ``friend'' could draw conclusions on routing anonymity set and frequency out of such an identity.

\subsection{Operational Aspects of MURBs\label{sec:murb}}
As we have interactions of any possible node with an unknown sender of a request (e.g., in the case of a new identity request), reply blocks are a necessity for the \MessageVortex{} protocol.

Originally, we included the possibility of replaying replayable blocks (MURBs) for sending error messages. Soon we found out that such messages imply privacy issues. While the error messages were discarded in favor of an RBB-based diagnosability, we kept the possibility of MURBs to enable users to have sender/recipient anonymity. 

Our MURBs are routing blocks that an owner of the block may use for a limited amount of time. Such sending may be carried out without any knowledge about the recipient's identity, location, or infrastructure. A MURB is equivalent to a normal routing block except for the following properties:

\begin{itemize}
	\item The sender is unknown but the receiver of the message is.
	\item It has a replay value of 1 or higher.
	\item Due to transport layer size restrictions and ephemeral quotas, the total size of the transported messages is limited.
\end{itemize}


A MURB in our term is an entirely prepared routing instruction built by the recipient of a message. The sender has only the routing blocks and the instructions to assemble the initial message. He does not know the message path except for the first message hop.

As a MURB is a routing block, it generates the same pattern on the network each time a sender uses it. To avoid statistical visibility, we need to limit the number of uses per MURB. The protocol is limited to a maximum of 127 usages. This number should be sufficiently sized for automated messages. A minute pattern would disappear after 2 hours at the latest and an hourly pattern after five days.

For a MURB to work, the RBB has to ensure that all quotas required to the route are sufficiently sized. Such sizing is difficult to foresee in some cases. An RBB may query these identities from time to time to ensure that they do not deplete. Wherever possible, MURBs should be dropped in favor of multiple SURBs to avoid the dangers of MURBs.

\section{Routing Algorithms Suitable for Achieving Anonymity\label{sec:routingAlgorithm}}
In \cref{sec:routingStrategies}, we elaborate on the properties of a routing block required to build an anonymizing message path.

In short, every foreseeable or logically invalid pattern may be used to identify \VortexMessages{} or in transport involved nodes. This is why we cannot use a fixed pattern in routing. Instead, we use randomized routing patterns. Ordinary fixed pattern protocols, such as broadcast or DC-net-based protocols, are identifiable as their communication pattern is stable (fixed set of messages between involved nodes and foreseeable message size). Whereas the message size might be varied in such systems by adding decoy content or stuffing, such behavior depends on the secrecy of the nodes executing such operations.

\subsection{The Routing Block}\label{sec:routingGraph}\index{message!routing}
In general, an RBB builds a routing block in three stages:
\begin{enumerate}
	\item Create a random but ``valid'' directed multigraph (\defref{routing graph})\index{routing graph} where the nodes represent \VortexNodes, and the edges represent actual messages sent between the \VortexNodes{} and are assigned a label depicting the sequence in time. The graph may contain loops. We may visualize such a \defref{routing graph} traditionally. Alternatively, we found that displaying the graph as a sequence of messages (see \cref{fig:transformGraph}) offers a better overview over the inner workings of a \defref{routing graph}. For a graph to be valid there must be at least one valid path from node 0 to any other node, including node 1 which is our main target. Furthermore, outgoing edges may only arise after a an incoming edge is present.
	\item We then rewrite that graph and order it while assigning timing information to each edge, leaving sufficient time in between to process the incoming message on the transport layer.
	\item As the next step, we assign operations to all involved workspaces.
\end{enumerate}

Based on such a \defref{routing graph}, we refer to a path between the two nodes $i$ and $j$ as an ordered set of edges, where an edge always starts where the previously edge ended, the first edge starts at node $i$, and the last edge ends at node $j$. A path may contain the same node multiple times, and a \defref{routing graph} may contain multiple paths between two given nodes. Figure~\ref{fig:graphPaths} shows all paths between nodes $0$ and $1$ of the graph outlined in \cref{fig:transformGraph}. All these paths may be used to transport a message from node $0$ to $1$. Depending on the strategy, multiple paths may be used to transport a part of a message or used to transport redundant message parts.

\begin{figure*}[ht]
	\centering
	\resizebox{.95\linewidth}{!}{
		\input{inc/graphTransformation.inc.tex}
	}
	\caption{Transformation of a graph into a sequence of messages.}
	\label{fig:transformGraph}
\end{figure*}

\begin{figure*}[ht]
	\centering
	\resizebox{.9\linewidth}{!}{
		\input{inc/graphPaths.inc.tex}
	}
	\caption{A graph containing six paths between node $0$ and node $1$.}\label{fig:graphPaths}
\end{figure*}

A possible routing mechanism creating such a graph and applying routing information is described in detail in \cref{sec:simpleRoutingStrategy}.

\subsection{A Simple Routing Strategy}\label{sec:simpleRoutingStrategy}
In this section, we show a simple algorithm for creating a \defref{routing graph} in a non-censored environment or in an isolated node-set in a censored environment. While the algorithm is complete, we had to shorten it for this work in order to remain readable. The algorithm is not perfect as it leaks certain properties, such as the maximum possible message size.

To create a \defref{routing block}, we need some basic objects as defined in algorithm~\ref{alg:simpleGraphObjects}.
\begin{breakablealgorithm}
	\captionof{figure}{Objects for building a routing block.}\label{alg:simpleGraphObjects}
	\begin{algorithmic}[1]
		\LineComment{A routing graph}
		\Object{RoutingGraph}
		\LineComment{Contains the routing \VortexNodes{} (node[0]$\rightarrow$sender; node[1]$\Rightarrow$receiver)}
		\State $\text{nodes}:\textsc{Sequence<Node>}$
		\LineComment{Contains messages between the nodes}
		\State $\text{edges}:\textsc{Sequence<Message>}$
		\EndObject
		\item[]
		\Object{Message}
		\State $\text{sourceNode}: Node$
		\State $\text{sourceId}: int$
		\State $\text{earliestTime}: datetime$
		\State $\text{latestTime}:datetime$
		\State $\text{targetNode}: Node$
		\State $\text{targetId}$
		\State $\text{operations}: \textsc{List<Operations>}$
		\item[]
		\Procedure{setTiming}{min,max}
		\State $\text{earliestTime} \gets \text{min}$
		\State $\text{latestTime} \gets \text{max}$
		\EndProcedure
		\EndObject
		\item[]
		\LineComment{The projected workspace of any eID under our control}
		\Object{WorkSpace}
		\State $\text{payloads}:\textsc{Map<Id,Payload>}$
		\State $\text{routingBlocks}:\textsc{List<RoutingBlock>}$
		\State $\text{operations}:\textsc{List<Operation>}$
		\item[]
		\LineComment{Returns an unused id with at least <numberOfSubsequentIds> unused IDs following}
		\AbstractFunction{getUnusedId}{numberOfSubsequentIds}
		\LineComment{Returns a random output id of an operation unused so far and marks it as used}			\AbstractFunction{getRandomPayloadId}{}
		\EndObject
		\item[]
		\LineComment{An object reflecting our knowledge about \MessageVortex}
		\Object{Universe}
		\State $\text{knownNodes}:\textsc{Map<Node,WorkSpace>}$
		\State $\text{keysize}:Integer \gets 256$
		\item[]
		\LineComment{Returns all the nodes of knownNodes}
		\AbstractFunction{getAllNodes}{}
		\LineComment{Returns a random node of list}
		\AbstractFunction{getRandomNode}{list}
		\LineComment{Returns the representation of the workspace of the named node}
		\AbstractFunction{getWorkspace}{node}
		\LineComment{Adds a message to a workspace with all its content (payloads, operations)}
		\AbstractFunction{addMessageToWorkspaces}{message}
		\LineComment{returns an integer r within 0<=r<maxValue}
		\AbstractFunction{nextRandomInt}{maxValue}
		\LineComment{returns an double r within 0<=r<1}
		\AbstractFunction{nextRandomDouble}{~}
		\LineComment{returns an double r with a Gaussian distribution}
		\AbstractFunction{nextRandomGaussian}{~}
		\EndObject
	\end{algorithmic}
\end{breakablealgorithm}

To create a routing block, we first need a graph representing the message flow. Algorithm~\ref{alg:simpleGraph} shows a pseudo-code to create such a valid graph. After creating a graph, we need to assign timing and routing information. Algorithm~\ref{alg:simpleTiming} shows a possible algorithm for assigning this timing information, whereas algorithm~\ref{alg:simpleRouting} shows a simple generator for the routing operation. The algorithm omits IDs for simplicity allocation of the workspace as this is a ``bookkeeping''-only problem.

To create a graph, we use the function~\funcref{alg:getRoutingGraph}{} on line~\ref{alg:getRoutingGraph-line} as shown in algorithm~\ref{alg:simpleGraph}. It creates an ordered set of nodes (\texttt{nodes}), whereas the first node in the set is the sender and the second node of the set is the final recipient. It then adds randomly known nodes until the anonymity set is as large as requested. Next, we assign the edges by calling function~\funcref{alg:getEdges}{} (Line~\ref{alg:getEdges-line}). The function loops until the requested minimum number of edges are reached, and all nodes of the graph receive at least one message. On each loop, an edge is added to the graph, that points from any already reached node to a random, different node.

\begin{breakablealgorithm}
	\captionof{figure}[Simple graph for routing block. (PseudoCode)]{Simple Graph for Routing Block.}\label{alg:simpleGraph}
	\begin{algorithmic}[1]
		\Function{getRoutingGraph}{startNode,endNode, numNodes, minEdges, universe}\funclabel{alg:getRoutingGraph}\label{alg:getRoutingGraph-line}
		\LineComment{The maximum number of seconds until the message needs to be delivered}
		\State $\text{maxTime} \gets 3000$
		\LineComment{The minimum number of seconds a message has time to be on one routing node}
		\State $\text{minHopTime} \gets 10$
		\LineComment{The minimum number of seconds a message has time to be on one routing node}
		\State $\text{redundantRoutes} \gets 3$
		\item[]
		\State $\text{ret} \gets \text{new RoutingGraph}()$
		\State $\text{ret.nodes} \gets \Call{getNodes}{startNode, endNode, numNodes, universe}$
		\State $\text{ret.edges} \gets \Call{getEdges}{minEdges, ret.nodes, universe}$
		\State $\text{ret.edges} \gets \Call{assignTiming}{ret.edges, maxTime, minHopTime, universe}$
		\State $\text{ret.edges} \gets \Call{assignRouting}{ret.edges, redundantRoutes, 0, universe}$
		\Return $\text{ret}$	
		\EndFunction
		\item[]		
		\Function{getNodes}{startNode, endNode, numberOfNodes, universe}\funclabel{alg:getNodes}\label{alg:getNodes-line}
		\State $\text{nodeList} \gets \lbrack\text{startNode}, \text{endNode}\rbrack$
		\While {$\text{len(nodeList)} < \text{numberOfNodes}$}
		\State $\text{randomNode} \gets \text{universe}.\Call{getRandomNode()}$
		\If {$\neg \text{nodeList.contains(randomNode)}$}
		\State $\text{nodeList.append(randomNode)}$ 
		\EndIf	
		\EndWhile{}	
		\Return $\text{nodeList}$
		\EndFunction  
		\item[]
		\Function{getEdges}{minEdges, nodes, universe}\funclabel{alg:getEdges}\label{alg:getEdges-line}
		\State $\text{edgeList} \gets []$
		\State $\text{listOfReachedNodes} \gets \Call{getReachedNodes}{edgeList, nodes[0]}$
		\While{$\text{len(edgeList)<minEdges} \Or $  \\ $\text{len(listOfReachedNodes)}<len(nodes)$}
		\State $\text{startNode} \gets \Call{universe.getRandomNode}{listOfReachedNodes}$
		\State $\text{endNode} \gets \Call{universe.getRandomNode}{nodes-[startNode]}$
		\State $\text{edgeList.append(new Message(startNode, endNode))}$
		\State $\text{listOfReachedNodes} \gets \Call{getReachedNodes}{edgeList}$
		\EndWhile{}
		\Return $\text{edgeList}$
		\EndFunction
		\item[]
		\Function{getReachedNodes}{edgeList,startNode}\funclabel{alg:getReachedNodes}\label{alg:getReachedNodes-line}
		\State $\text{reachedNodeList} \gets [\text{startNode}]$
		\ForAll{$\text{e} \in \text{edgeList}$}
		\If{$\neg \text{reachedNodeList.contains(e.targetNode)}$}
		\State $\text{reachedNodeList.append(e.targetNode)}$
		\EndIf
		\EndFor
		\Return $\text{reachedNodeList}$
		\EndFunction
	\end{algorithmic}
\end{breakablealgorithm}

Function~\ref{alg:assignTiming} is specified in algorithm~\ref{alg:simpleTiming} on line~\ref{alg:assignTiming-line}. In this function, we assign the timing information to the graph. 

We use a custom random distribution called \funcref{alg:getRandomTime} (line~\ref{alg:getRandomTime-line}). This distribution is a derived form of a Gaussian distribution and has its minimum value, maximum value, and peak value at desired spots. The squishing of the function violates some properties of the Gaussian bell curve. Due to the squishing, the left and right sides of the bell no longer have the same area. The timing information distributes in a serialized way along the timeline. Figure~\ref{fig:timeDistribution} shows the distribution of the implementation.

\begin{figure*}[ht]
	\centering
	\input{inc/timeDistribution.inc.tex}
	\caption{Distribution of \funcref{alg:getRandomTime}{}(90, 120, 200) in algorithm~\ref{alg:simpleTiming}.}
	\label{fig:timeDistribution}
\end{figure*}

We assign the timing information by looping through our ordered set of edges. First, we calculate the earliest ($\text{earliestTime}$) and the maximum available time starting then ($\text{maxShare}$) until the message has to be sent. We calculate when the message has to be sent in relation to $\text{earliestTime}$ ($\text{share}$). Finally, we generate a time when an edge may be executed earliest ($\text{minTime}$; line~\ref{alg:minTime-line}) and latest ($\text{maxTime}$; line~\ref{alg:maxTime-line}).

\begin{breakablealgorithm}
	\captionof{figure}[Assign Timing Information to a Graph. (PseudoCode)]{Assign Timing Information to a Graph.}\label{alg:simpleTiming}
	\begin{algorithmic}[1]
		\Function{assignTiming}{edges, maxTime,minHopTime, universe}\funclabel{alg:assignTiming}\label{alg:assignTiming-line}
		\If{$\text{len(edges)} \times \text{(minHopTime - 1)} > \text{maxTime}$}
		\Throw "maxTime too small for constraints"
		\EndIf
		\State $\text{earliestTime} \gets 0$
		\State $\text{maxRemainingTime} \gets \text{maxTime}-\text{earliestTime}$
		\State $\text{remainingHops} \gets \text{len(edges)} - 1$
		\State $\text{times} \gets []$
		\ForAll{$\text{e} \in \text{edges}$}
		\State $\text{maxShare} \gets \text{remainingTime} - \text{remainingHops}\times\text{minHopTime}$
		\State $\text{share} \gets \frac{maxShare}{remainingHops}$
		\State $\text{minTime} \gets \Call{getRandomTime}{earliestTime, earliestTime+share, earliestTime+maxShare}$\label{alg:minTime-line}
		\State $\text{maxTime} \gets \Call{getRandomTime}{minTime, minTime+share, earliestTime+maxShare, universe}$\label{alg:maxTime-line}
		\State $\text{earliestTime} \gets \text{maxTime}+\text{minHopTime}$
		\State $\text{remainingHops} \gets \text{remainingHops} - 1$
		\State $\text{maxRemainingTime} \gets \text{maxTime}-\text{earliestTime}$
		\State $\text{e}.\Call{setTiming}{minTime, maxTime}$
		\EndFor
		\Return $text{edges}$
		\EndFunction
		\item[]		
		\Function{getRandomTime}{min, peak, max, universe}\funclabel{alg:getRandomTime}\label{alg:getRandomTime-line}
		\State $\text{value} \gets \text{min}-1$
		\While{$\text{value} < \text{min} \Or \text{value} > \text{max}$} 
		\State $\text{value} \gets \text{universe}.\Call{nextRandomGaussian}{~}$
		\State $\text{d} \gets \text{universe}.\Call{nextRandomDouble}{~}$
		\If{$d < (peak-min)/(max-min)$} 
		\State $\text{value} \gets \text{peak} - \frac{\text{abs(value)} \times (\text{peak} - \text{min})}{5}$
		\Else
		\State $\text{value} \gets \text{peak} + \frac{\text{abs(value)} \times (\text{max} - \text{peak})}{5}$
		\EndIf
		\EndWhile
		\Return $\text{value}$
		\EndFunction
	\end{algorithmic}
\end{breakablealgorithm}

Key to the graph itself is neither the edges or nodes nor the timing, but the operations applied to the graph. This part is covered by function~\funcref{alg:assignRouting}{} in algorithm~\ref{alg:simpleRouting}. We assign the operations in three steps. We first assign to $\text{redundantRoutes}$ a valid message path (lines~\ref{alg:startAssignValidRoutes-line}\=/\ref{alg:endAssignValidRoutes-line}). Then we identify ``unused (sub\=/)routes'' and assign the same operations to these routes (lines~\ref{alg:startAssignUnusedRoutes-line}\=/\ref{alg:endAssignUnusedRoutes-line}). 

Operations are assigned in a recursive manner. First, we identify the routes we want to assign operations. This recursive part is achieved by the \funcref{alg:assignSingleRoute} (line~\ref{alg:startAssignRoute-line}\-/\ref{alg:endAssignRoute-line}). We first identify a payload to be transported and the chain of nodes. We call \funcref{alg:assignSingleRoute}, which will then apply a random operation on the first node and transport the relevant payload block to the second node in the chain, mapping it there to an unused ID within the workspace. We then take the remaining path with the newly created ID in the remaining path and repeat the step, thus looping recursively through the path until we have covered the whole path.

Operations are chosen in two ways: either we create an $addRedundancy$ operation of type $n-1$ of $n$, or we use a simple encryption step. In each case, we apply an operation on the current node a, and on the final node we apply the reverse operation, thus rebuilding the message on the last node simultaneously.

\begin{breakablealgorithm}
	\captionof{figure}[Assign Routing Information to a Graph. (PseudoCode)]{Assign Routing Information to a Graph.}\label{alg:simpleRouting}
	\begin{algorithmic}[1]
		\Function{assignRouting}{edges, redundantRoutes, messageId, universe}\funclabel{alg:assignRouting}\label{alg:assignRouting-line}
		\If{$redundantRoutes<1$}
		\Throw "At least one route is required"
		\EndIf
		\State $\text{routes} \gets \text{getRoutes(edges)}$\label{alg:startAssignValidRoutes-line}
		\If{$\text{len(routes)}<\text{redundantRoutes}$}
		\Throw "Graph has not enough redundant routes"
		\EndIf
		\LineComment{Add operations to true routes}
		\State $\text{numRoute} \gets 0$
		\While{$\text{redundantRoutes}>\text{numRoute}$}
		\State $\text{currentRoute} \gets \text{routes[numRoute]}$
		\State $\Call{assignRoute}{\text{currentRoute}, \text{payloadId}, \text{currentRoute[LAST]},0}$
		\State $\text{numRoute} \gets \text{numRoute} + 1$
		\EndWhile\label{alg:endAssignValidRoutes-line}
		\LineComment{Add sensible operations to decoy routes}
		\ForAll{$\text{r} \in \Call{getUnusedRoutes}{edges}$}\label{alg:startAssignUnusedRoutes-line}
		\State $\Call{assignRoute}{\text{r}, \text{r.getRandopOperation().getUnusedIds(1)}, \text{NULL},32769}$
		\EndFor\label{alg:endAssignUnusedRoutes-line}
		\State $\Call{addMessageMapping}{\text{edges}}$
		\Return edges
		\EndFunction
		\item[]		
		\Function{assignSingleRoute}{route, payloadIds, lastNode, targetIds}\funclabel{alg:assignSingleRoute}\label{alg:startAssignRoute-line}
		\State $source \gets route.getSourceNode()$
		\If{$\text{payloadIds.isEmpty}()$}
		\State $\text{PayloadIds} \gets \text{source.getRandopOperation().getUnusedIds(1)}$
		\State $\text{payloadSet} \gets \Call{assignRoute}{\text{route[2-]}, \text{targetIds.forward()}, \text{lastNode}, \text{targetIds.reverse()}}$
		\Else
		\State $\text{targetIds}  \gets \Call{assignOperation}{\text{route.getSourceNode()}, \text{payloadIds}, \text{lastNode}, \text{targetIds}, \text{universe}}$
		\State $\text{payloadSet} \gets \Call{assignRoute}{\text{route[2-]}, \text{targetIds.forward()}, \text{lastNode}, \text{targetIds.reverse()}}$
		\EndIf	
		\EndFunction\label{alg:endAssignRoute-line}
		\item[]		
		\Function{assignOperation}{node, transportIds, reverseNode, targetIds, universe}\funclabel{alg:assignOperation}\label{alg:startAssignOperation-line}
		\State $\text{out} \gets \text{node.outEdges()}$
		\State $\text{in} \gets \text{node.inEdges()}$
		\If{$\text{out}>1 \Or \text{extRandomInt(3)}=1$}
		\LineComment{assign addRedundancy}
		\State $\text{numBlocks} \gets \text{max(out+1, universe.\Call{nextRandomInt}{out+4})}$
		\State $\text{seed} \gets \text{universe}.\Call{nextRandomInt}{2^{256}}$
		\State $\text{op} \gets \text{node.addRedundancy(transportIds, numBlocks - 1, numBlocks, seed)}$
		\If{$\text{reverseNode}!=\text{NULL}$}
		\State $\text{reverseOp} \gets \text{reverseNode.removeRedundancy(targetIds, op)}$
		\State $\text{newId} \gets \text{op.getUnusedIds(1)}$
		\State $\text{newId.addReverseIds(reverseOp)}$
		\EndIf	
		\Else
		\LineComment{assign encrypt}
		\State $\text{keySize}   \gets (\text{universe}.\Call{nextRandomInt}{3}+2)*64$
		\State $\text{key}       \gets \text{universe}.\Call{nextRandomInt}{2^{\text{keySize}}}$
		\State $\text{op}        \gets \text{node.encrypt(transportIds, "AES", keySize, key)}$
		\If{$reverseNode!=NULL$}
		\State $\text{reverseOp} \gets \text{reverseNode.decrypt(targetIds, op)}$
		\State $\text{newId}     \gets \text{op.getUnusedIds(1)}$
		\State $\text{newId.addReverseIds(reverseOp)}$
		\EndIf	
		\EndIf
		\Return{$newIds$}
		\EndFunction\label{alg:endAssignOperation-line}
	\end{algorithmic}
\end{breakablealgorithm}

The algorithm outlined in this section has several of disadvantages due to its brevity. As it proves difficult to split routes in such a compact recursive manner, it was omitted. For the same reason, we always used $addRedundancy$ operations, which rebuild the message out of a single block. These simplifications have some drawbacks. This algorithm never loses size (it may gain size due to padding and stuffing). Therefore, we may match similarly sized payload blocks as potentially belonging to the same message. Apart from that, the algorithm fulfills all criteria mentioned above. We apply the same operations on the decoy and true message traffic, and we have no timing, operations, or message patterns. As soon as this algorithm uses traffic splitting with either the $split$ or $addRedundancy$ operation, this weakness disappears.

\section{Routing Diagnosis and Reputation Building\label{sec:diagnosisOfMessagePath}}
When all nodes are working as expected, no diagnostic is required. As we rely on always-connected devices such as mobile phones as routers, it is likely that not all nodes are available within the required time frames. As a result, we need at least the possibility to identify malfunctioning nodes and exclude them from routing. Furthermore, active adversaries may intentionally induce bad packets to destroy message content.

\MessageVortex{} allows a diagnosis to identify such malicious nodes. We differentiate between implicit and explicit diagnosis. When making an implicit diagnosis, we analyze packets that are routed from the start node over one or more other nodes back to the start nodes again. As a routing block builder is aware of the message content and all involved routing operations, it may calculate the payload spaces at all points throughout the message transfer and therefore predict the content and size of the payload blocks received. This is possible due to the fact that we defined all operations byte-precise and left no room for interpretation. This applies to all parts of the operation, including padding and stuffing. If the received payload blocks differ from the expectation, at least one of the nodes involved in the transfer of the payload malfunctioned. Reputation-buiding over time can be achieved by assigning to all nodes additively a small reputation value if involved in a working route and subtract a value when participating in a loop that malfunctioned. As malfunctioning nodes will always be in a malfunctioning loop, their reputation value will drop while working nodes will build up a score each time when participating with other working nodes.

We describe the reputation of a node $a$ as $R_a$. Node $a$ takes part in a set closed loops $I$ with elements $I_i$. The weighting $w_i$ of a loop $I_i$ is $1$ for a successful loop and $-1$ for an unsuccessful loop. We then may calculate the reputation $R_a$ as described in \cref{eqn:reputation}.

\begin{eqnarray}
	R_a & = & \sum_{i}{\frac{w_i}{len\left(I_i\right)}}\label{eqn:reputation}
\end{eqnarray} 

We can make an explicit diagnosis in the case where the payload received does not match its expected value or is completely missing. We may achieve this by creating additional routing blocks picking up packets of the previous message in the workspaces of the suspected malfunctioning nodes. Explicit diagnosis yields a big danger. An adversary expecting diagnosis, because he knows that he cheated, may fall back to an irregular behavior where the first operations are falsified, and if a second routing block arrives, the expected answers are given. This would falsify the reputation score in favor of an adversary and lower the reputation score of any subsequent nodes. This is why we recommend not using explicit diagnosis to identify active adversaries or calculate a reputation but only to identify nodes that are offline.

\section{Redundancy and Distribution Strategy}
The capability to distribute data and redundancy information over several nodes is one of the key features of the protocol. The $addRedundancy$ operation serves two purposes. First, it allows a splitting operation where the content is not only split but distributed over all parts. While a normal $splitPayload$ operation leaves the message itself intact but splits it into two parts, which each may contain meaningful, readable parts of the underlying message, $addRedundancy$ distributes the message over the output blocks. The difference is not as big as it seems, as the input is (with a possible exception to the sending node) not applied to the original message but to an encrypted part of the message.

Assuming that an attacker does not control the whole network of relevant messages but is in possession of the whole routing block and possesses all operations and keys to recover the original message, it is safe to say that distributing the message over multiple redundant paths improves security. Both operations allow such behavior, but in a very different way. The operations $splitPayload$ and $mergePayload$ allow creating payload blocks with any size. However, when transmitting both sizes of a split, they add up to a full block size of the previously completed encryption operation. Thus, if we control both receiving nodes of the parts of the $splitPayload$ operation, we may conclude that the two \defref{eID}s belong to the same real identity. This is why we always used a subsequent encryption operation after applying a $splitPayload$. This rounds both chunks again to block sizes of the encryption operation.

\chapter{Protocol Bootstrapping\label{sec:keyDistribution}}
Protocol bootstrapping is especially difficult in an environment with a censoring adversary. While in an environment of an observing adversary, the nodes may be public and thus queried. In an environment of a censoring adversary any directory or possibility to query nodes inevitably leads to a possibility of harvesting \VortexNodes{}. 

We consider the bootstrapping problem as one of the major, unsolved problems of \MessageVortex.

\section{Key Distribution for Endpoints}
For endpoints, we may have at least a partial solution. Sending a \VortexMessage{} as an unencrypted message to the users' true email, containing a request capability block and a \texttt{HeaderRequestReplaceIdentity} without a new $NodeSpec$ may be used to initiate a handshake between two nodes. While such behavior is cryptographically secured, the observing adversary gains as additional information that the receiving party of the message is using \MessageVortex{} and learns the full address, including its key from the sending party. None of this information is confidential in an environment with an observing adversary but shows the weakness of bootstrapping the system.

\section{Key Acquisition for Routing Nodes}
An adversary may make key acquisitions of routing nodes in an observing adversary environment through the $HeaderRequestNodes$ request. All these nodes distributed by such mechanisms are so-called public nodes and must be considered as untrustworthy nodes at any time. 

It is interesting to have an inbound address listed as a public node due to their traffic and the observable endpoints. Simultaneously, they are not suitable as nodes for communicating with environments connected to a censoring adversary. Therefore, such nodes are typically not considered to increase the anonymity set. This is because such an adversary would most likely try to harvest all public nodes and blacklist them to block cross border traffic and possibly gain clues on the identity of transport endpoints of \VortexNodes{} within his reach.

Tus, while a node in an environment with an observing adversary may use such public nodes, a \VortexNode{} within reach of a censoring adversary has two choices:
\begin{itemize}
	\item Build a trusted ``own'' network of trustworthy partners and exchanging keys initially by hand.
	\item Exit the jurisdiction on the first hop or even by using a transport layer account supposedly outside the reach of the own censoring adversary
\end{itemize}

Both options are equally bad, but the second option is easier to fulfill as currently alliances in terms of cooperations seem to be relatively stable, and only a limited amount of adversaries (e.g., ``Five Eyes'' or China) have the resources to record encrypted traffic for later decryption.

\chapter{Real-World Problems when Using \MessageVortex}\label{sec:realWorldProblems}
Some problems are not directly related to the \MessageVortex{} protocol but must still be considered when implementing or using \MessageVortex. The problems discovered during our experiments and possible solutions are listed in the following sections.

\section{Size Restrictions of the Transport Layer}
A transport layer may limit the size of messages transferred. We managed to create \VortexMessages{} as small as $2KB$ in size. Considering the blending overhead of F5, our message is sized at least $16KB$, which is not a problem for any selected transport protocol. While a \VortexMessage{} may be small, an size limit is possibly imposed by the transport layer. Most SMTP providers define a limit of $10\frac{MB}{message}$. Considering that we use a binary transfer, which is typically BASE64-encoded, the usable transfer size is roughly $7.5MB$, as BASE64 adds roughly $25\%$ overhead. Considering that we should not use any content larger than $12\%$ of the carrier message, the true transport capability of a $10MB$ message drops to $\approx 900KB$, which is disastrously small. While a single \VortexMessage{} may not be larger than the $900KB$ limit on SMTP due to this limitation, the assembly in a workspace allows transporting larger messages than the limit on the transport layer.

The size of this calculation shows the waste of the transport capacity of our system in a drastic way. Assuming that we use a high anonymity set of $k=30 \text{nodes}$ and assuming that on average, each message contains half of the original message and we are exchanging 60 messages within the anonymity set, a $900KB$ message would result in $60\times 5MB=300MB$ cumulated transfer volume between all nodes which results in a total transfer efficiency of $\approx 0.3\%$. While such waste is not uncommon within anonymity systems (unless tuned for efficiency), the level of waste is dramatic.

\section{Redundancy of the \VortexNode}
At the beginning of our work, we attempted to make \VortexNodes{} redundant by sharing configuration and state data over the transport media. While the idea was tempting, we discovered that any kind of such usage leads to an uncommon usage pattern of the transport account. This uncommon usage pattern allows an adversary to identify transport accounts of \VortexNodes.Thus, we dropped this idea. 