%!TeX program=pdflatex
%!TeX encoding=utf8
%!TeX spellcheck = en_US
%!TeX root = ../../messageVortex.tex


% ********************************************************************************************************
% *** Decisions and Research
% ********************************************************************************************************
\partepigraph{Thinking is the hardest work there is, which is probably the reason, so few engage in it.}{Henry Ford, American industrialist and founder of Ford Motor Co.}
\part{The \MessageVortex{} System}\label{sec:coreMVProtocol}
In this section, we describe the core parts of the \MessageVortex{} protocol. Unlike most other academic attempts, we do this based on an adversary capable of banning our technology. We therefore are not able to focus solely on the anonymity property. Instead, we first collect requirements for such a system in \cref{sec:genRequirements}. Based on these requirements, we explain our architectural concepts and decisions in \cref{sec:rationale}. We then build an outline of our protocol focusing on the protocol's main properties without going too much into implementation details. In \cref{sec:protocol}, we describe the protocol and its key concepts in depth. We explain all aspects relevant to the academic solution without going into implementation details. The implementation details are described in the RFC draft document in \cref{app:rfcMessageVortexMain}. Additionally, we describe the implementation's academically relevant details and their realization in infrastructure, in \cref{sec:implementation}. For operational concerns such as route-building strategies, refer to \cref{sec:operation}.

\chapter{Requirements for an Anonymizing Protocol}\label{sec:genRequirements}
In the following sections, we first define a threat model. We then elaborate on the main characteristics of the anonymizing protocol based on the threat model. This procedure allows us to build a coherent model for our target protocol.

We collected an overview of all isolated characteristics of \cref{sec:properties} in \cref{tab:requiremnts}. These properties are vital for the success of our system. We will elaborate on success or failure in \cref{sec:reqDiscussion}.

\begin{table*}[ht]\centering\tiny
	%\setlength{\aboverulesep}{0pt}
	%\setlength{\belowrulesep}{0pt}
	\newcolumntype{x}[1]{!{\centering\arraybackslash\vrule width #1}}
	\rowcolors{2}{black!30}{black!10}
	\bgroup
	\def\arraystretch{1.5}%  1 is the default, change whatever you need
	\begin{tabular}{|l|l|l|p{9.8cm}|}\hline
		ID   & Category    & Short               & Description \\\hline
		RQ1  & System      & Undetectable        & Protocol nodes and their traffic should be undistinguishable from accepted nodes and traffic. \\
		RQ2  & System      & Equal Nodes         & All nodes of the system should have similar functions, capabilities, and behavior. \\
		RQ3  & System      & Zero Trust          & No trust should be imposed on any infrastructure unless it is the senders' or the recipients' infrastructure.\\ 
		RQ4  & System      & Unlinkability       & Message Requirement A message must not be linkable by an adversary to either a sender or a recipient.\\ 
		RQ5  & System      & Anonymizing         & A system must be able to anonymize sender and recipient at any point of the transport layer and any point within the system unless on the senders' or the recipients' node. \\
		RQ6  & System      & Accounting          & The system must be able account for an entity without being linked to a real identity. \\
		RQ7  & Message     & Untagable           & The message should be untagable (neither by a sender nor an involved intermediate node). \\
		RQ8  & Message     & Unbugable           & The message should be unbugable (neither by the sender nor by an involved intermediate node). \\
		RQ9  & Message     & Unreplayable        & A message or its behavior must not be replayable. \\
		RQ10 & Operational & Bootstrapping       & The system must allow to bootstrap from a zero-knowledge or near-zero-knowledge point and extend the network on its own. \\
		RQ11 & Operational & Algorithmic variety & The system must be able to use multiple symmetric, asymmetric, and hashing algorithms to immediately fall back to a secure algorithm for all new messages if required. \\
		RQ12 & Operational & Easily handleable     & The system must be usable without cryptographic know-how and with popular or common tools. \\
		RQ13 & Operational & Reliable            & From a user's perspective, the system must act predictably. Messages handed over to the system should reach their destination in any case. \\
		RQ14 & Operational & Transparent         & From a user's perspective, the system must act predictably. He can determine the state of a message at any given point in time. \\
		RQ15 & Operational & Available           & A user must have access to a working system and its software and updates. \\
		RQ16 & Operational & Identifiable sender & A recipient of a message should be able to authenticate a sender of a message beyond a simple authentification.\\\hline
		
	\end{tabular}
	\egroup
	\caption{Summary table of requirements.}
	\label{tab:requiremnts}
\end{table*}

\section{Threat Model}\label{sec:adversary}\index{Threat model}\index{adversary}
Within this work, we look at two adversaries with differing behavior. The two adversaries are an ``observing adversary'' (mainly spying) and a ``censoring adversary'' (actively disrupting communication). While equal in their technical capabilities, they have different executive and legislative environments. This difference in adversaries is essential as the usage of our system differs in these two environments. We assume that one of these adversaries is present within any jurisdiction. 

We refer to ``\defref{jurisdiction}'' as a geographical area where a set of legal rules created by a single actor or a group of actors apply. These actors have executive capabilities (e.g., police, army, or secret service) to enforce this legal rule set.

We assume for our protocol that adversaries are state-sponsored actors or players of large organizations. Furthermore, we assume that these actors have high funding and elaborated capabilities either themselves or within reach of their sponsor. Actors may join forces with other actors as allies. However, achieving more than 50\% on a world scale is excluded from our model. We always assume one or more actors with disjoint interests covering half of the network or more. 

We assume the following goals for an adversary:
\begin{itemize}
	\item An adversary may want to disrupt non-authorized communication.
	\item An adversary may wish to read any information passing through portions of the Internet.
	\item An adversary may wish to build and conserve information about individuals or groups of individuals of any aspect of their life. 
\end{itemize}

To achieve these goals, we assume the following properties of our adversary:
\begin{itemize}
	\item An adversary has elaborated technical know-how to attack any infrastructure. This attack may cover any attack favoring his goals, starting with exploiting popular software weaknesses (e.g., buffer overflows or zero-day exploits) down to simple or elaborated (D)DoS attacks.
	
	\item An adversary may monitor traffic at any location in public networks within a jurisdiction.
	
	\item An adversary may freely modify routing information within a jurisdiction.
	
	\item An adversary may freely modify even cryptographically weak secured data where a single or a limited number of entities grant proof of authenticity or privacy.
	\item An adversary may inject or modify any data on the network of a jurisdiction.
	
	\item An adversary may create their nodes in a network. He may furthermore monitor their behavior and data flow without limitation.
	
	\item An adversary may have similar access to resources as within its jurisdiction in a limited number of other jurisdictions.
	
	\item An adversary may force a limited number of other non-allied nodes to expose their data to him. For this assumption, we explicitly excluded actors with disjoint interests.
	
\end{itemize}

As adversaries have different capabilities and goals, we should classify them among these boundaries as well. We therefore split up the adversaries into the following subclasses:
\begin{itemize}
	\item A censoring adversary
	\item An observing adversary
\end{itemize}

This adversary describes a powerful state-sponsored actor with very high but not unlimited powers. He serves us as a worst-case adversary.

\subsection{Observing Adversaries}\index{adversary!observing}
This adversary behaves like a traditional spy. He collects and classifies information while typically hiding his activities. The adversary only observes traffic and tries to extract data from the system.

Unlike the case of a censoring adversary, we imply that in most of the cases, no restrictions apply for the use of anonymizing technology from a jurisdictional point of view. If restrictions apply, then such an adversary should be classified as a censoring adversary, as the technology is ``censored.'' Such a classification must be carried out in this case, regardless of whether the adversary only tries to collect information or not.

\subsection{Censoring Adversaries}\index{adversary!censoring}
The primary goal of this adversary is censoring messages and opinions not within his interests. He does this regardless of whether the activities of censorship may be observed or not. Therefore, this adversary does not necessarily cloak his activities and typically classifies censorship circumventing actions as illegal.

In such environments $k$-anonymity, as specified in~\cite{k-anonymous:ccs2003}, may not be sufficient for such an adversary. Instead, the \MessageVortex{} system must hide all activities from such an adversary.

\subsection{Realism of the Assumed Adversaries}
The adversaries defined above are not realistic but ``worst-case assumptions''. An adversary may monitor certain spots within a network. Such spots are typically either jurisdictional borders or neuralgic points within a jurisdiction, such as the central router of an Internet service provider (ISP). However, it is not realistic that an adversary can tap any point of a network at a jurisdiction scale. Such tapping would require almost infinite bandwidth and unlimited access. 

Accessing cryptographically weak protected data is possible. However, accessing or modifying such data typically requires a high amount of calculation resources. Such resources may be available for a single case, but they typically do not scale if we assume high protocol usage,

Modifying network traffic would require even higher evolved capabilities as such modification requires tapping of a network and the capability to actively modify network traffic. Such modification is in practice almost always limited to a broadcast domain. This limitation typically means that all devices within a broadcast domain receive the same messages except if we direct the message to a single device. In our model, we state that the traffic may be freely modified at any point within the jurisdiction. This assumption is not realistic underlying today's common network technologies.
Furthermore, it is not realistic that a state-sponsored actor will carry out a DDoS attack against an entity within a jurisdiction, as simply blocking traffic would be far more effective and less resource binding. However, a DDoS attack may be a good solution when disrupting services within a jurisdiction not cooperating with the adversary's goals.

However, an adversary may have a limited number of accesses to the network with exactly these capabilities. As we cannot define or limit the number of access points, our defined adversaries reflect a worst-case assumption that may not be surpassed. Therefore, our adversaries, while not realistic, reflect a state where, if our protocol withstands such adversaries, it may be considered safe.

\section{Required Properties for Our Unobservable Protocol}\label{sec:properties}
In this section, we collect the required properties for our system. We first list a property and then explain why it is essential.

\subsection{Required System Properties}\label{sec:requirements}

\begin{requirement}{undetectable}{Undetectable}
	Protocol nodes and their traffic should be undistinguishable from accepted nodes and traffic. 
\end{requirement}

Users are unable to limit the route of network packets through named jurisdictions. Therefore, we must protect users of \MessageVortex{} from being subject to legal prosecution in any jurisdiction. All these users need to be anonymous when sending or receiving messages. This limitation applies not only to their communication but also to the usage of anonymization technology. Unfortunately, most transport protocols (in fact, all of the common ones such as \defref{SMTP}, SMS, \defref{XMPP}, IP, or messengers) use a globally unique identifier for senders and recipients. These addresses are readable by any party capable of reading the packets (mainly the routing nodes).  This identification contradicts anonymity.

In the threat model in \cref{sec:adversary}, we defined the adversary as someone with superior access to the network and its infrastructure. Such an adversary might attack a message flow in several ways:
\begin{itemize}
	\item Identifying the sender.
	\item Identifying the recipient.
	\item Identifying other involved parties (e.g.f, routers).
	\item Reading messages passed or extract meta information.
	\item Disrupting or modifying communication fully or partially. This may or may not include the possible identification of the traffic.
\end{itemize}

If users need to stay anonymous, they must protect their traffic from influences outside the system. As we are unable to protect data from modification, we must hide the traffic of our application. In such a scenario, an adversary cannot block our traffic unless he is willing to disrupt communication entirely by disrupting the transport protocol's communication. 

\begin{requirement}{P2P}{equal nodes}
	All nodes of the system should have similar functions, capabilities, and behavior.
\end{requirement}

This requirement protects all involved parties from possible legal prosecution. As we cannot introduce our infrastructure or protocols, any categorization from outside or inside would lead to an information leak. 

We have to assume that all actions taken by a potential adversary are not subject to legal prosecution. This assumption is based on the fact that an adversary trying to establish censorship may be part of the jurisdiction's government. We may safely assume that there are legal exceptions in some jurisdictions for such entities. Having such legal means enables an adversary to introduce legally spying nodes into our system.

To withstand an adversary outlined in \cref{sec:adversary}, the messages sent even within the system must be unidentifiable by meta-information or content. ``Meta-information'' may refer to any information including, but not limited to, frequency, timing, message size, sender, protocol, ports, or recipient. If we want to guarantee that a node is not identifiable as an endpoint of a message, all involved nodes must carry out equivalent \defref{operation}s. As soon as we have differences between routing nodes and endpoints, we can identify participating persons at entry or exit nodes.

If we want a user's traffic to remain indistinguishable from traffic generated from routing nodes, all traffic must have the same properties. This applies not only after ``entering the system'' but at any time. As a result, only an infrastructure-less approach may be used as a consequence. A hybrid or server-based approach requires infrastructure to be placed within the Internet. Jurisdictions with a censoring adversary may place focus on such systems and identify and prosecute their owners. 

Furthermore, it must be impossible for an observing adversary to identify message endpoints. All nodes must look equal from the outside in terms of traffic, as well as by offered functions and behavior. The term ``Equal nodes'' does not necessarily mean that nodes must be indistinguishable. It merely means that given the functions, capabilities and behavior of a node, no further information can be deduced and no differentiation in function may be achieved.

\begin{requirement}{zeroTrust}{zero trust}
	No trust should be imposed on any infrastructure unless it is the senders' or the recipients' infrastructure.
\end{requirement}    

The requirements above protect from an adversary outside the system. From the inside, an adversary may have access to much more information. An adversary will likely create nodes in an open system. As a consequence, trust in infrastructure is minimal.

In our model, we will be suspicious of the infrastructure. As every infrastructure node learns from each transaction (e.g., the usage of the network or size of messages), we have to minimize or ideally eradicate such information gains. The main problem is that we are unable to hide peer senders or recipients when routing messages. In jurisdictions where such infrastructure usage is illegal, we need to protect the presence of our routing messages from any distrusted party. Such hiding concludes that we need to be able to control which nodes are involved when sending messages. We refer to this concept as controllable trust.

In terms of the trust, we conclude that:
\begin{enumerate}
	\item We trust in infrastructure because it is under full control of either the sender or the recipient. If we are unable to trust these infrastructures, information may be leaked without problem. Thus, trusting these infrastructures is inevitable.
	\item We should not trust any other infrastructures, as an adversary can misuse data passing through.
\end{enumerate}

\begin{requirement}{unlink}{unlinkability}
	A message must not be linkable by an adversary to either a sender or a recipient.
\end{requirement}

We need a requirement guaranteeing the unlinkability between the sender and recipient from an adversary's point of view. This prevents building social graphs and narrowing down groups of individuals.

\begin{requirement}{anon}{anonymization}
	A system must anonymize the sender and recipient at any point of the transport layer and at any point within the system unless on the senders' or the recipients' node.
\end{requirement}

Unobservability requires, according to~\cite{anonTerminology}, an item of interest (\defref{IoI}) to be undetectable from an uninvolved entity and anonymous for the involved entities. We therefore require anonymization as a property.

As a result of the architecture of today's common networks, the anonymization of a sender or a receiver is not simple. A relay may allow at least the anonymization of the original sender given the trust into such an infrastructure. 
By combining it with encryption, we may even achieve a simple form of a sender and receiver pseudonymity, even for a weak outside observer. This has been accomplished in Cypherpunk remailers (see \cref{sec:remailersAndMixnets}). If we cascade more relay-like infrastructures and combine them with cryptography, we may achieve sender and receiver anonymity. When we then introduce anonymous remailing endpoints, we may additionally achieve both simultaneously. These are the standard approaches in remailers and mixes. We have seen real-world attacks on such systems in the past, and some were successful (e.g.,~\cite{penetClosure}). 

\cite{anonTerminology} defines anonymity as:
\begin{shadequote}{}
	Anonymity of a subject means that the subject is not identifiable within a set of subjects, the anonymity set.
\end{shadequote}

If we apply our threat model, we find that we require all users to be anonymous, regardless of whether a specific user is sending messages or not. Otherwise, such a user may become subject to legal prosecution. 

\begin{requirement}{accounting}{accounting}
	The system must be able to account for an entity without being linked to a real identity.
\end{requirement}

As a system may be flooded with messages, we need means to control the burden of processed messages. To separate message flows, we need means to control them by identity. Unlike other protocols, we have no identifier as we work based on the previous requirement anonymity. We will however require some type of accounting to keep adversaries from flooding our system.

\subsection{Message Requirements}
From the message point-of-view, we need to conserve privacy, which has been elaborated on in the previous section.

\begin{requirement}{untagable}{untagable}
	The message should be untagable (neither by a sender nor by an involved intermediate node).
\end{requirement}

\index{taging}To protect a message from being followed or observed, a message requires certain properties. First, a message should not have, by design, any properties which can be observed when passing through the system. Any node should remove all parts which were under control of the previous node.

\ref{req:zeroTrust} implies that a node may try to introduce such features into the message. As we cannot keep a node from doing so, we can define that such tags must be removed by the next node. This may only be done if any node apart from the sender and recipient node does not have access to the message being transported or the message is protected from modification.

\begin{requirement}{unbugable}{unbugable}
	The message should be unbugable (neither by the sender nor by an involved intermediate node).
\end{requirement}

\index{bugging}Another way of breaking anonymity is that instead of following a message through the system, an adversary may modify (bug) it so that the receiving or any intermediate node leaks its presence. In traditional messaging such bugging is carried out by introducing remotely hosted data or by introducing revocable certificate operations into the message stream and then observing the VA of a PKI for respective OCSP calls or CRL accesses. DNS or similar information lookups may be used as well. Our protocol handling must not depend on such external lookup or download mechanisms to ensure that bugging is not possible.

This property applies not only to the message content itself but also to any routing node processing. All operations carried out need to be standalone and should not be queryable or detectable from an outside observer even if he is able to manipulate the message content.

\begin{requirement}{unreplayable}{unreplayable}
	A message or its behavior must not be replayable.
\end{requirement}

In a generic sense, a node may also replay a message to highlight a messages property (e.g., the path or size), which may lead to the discovery of such meta-information. 

\subsection{Operational Requirements}
In order to be realistically operated, our system needs to fulfill some additional requirements.

\begin{requirement}{boot}{bootstrapping}
	The system must allow to bootstrap from a zero-knowledge or near-zero-knowledge point and extend the network on its own. 
\end{requirement}
Until here, we described a system that is not centrally controlled. If not relying on broadcast domains, which is not feasible on a global scale, each node needs to know other nodes that may be contacted for routing purposes. We refer to the initial process of collecting routing nodes as bootstrapping.

This bootstrapping is needed for users to extend their network at first to a reasonable anonymity set assuming an adversary inside the system. At the same time, the bootstrapping mechanism is a great danger as it allows an adversary to harvest nodes. As a result, each node must be able to control by whom a node is discoverable.

\begin{requirement}{algVar}{algorithmic variety}
	The system must be able to use multiple symmetric, asymmetric, and hashing algorithms to immediately fall back to a secure algorithm for all new messages if required. 
\end{requirement}

Weaknesses in algorithms are discovered quite commonly. We may therefore not rely on a single algorithm. Instead, we must create a protocol supporting processing alternatives for algorithms. This includes crypto agility, as described in~\cite{bsiPostQuantum}.

\begin{requirement}{easy}{easy handleable}
	The system must be usable without cryptographic know-how and with popular or common tools.
\end{requirement}

Academic systems are usually not known for focusing on user-friendliness. Users, on the other hand, are not known for their willingness to sacrifice functionality or usability for security. If we want our system to be secure, we require many users to generate a sufficient level of decoy traffic. This would lower the bar for bootstrapping and increase the size of anonymity sets. We therefore conclude that the system must be easy to handle for a user. Usually, this would be a decision related to a GUI or an end-user application but not to a system. However, if we want our system to be easy to handle, we need to take this into account as a requirement.

\begin{requirement}{reliable}{reliable}
	From a user's perspective, the system must act in a predictable manner. Messages handed over to the system should reach their destination in any case.
\end{requirement}

Any message-sending protocol needs to be reliable in its functionality. If the means of message transport are unreliable, users tend to use different means for communication~\cite{zhou2011examining}. 

\begin{requirement}{transparent}{transparent}
	From a user's perspective, the system must act in a predictable manner. The user is able to determine the state of a message at any given point in time.
\end{requirement}

Transparent behavior is a prerequisite for reliability. If something generates acertain behavior, but a user is unable to determine the reason for it (i.e., if a user expects a different behavior), he would usually assume a malfunction. Therefore, ``reliable'' means not only stable by its behavior. It also means that the system has to be diagnosable. A user's perception will not be ``reliable'' if he is not able to determine causes for differences in observed and expected behavior (e.g.,~\cite{nicholson2003assessing}).

\begin{requirement}{available}{available}
	A user must have access to a working system and its software and updates.
\end{requirement}

If a user should be able to use the system, he needs access to other nodes and the required software, as well as its updates. This has to be considered even in an environment with a censoring adversary which means that the system needs to be available.

Availability, in this specific context, may have two differing meanings. A system is available if\ldots
\begin{enumerate}
	\item a sender and a recipient have (or may have) the means of using it.
	\item the infrastructure provides the service, as opposed to: ``is running in a degraded or dysfunctional state and, therefore, possibly unable to provide the service.''
\end{enumerate}

\begin{requirement}{senderId}{identifiable sender}
	A recipient of a message should be able to authenticate a sender of a message beyond a simple authentification.
\end{requirement}

A messaging system offering unlinkability may offer sender anonymity from a recipient's perspective. If so, a sender should be identifiable in such a way that a classification of senders is possible for a legitimate recipient and impersonation is not achievable. It is important to understand that an identifiable sender does not necessarily mean that users can identify a sender as a specific party. It only means that two senders may be identified as the same sender.

We did not consider efficiency as a requirement, as our goal is to achieve anonymity under harsh conditions. 

\chapter{Rationale}\label{sec:rationale}
In this chapter, we set the course for our system. We explain why we built the protocol the way it is. We elaborate on our decisions and explain why the system is not built differently.

The system we describe is a four-layered system (transport, blending, routing, and accounting layer) in which each layer fulfills a specific duty. The transport layer is equal to an unmodified, common Internet data transport protocol. The blending layer inserts and extracts our protocol messages into the transport layer. The routing layer disassembles and reassembles the messages received and applies specially crafted operations, and the accounting layer tracks the  quotas and protects the system's resources. The three \MessageVortex{} layers (all layers except ``transport'') run on common Internet end-user devices such as mobile phones or tablets.

\section{System Design and Infrastructure}
All anonymity systems listed in \cref{sec:systems} have in common that they rely on dedicated servers providing an anonymity-related service. Such specialized servers make operators or owners of such servers vulnerable in an environment where a censoring adversary (as described in \cref{sec:adversary}) exists. Therefore, our approach should be different. Instead of creating our own protocol, we describe a system where we use pre-existing standard servers without modification for our purpose. If we succeed in ivisibly piggybacking such a protocol, we may inherit the regular usage of this infrastructure as decoy traffic. Piggybacking and mimicking protocols is not new. Protocols such as Skypemorph~\cite{mohajeri2012skypemorph} or pluggable transports for Tor (e.g., Meek, FTE, or OBFS4) use this technology successfully for censorship circumvention.

Piggybacking is executed in a protocol-agnostic manner. On the protocol level, this requires that we separate the embedding of messages into the transport protocol from the rest of the system. This makes the system even more difficult to observe as routing graphs taking multiple protocols into account increase the complexity exponentially through their different properties.

Important properties of piggybacking are mainly:
\begin{itemize}
	\item \ldots the importance or significance of the transport protocol.\\
	The more important the transport protocol, the higher the barrier to censor the entire protocol.
	\item \ldots the traffic load.\\
	The higher the load created by the transport protocol for analyzing the data, the more difficult it is to uncover messages.
	\item \ldots the quality of the piggybacking\\
	The harder it is to identify a single message as part of the protocol or not, the harder it is to establish censorship.
\end{itemize} 

The content of the message in the transport layer protocol is provided by the routing node and not by anyone or anything else. This restriction is based on the fact that if we allow anyone else except the routing node itself to control visible aspects of the transport layer message, the system could be misused for sending transport layer messages. To give an example: Such a system could be misused for blackmailing a user not participating in the system. We simply create a message obfuscating the source and then exit the system by embedding the true blackmailing message. 

As we rely on third-party infrastructure with our approach, we have to ensure that when designing our approach not to violate requirement \ref{req:zeroTrust}. For obvious reasons, a direct connection between the sender and recipient via any named transport protocol would violate the requirement \ref{req:unlink}. A single intermediate node would minimally imply trust in this node and its anonymization capabilities, which is not acceptable due to the requirement \ref{req:zeroTrust}. When using multiple nodes, other anonymization protocols typically use three to five intermediate nodes due to their arguing. Such protocols typically have at least three anonymization nodes for obvious reasons and sometimes an entry and exit node summing up to five nodes. This implies that the routing of our protocol is required. As we have a \ref{req:zeroTrust} policy, decisions for routing may no longer take place on the routing node but must be dictated externally. Some protocols (such as a typical Crowds-based system) have weaknesses as each node may decide on the subsequent node and choose one in their favor.

For routing, we will use end-user devices. This decision is further backed by the requirement \ref{req:P2P}. It however opposes the requirement of \ref{req:reliable}, as such system participants are likely to be unreliable due to missing network connectivity, device failure due to drained batteries, or simply because they no longer participate in a network. To counter this, we implement measures on the message level.


\section{Message and Routing}\index{message!routing}
One of the biggest weaknesses of all protocols is the information leakage they have by design and the inability to restrict access to their functionality. We will build the messages with the following design guidelines:
\begin{itemize}
	\item No routing controlled content shall survive a hop.\\
	For us, this means that by design a message is received and dismantled. Any content visible or manipulatable by the previous node must be removed. Only new content or content inaccessible to the previous node may be used to build new messages. Following this criterion, we automatically fulfill the requirement \ref{req:untagable}.
	\item A routing node may efficiently identify a message sender.\\      
	The sender must be efficiently identifiable. At first sight, this requirement is non-fitting as it opposes heavily to \ref{req:anon} and \ref{req:unlink}. On the other hand, not providing these means makes it next to impossible to create a system that may not be misused and flooded. As the identification is pseudonymous, it must be short-lived, and multiple identities of the same sender must not be linked to each other. We will refer to this identity as an ephemeral ID (\defref{eID}). This \defref{eID} is handled in such a way that no complete decoding of the message is required to authorize the user. Instead, we build a message in such a way that tamper-proof, small-sized parts of the message are decoded first, and possibly bloated message content may be decoded after it is clear that the content is acceptable. If we assign ``costs'' to the creation of \defref{eID}s, it effectively protects the system from flooding.
	\item The routing \defref{operation}s must not leak more information than the next hop.\\
	We will apply a transformation on each routing hop to the message. This prevents following the message throughout the system. In most of the systems, messages are mainly disassembled and reassembled, or onionized. Additionally, the traffic of our system is cloaked in mimicking traffic, making it next to impossible for an outside observer to identify message flows. In other systems however, the node generating decoy or mimicking traffic is well aware of the true message flow. In our system, instead of mimicking traffic, we add redundancy information (or remove it). By doing so, a routing node no longer has insight into which part of the traffic is relevant to the message and which part is not. Furthermore, we may introduce the possibility of distributing the message content throughout multiple paths in such a way that each path has insufficient content to rebuild the message. In fact, depending on the complementing missing message, any content received or sent by a node may be valid in our system. 
	\item Messages are protected from being replayed.\\
	In former systems, message paths were highlighted by injecting additional information. Our system is already protected from such injections by the \defref{eID} concept, which identifies the sender. There are however other means for highlighting traffic. An adversary may either inject message payload (corrupting the message flow) or replay the message. While we cannot keep anyone from violating the rules, we may at least implement replay protection. Furthermore, we may later discover that we are able to identify willingly induced or size mismatching content.
	\item Messages in the routing system are ``store and forward.''\\
	All synchronous routing systems have in common that message observation is relatively easy for an outside or inside observer with a sufficient number of observation points unless mimicking routes are used. This is why we allow the message to be stored and picked up or sent at a later stage. 
	\item Use the Reed--Solomon-function as our main routing \defref{operation}.\\
	Originally,~\cite{reed1960polynomial} introduced a system allowing the use of polynomes to create error-correcting codes. In~\cite{chaum1988multiparty} \citeauthor{chaum1988multiparty}, have shown that the codes are suitable for distributing data assuming enough parties are honest and not malfunctioning. Unlike \citeauthor{chaum1988multiparty} proposition, we do not use the Reed--Solomon-function to achieve anonymity or privacy. Instead, we use it for decoy traffic generation. We split a message into multiple parts at several points by adding redundancy information while routing and assembling it again on the target node. By doing so, we achieve two vital things. First, we introduce the possibility of recovering errors due to misbehaving nodes, and secondly, the real traffic can no longer be differentiated from decoy traffic. 
	\item \MessageVortex{} must provide a variety of algorithms and \defref{operation}s to build a message.\\        
	As all systems and algorithms applied to the system may be weakened or fail, a system needs to have the possibility to choose from multiple algorithms, protocols, and infrastructures. This choice should be made by a trustworthy system that restricts us from either the sender or the receiving system. The German Federal Office for Information Security (BSI) makes recommendations in~\cite{bsiPostQuantum} for systems and protocols, which we intend to follow.
	
	The main text can be condensed to the following recommendations:
	\begin{itemize}
		\item A protocol or system should be crypto agile.
		\item A protocol or system should use signatures for updates.
		\item The document furthermore recommends using symmetrical keys with a key length of 128 bit or more.
		\item The document recommends a combination of large, long-term keys and small, short-term keys.
		\item The document recommends using a combination of multiple independent algorithms in cascaded forms so that if one algorithm fails, the other one is still able to protect the data.
		\item For key exchange, BSI recommends lattice-based cryptography.
	\end{itemize} 
\end{itemize}

\section{Summarizing Chosen Approaches for \MessageVortex}\label{sec:reqSummary}
In this section, we made the following decisions for \MessageVortex:
\begin{itemize}
	\item Piggybacks common protocols.
	\item Does not require specialized infrastructure within the Internet.
	\item No proprietary systems on the Internet.
	\item Runs on commodity hardware.
	\item Sends messages in an asynchronous mode.
	\item Creates unidentifiable decoy traffic by using a Reed--Solomon-function.
	\item Has no strict message size and strictly avoids increasing or decreasing sizes in any type of message or message part.
	\item Does not enforce specific attributes such as transport protocol, message size, message timing, or providers.
	\item Run offers routing \defref{operation}s instead of traditional mixing and recombination methods.
	\item Offers a choice of algorithms when routing.
	\item Offers short-lived pseudonyms to enable the identification of the original sender.
\end{itemize}

The protocol is a four-layer protocol, as shown in \cref{fig:protocolLayers} on page \pageref{fig:protocolLayers}. We communicate with standard protocols, which we refer to as the transport layer. While included in the message flow, they do not form a part of the \VortexNode. The \VortexNode{} itself consists of the three layers ``Blending'', ``Routing'', and ``Accounting''.

The blending layer is the bridging part linking a transport layer to the \VortexNode{}. It injects and extracts messages from the transport layer and passes the extracted messages to the routing layer. It may be either used as a protocol bridge (e.g., in the case of XMPP) or act as a sophisticated router (e.g., in the case of email protocols, where mails are fetched or received on push event via POP3 or IMAP while sending messages using SMTP).

The routing layer receives unified standard messages from the blending layer, processes them, possibly extracts messages for local delivery, and passes subsequently created messages to the blending layer.

This design is definitely implementable on a consumer device. On the other hand, it is also scalable and suitable for a clustered environment. Blending can be achieved in a stateless manner, is even suitable for serverless computing, and thus largely scalable. Routing may be implemented either with horizontal partitioning along with a set of \defref{eID}s or on a serverless base with a unified storage in the background. The accounting layer acts as a controller and may be implemented as well as a stateless service with a minimal NOSQL-storage for all \defref{eID}s. 

\chapter{Protocol}\label{sec:protocol}
\MessageVortex{} is a protocol piggybacking standard transport protocols similar to S/MIME~\cite{rfc2015} or PGP~\cite{PGP}. Unlike these protocols, we require the capability to keep the presence of our messages secret. The message itself should only be visible to an intended node.\MessageVortex{} itself is agnostic to the transport, but we do require appropriate blending to hide credibly within the transport protocol. The information processed on a node and its associated meta-information should not leak any information about the processed message. 

Our system sends so-called \VortexMessages. These messages are hidden within a transport protocol (e.g., SMTP or XMPP) with a blending mechanism (e.g., the steganographic algorithm F5) and extracted by a blending layer. The extracted \VortexMessage{} is an encrypted, structureless blob, which is handed over to a routing layer. The \VortexMessage{} itself contains a header block, a routing block, and possibly some payload blocks. The header block contains all the information required to protect the system. The routing block contains instructions (so-called ``\defref{operation}s'') on how the payload blocks are processed and where to send the resulting blocks. Those \defref{operation}s are one of the keys as information leakage occurs in this step in most of the systems. We therefore crafted all \defref{operation}s very carefully to keep as much information secret as possible. These \defref{operation}s are key to the system as they allow us to increase and decrease the size of a message without revealing what part of the data is a decoy and what is not.

A payload may either be kept by the system for later processing with other messages, processed (possibly with different) payload blocks, or displayed to the ``local user'' as a message.

The general idea of the protocol is to form a network from nodes that mix and route messages between the sender and receiver. A routing block builder (\defref{RBB}), which is typically identical to the sender, has full control over almost all attributes of the message, and nodes are unable to learn anything from the message while routing. Each user has a node, and there may be additional nodes (public routing nodes) without a user connected to it. 

The message is either onion-like encrypted, split into parts and remerged, or blown up with redundancy information. 

This behavior results in a mixing-like a system with a decoy generation in which even decoy generating nodes are unable to differentiate between real traffic and decoy as all blocks always contain parts of the message. Routing decisions are controlled by the builder of the routing block, and redundancy is possible and controlled by the routing block builder to make the system more stable.

In the following sections, we describe this protocol in detail. First, we build a terminology implicitly used in the previous chapters. Then we describe the key concepts and techniques of the protocol without in-depth analysis or reasoning. The implementation and operational aspects are discussed in \cref{sec:implementation} and \cref{sec:operation}. 


\section{Protocol Terminology}
For our protocol, we use the following terms:
\begin{itemize}
	\item \textbf{\defref{sender}:} The user or process originally composing the message. In contrast to the \defref{sender}, the \defref{immediate sender} is the node sending the message to the current node. It may or may not be identical to the \defref{sender}.
	\item \textbf{\defref{recipient}:} The user or process destined to receive the message in the end.
	\item \textbf{\defref{user}:} Any entity, running a \MessageVortex{} node.
	\item \textbf{\defref{router}:} Any node processing the message. Please note that all \VortexNode{}s are routers. This includes the senders' and recipients' node.
	\item \textbf{\defref{message}:} The ``real content'' to be transferred from the sender to the recipient.    
	\item \textbf{\defref{VortexMessage}:} The encoded message passed from one node to another. The \VortexMessage{} is considered before any embedding takes place. If embedded, we refer to such a message as ``embedded \VortexMessage''.
	\item \textbf{\defref{payload}:} Any data transported in a \VortexMessage{} between routers with exception to the routing and header block, regardless of the meaningfulness or relevance to the \VortexMessage.
	\item \textbf{\defref{decoy traffic}:} Any payload transported between routers that has no relevance to the message at the final destination.
	\item \textbf{\defref{identity}:} A tuple of a routable address and a public key. This tuple is a long-living tuple but may be exchanged from time to time. An Identity is always assigned to a node, but one node may have multiple identities. 
	\item \textbf{\defref{eID}:} An identity created on any node with a limited lifetime and anyone possessing the private key (proven by encrypting with it) is accepted as representative of that identity. An \defref{eID} has a \defref{workspace} associated to it. Please note that an \defref{eID}{} is not identical to an \defref{ID}{} which is a numerical identifier for a payload block storage location within a workspace.
	\item \textbf{Routing Block Builder (\defref{RBB}):} An entity, which builds a routing block. Typically identical to either the sender or recipient.
\end{itemize}

\section{Key Components}
The following sections describe some key components of the system. Understanding them is essential for the understanding of the protocol as a whole. 

We first describe a single node and its identity. This node is always equivalent to a potential sender, recipient, or router. 

We then introduce the concept of \defref{workspace}s and ephemeral identities (\defref{eID}s). These concepts are essential for the routing and accounting layers. They dictate memory and storage requirements and lay a foundation for the routing layer.

Understanding the protocol layers' inner workings is essential to the understanding of the project as a whole. We emphasize their main function and their inner workings without going into implementation details. These details are further discussed in \cref{sec:implementation}. We mainly focus on the data and the high-level processing within these layers.

\subsection{Nodes and Their Identities}\index{node}\index{identity}
We refer to a \VortexNode{} (node) as a system run by an individual containing a software processing \VortexMessages. Each node is connected to a transport layer protocol service (e.g., an IMAPv4 server as an endpoint for email or an XMPP server). A node is not a server but a device connected to a regular, unmodified transport service provider. Such transport services may be an SMTP/IMAPv4/POP3 account, an XMPP account, or a similar transport protocol account.

Each node $o$ has at least one identity reflected by an asymmetric key pair $K_{host_o}$. Any node $p$ communicating with node $o$ must have the public key  $K^1_{host_o}$ of the node.

A node requires the key $K^1_{host_o}$ to encrypt a message for node $o$. This key know-how enables environments with censoring adversaries to withstand probing attacks, because without the knowledge of such keys, no reply from a node is received. The transport endpoint itself is not a secret. The usage as \VortexNode however is kept secret as long as the key is unknown.

The protocol itself has the possibility to answer cleartext requests. So-called ``public nodes'' (see \cref{sec:vortexNodeTypes}) make use of such messages. They are, however, an exception. In general, all \VortexMessages{} are encrypted. 

\subsection{Workspaces and Ephemeral Identities}\index{identity!ephemeral}\index{workspace}
We dumped the approach for a system with a global, unified storage for all message processing. Such a design would allow an adversary to flood our storage. Instead, we introduced temporary storages suitable for a set of transactions belonging to a single identity or a limited set of collaborating entities. In our system, every transaction on a node is assigned to an ephemeral identity (\defref{eID}). An \defref{eID} has a limited lifetime and is represented by an asymmetric key pair and has to be created on each \VortexNode{} taking part in message processing. Each \defref{eID} has a storage assigned to which we refer as ``\defref{workspace}''. A simplified outline of a \defref{workspace} is shown in \cref{fig:workspace}.

An \defref{eID} is unique on every host and created on each \VortexNode{} by the routing block builder (\defref{RBB}). To create an \defref{eID}, an \defref{RBB} first sends a message with only a header block to the respective \VortexNode. The request contains the new identity, a reply block, and a request to create a new identity. The receiving \VortexNode{} will then typically send a challenge back. A challenge may be the start of a hash bit sequence (also referred to as ``puzzle''). The requester has then to resend the request with a header block. The requester must insert additional data in such a way that the start hash in its binary form matches the bit sequence provided. Another possibility is to request payment in a cryptocurrency. This allows us to commercialize routers in some countries where the usage of such routers is generally allowed.

The length of the requested bit sequence is chosen by the accounting layer at its own will. If the request is not answered in a given time, the \defref{eID} will be discarded. Analogous to an SYN-Flood attack, an adversary may try to overwhelm a \VortexNode{} with \defref{eID} creation requests. Such flooding will be much more costly for the adversary than for the \VortexNode{}, and such a node may decide to temporarily no longer accept new \defref{eID} requests without affecting already existing \defref{eID}s.

Each \defref{eID} has a lifetime, a maximum number of messages to be processed, and a maximum number of bytes to be sent assigned to it. The lifetime of an \defref{eID} is typically days and maybe up to a few months. Lifetimes may not be extended and are defined by the sender of the request. A node may accept or decline the request if the lifetime of the request or the state of the node does not meet its expectation. The puzzle sent in return may be a fixed value or related to the nodes' current state and load.

This system guarantees that a sender must invest considerable work (in terms of CPU time required) prior to using resources of a \VortexNode. A \VortexNode{} may raise the complexity of its puzzles when having a high load. This allows for a single user to still obtain an \defref{eID} while increasing costs for an attacker considerably raises the bar for DoS attacks. Even if someone floods a node with new \defref{eID}s, already created \defref{eID}s are not affected as their \defref{workspace} has already been allocated.

\begin{figure}[ht]
	\centering\resizebox{.95\linewidth}{!}{
		\input{inc/workspace.inc.tex}
	}
	\caption{Simplified outline of a workspace in a \VortexNode.}
	\label{fig:workspace}
\end{figure}


The \defref{workspace} (see \cref{fig:workspace}) itself contains chunks of the messages (payload blocks)\index{payload block} mapped to \defref{ID}s and \defref{operation}s. The \defref{operation}s transform one or more source \defref{ID}s onto one or more target \defref{ID}s. Any of these payload blocks may be assigned to a subsequent message as payload block by a routing block. An \defref{operation} or a payload block share the lifetime of the respective message header. If \defref{operation}s overlap in output blocks, the newest \defref{operation} (arrived latest) wins. Arriving \VortexMessages{} map their payloads onto \defref{ID}s of the respective \defref{workspace} of the \defref{eID}. To allow such mapping, the first IDs are special \defref{ID}s either mapping to the \defref{ID} 0 (message for local delivery) or \defref{ID}s 1-127 (always reflecting the current message [ingoing or outgoing]).

This concept has certain disadvantages related to the expiration of \defref{eID}s. We will address them in \cref{sec:newEID} and \ref{sec:replaceMURB}.

\subsection{Protocol Layers}
As already introduced in \cref{sec:reqSummary}, the protocol is built on multiple software layers. The layers are shown in \cref{fig:protocolLayers}.

\begin{figure}[H]
	\resizebox{0.95\textwidth}{!}{\input{inc/layerDesign.inc.tex}}
	\caption{The protocol layers.}
	\label{fig:protocolLayers}
\end{figure} %FIXME large gap between figure and title of figure

On the logic side, the protocol is split into two parts:
\begin{enumerate}
	\item Transport Layer\\
	Standard Internet infrastructures provide this layer. The primary goal is to hide or blend our protocol into regular traffic within that layer. Typical examples for such layers are SMTP or XMPP servers.
	\item Blending and subsequent layers (the Vortex infrastructure)\\
	Any user of the Internet may provide these layers. Since these layers may be only Vortex routing nodes or valid endpoints, the nodes may or may not be publicly known. In a first implementation, we build this system as a standard Java application. The primary goal is to compile it to native code afterward and run it on an SoC-like infrastructure such as a RaspberryPi or port it to an android device.
	
	We may further split the Vortex infrastructure layers into
	\begin{enumerate}
		\item  Blending layer\\
		This layer receives messages from the Vortex system and creates transport layer conformant messages and vice-versa. In an ideal case, the messages generated by this layer are indistinguishable from any regular message traffic of the transport layer, and the embedded message is only detectable by the receiving node.
		\item Routing layer\\
		The routing layer disassembles and reassembles messages. 
		\item Accounting layer\\
		The accounting layer has three jobs. First, it has to authorize the message processing after the decryption of the header block by the blending layer. Secondly, the accounting layer handles all header request blocks and the reply blocks. Third, it keeps track of the accounting regarding the sent messages. Its main purpose is to protect the system from misuse or flooding.    
	\end{enumerate}
\end{enumerate}

In total, we have four layers. The bottom-most layer consists of unmodified standard infrastructure for transport within the Internet, and the three layers on top build a single \VortexNode. There is always one accounting and one routing layer. Blending layers exist on a ``need to have'' basis. Typically, there is one blending layer per transport protocol or transport protocol account.

\subsection{Transport Layer}
The transport layer is a standard protocol within the Internet. It is neither a \MessageVortex{}-specific infrastructure, nor has it been modified for the purpose. Instead, it serves the purpose of a storing and forwarding medium. This medium solves two major problems. First, no NAT traversal technology such as ``TCP hairpins'' or ``hole punching'' is required. Secondly, it compensates for short outages due to regional routing problems to the end-user (e.g., networking problems on the Internet).

A transport layer should have some generic properties:
\begin{itemize}
	\item Widely adopted 
	\item Reliable
	\item Symmetrically built 
\end{itemize}

For a more detailed description of the criteria, see \cref{sec:transportCriteria}.

For our first tests, we used a custom transport layer, allowing us to monitor all traffic quickly, and build structures in a very flexible way. This transport layer works locally or in a broadcast-based network with a minimum amount of work for setup and deployment. The API we used may however be used to support almost any kind of transport protocol.

In \cref{sec:transportProtocols}, we share a short analysis going through some common protocols outlining the strength and weaknesses of common transport protocols within the Internet.

After that, we focused on the protocols identified in the previous sections for transport:
\begin{itemize}
	\item \defref{SMTP}
	\item \defref{XMPP}
\end{itemize}

For the prototype, we have implemented an SMTP transport agent and the respective blending layer.

\subsubsection{Blending Layer}\label{sec:blendingLayer}
The blending layer solves multiple problems:
\begin{itemize}
	\item It translates the message block into a suitable format for transport\\
	This translation includes jobs such as embedding a block as encoded text, as a binary attachment, or hiding it within a message using steganography. Another demanding task in this context is to create credible content for the transport message itself.
	\item Extracts incoming blocks\\
	Identifying incoming messages containing a possible block and extract it from the message.
	\item Does housekeeping on the storage layer of the transport protocol\\
	Access protocols such as POP and IMAP require that messages are deleted from time to time to stay below the sizing quotas of an account. Managing this transport layer account is the job of the blending layer.
\end{itemize}

There is no specification on the housekeeping of the blending layer, as this is specific to the requirements of the account owner. We do, however, recommend handling messages precisely as if they were on an account handled by a human unless the receiving account appears to be a machine account. 

The blending is currently achieved by merging the \VortexMessage{} using either F5 as described in~\cite{f5} or by plain blending, which is a binary embedding. For both embeddings we currently need jpeg images included in the SMTP message. 

\paragraph{Processing a message received from the transport layer}~\\
We define the blending layer to work as follows when receiving messages:
\begin{enumerate}
	\item Logging arrival time on the transport layer.
	\item Extracting possible \VortexMessage.
	\item Applying decryption on a suspected header block of \VortexMessage.
	\item Identifying the header block as valid by querying the accounting layer.
	\item Extracting and decrypt subsequent blocks.
	\item Passing extracted blocks and information to the routing layer.
\end{enumerate}

A more accurate and precise outline may be found in \cref{sec:processingIncommingMessages}.

\paragraph{Processing a message received from the routing layer}~\\
We define the blending layer to work as follows for sending messages:
\begin{enumerate}
	\item Assembling message as passed on by the routing layer.
	\item Using the blending method specified in the routing block, build an empty message. 
	\item Creating a message decoy content.
	\item Sending the message to the appropriate recipient using the transport layer protocol.
\end{enumerate}

For more details regarding the exact sequence and implementation decisions, refer to \cref{sec:processingOutgoingMessages}.

\paragraph{Credible content creation for the transport layer}~\\
One of the most demanding tasks of the blending layer is to create transport protocol messages. In~\cite{oakland2013-parrot}, \citeauthor{oakland2013-parrot} expresses that it is easy for a human to determine decoy traffic as the content is easily identifiable as generated content. While this may be true, there is a possibility here to generate ``human-like'' data traffic to a certain extent. For the blending layer, it is not necessarily required to mimic human messages. Instead, the blending layer may generate messages such as password recovery messages, monitoring messages, and even \defref{UBM}-like the content. All these messages have required properties in common. First, all of them are machine-generated messages which are modified quite often. All of these messages are known to be sent and possibly adapted individually. 

For the blending itself, we required a steganographic algorithm. After reviewing the options, we decided on F5~\cite{f5} as a steganographic algorithm, which attracted many researchers. The original F5 implementation had a detectable issue with artifacts~\cite{F5broken} caused by the recompression of the image. This issue occurred only due to a problem in the reference implementation, and the researchers have provided a corrected reference implementation without the weakness.

We searched for other steganographic algorithms but were unable to find any other suitable algorithm apart from F5, which fulfilled the following set of criteria:
\begin{itemize}
	\item Unbroken.
	\item Researched.
	\item Suitable for embedding in lossy-compressed, common image formats (e.g., jpeg).
	\item An implementation or a well-specified algorithm exists.
\end{itemize}

We decided to keep our plain embedding algorithm in the implementation. It already requires an in-depth analysis or a human to detect embedding, and the message itself is, even if detected, well-protected. Its biggest strength is its efficiency. This algorithm is, however, only suitable for public nodes matching up to an observing adversary (as defined in \cref{sec:adversary}). It must not be used in environments where a censoring adversary is suspected.

When using F5, jpeg images are required. Imagery requires to be at least eight times the size of the message embedded. Unlike other approaches harvesting random pics or obtaining them from a local repository, we recommend using machine-generated images such as rendered content. We recognize that custom Gravatars, router, and usage graphs of services or render services are suitable imagery material for our purpose. The message content would obviously be machine-generated content and not be suspect. This would effectively render the Dead Parrot problem as described in~\cite{oakland2013-parrot} ineffective. 

\subsubsection{Routing Layer}\label{sec:routingLayer}\index{message!routing}
A routing layer needs to receive all payload and routing blocks and process them (for an exact outline of the routing block, see \cref{sec:vortexMessage}). These blocks are stored in a suitable list within the \defref{workspace} of the \defref{eID} identified by the header block.

We refer to the message processing as ``routing'' as it is more than just forwarding. While processing a message we may split, or reassemble a message and process complex operations on parts of it such as adding a redundancy operation or operations such as ``onion routing'' or ``garlic routing''.

Within the routing block, we find a set of instructions in addition to the next \VortexNodes{}' information and the encrypted routing blocks for the messages to be assembled.
 A simplified representation of a routing block is shown in \cref{fig:mathRoutingSimplified}.

\begin{figure}[!ht]
	\begin{align}
		\mathbf{ROUTING_o}           = & \langle [ \mathbf{ROUTINGCOMBO} ] *, \mathbf{replyBlock},mapping* \rangle\\  
		\mathbf{ROUTINGCOMBO}        = & \langle processIntervall, K_{peerN+1}, recipient, \mathbf{nextMP}, \mathbf{nextHP}, \nonumber \\
		& \mathbf{nextHEADER}, \mathbf{nextROUTING}, \mathbf{assemblyInstructions} \rangle\\
		\mathbf{PL}                  = & \langle \text{payload octets} \rangle *\\ 
		\mathbf{nextMP}              = & E^{K^1_{host_{o+1}}} \left( K_{peer_{o+1}} \right)\\
		\mathbf{nextHP}              = & E^{K^1_{host_{o+1}}} \left( K_{sender_{o+1}} \right)\\
		\mathbf{nextHEADER}          = & E^{K_{sender_o}} \left( \mathbf{HEADER_{o+1}} \right)\\
		\mathbf{nextROUTING}         = & E^{K_{sender_o}} \left( \mathbf{ROUTING_{o+1}} \right)\\    
		\mathbf{operations}          = & \langle \text{list of operations} \rangle \\
		\mathbf{assembyInstructions} = & \langle  blendingInformation, nextHop, \langle \text{mapping operation} +\rangle \rangle
	\end{align}
	\caption{Simplified representation of a routing block.}
	\label{fig:mathRoutingSimplified}
\end{figure}

The routing of a message is simple. A \defref{workspace} of an \defref{eID} contains routing blocks and payload blocks\index{payload block}. A routing block has an active time window defined in the header block. Anytime during that time window, a routing layer of a node processes the routing instructions contained in the assembly operations of the routing block. If successful, the message will be sent using the specified blending layer and target address.

The routing layer stores the main information assigned to the operation of routing messages. The following data has to be kept for routing within the \defref{eID}s \defref{workspace}:
\begin{itemize}
	\item $\mathbf{Build[]}\langle expiry, buildOperation \rangle$\\
	The array $\mathbf{Build[]}$ is a list of building instructions for a message. The server may decide at any time to reject a list exceeding the required size or long-living message. Thus, the server may control the size of this list as well. However, controlling the size of this list will most likely result in the non-delivery of a message. 
	
	The $buildOperation$ is extracted by enumerating $operation*$ while $expiry$ is the upper bound of the $processIntervall$.
	\item $\mathbf{Payload[]}\langle expiry, payload, id \rangle$\\
	The array $Payload[]$ reflects a list of all currently active payloads. Servers may decide to store derivatives of payloads. However, as derived payloads inherit their expiration from the generating operation, such behavior may be safely omitted and operations executed if their result is required.
	
	\item $\splitatcommas{\mathbf{Route[]}\langle processIntervall, blendingInformation, nextHop, \mathbf{nextMP}, \mathbf {nextHP}, \mathbf{nextHeader}, \mathbf{nextRouting}, K_{peer_{o+1}}, \mathbf{assemblyInstructions} \rangle}$\\
	The list of routing information triggers processing. At a randomly chosen time defined in the $processIntervall$, a message is composed. The message is assembled by $\splitatcommas{\langle \mathbf{nextMP}, E_{K_{peer_{o+1}}}\langle \mathbf{nextHP}, \mathbf{nextHEADER}, \mathbf{nextROUTING}, payload* \rangle \rangle}$. The payloads are created with the help of the arrays $build[]$ and $payload[]$, and as soon as the message is authorized by accounting and passed to the blending layer, the entry in this list is discarded.
\end{itemize}

The routing system created by this layer may be seen as a source routing system if one is willing to ignore that the sender of a message and the builder of the routing information are not equal.

\subsubsection{Accounting Layer}\label{sec:accountingLayer}\index{message!accounting}
The accounting layer tracks all information required and assigned to ephemeral identities (\defref{eID}). It is queried by the blending and the routing layer for the authorization of the operations. The accounting layer manages the following tuples of information:

% List duplicated in Accounting layer in implementation and protocol
\begin{itemize}
	\item $\mathbf{eID[]}\langle expiry, pubKey, mesgsLeft, bytesLeft \rangle$\\
	The $\mathbf{eID}$ tuple is the longest living tuple. It reflects an ephemeral identity and exists as long as the current identity is valid. All other tuples are short-lived lists. As the server decides whether to accept new identities or not, the size of this data is controllable. 
	\item $\mathbf{Puzz[]}\langle expiry, request, puzzle \rangle$\\
	The array $\mathbf{Puzz[]}$ is a list of unsolved puzzles of this \defref{eID}. Every puzzle has a relatively short lifespan (typically below 1d). A routing node controls the size of this list by only accepting requests to a certain extent. Typically, this list should not surpass two entries as we should have either a maximum of two open quota requests or one identity creation request.
	\item $\mathbf{Replay[]}\langle expiry, serial, numberOfRemainingUsages \rangle$\\
	The array $\mathbf{Replay[]}$ is a list of serials. List entries are created upon their first usage and remain active until the routing block is expired. 
\end{itemize}


\subsection{VortexMessages}\label{sec:vortexMessage}\index{message}
A \VortexMessage{} is built by combining multiple loosely interconnected blocks. We first name the blocks and their function, and then we explain the inner workings of the blocks and provide reasoning why the block has been built as it is. 

Figure~\ref{fig:messageOutline} shows an outline of the block structure of a message destined to $host_o$. For a mathematical representation, see \cref{fig:mathMessage}.

\begin{figure}[ht]
	\centering\resizebox{.95\linewidth}{!}{
		\input{inc/vortexMessage.inc.tex}
	}
	\caption{Simplified message outline visually and in math.}
	\label{fig:messageOutline}
	% MIssing revision
\end{figure}

The first block is the message prefix block $\mathbf{MPREFIX_o}$, which has been encrypted with the public key of the receiving node $K^1_{host_o}$. This block contains the key for decrypting the rest of the message. Each PREFIX block contains a symmetrical key and the specification on how to encrypt or decrypt with it (mode, padding, IV, and other possibly required parameters) in ASN.1 encoding. 

Immediately following the message prefix block, we have the inner message block. This message blocks contains three additional blocks and a variable number of payload blocks. The inner message is encrypted with the symmetrical peer key $K_{peer_o}$. This peer key is specific to this message and is nowhere reused. It is only known by the two peer hosts $host_o$ and $host_{o-1}$, and the routing block builder (\defref{RBB}). More importantly, $host_{o-1}$ does not need to know the host key of $host_o$ ($K^{host_o}$). Therefore, relaying a message to $host_o$ does not enable $host_{o-1}$ communication with $host_o$. 

The blocks $HEADER_o$ and $ROUTING_o$ are protected with an additional key $K_{sender_o}$. The decryption key is obtained by $host_o$ from the header prefix block $\mathbf{HPREFIX}$. After only decrypting the header block $\mathbf{HEADER}$ and verifying its signature, the accounting layer may check if further processing is authorized. The splitting of the two keys allows us to\ldots
\begin{itemize}
	\item \ldots send a message to $host_o$ without $host_{o-1}$ knowing the host key of $host_o$.
	\item \ldots hide the structure of the message itself.
	\item \ldots keep the content of $\mathbf{HEADER_o}$, and $\mathbf{ROUTING_o}$ secret from $host_{o-1}$.
\end{itemize}

After authorization by the accounting layer, the header block is processed as outlined in \cref{sec:processingIncommingMessages}. Basically, we just added the routing blocks and payload\index{payload block} to the respective \defref{workspace} and waited for the routing layer to process the information.

Looking at a full \VortexMessage, we get the protocol outline, as shown in \eqref{eq:vortexMessage} on page~\pageref{eq:vortexMessage}.

\begin{figure*}[!ht]
	\begin{align}
		\mathbf{VORTEXMESSAGE}       = &\langle \mathbf{MP}^{K^{-1}_{host_o}}, INNERMESSAGE \rangle \label{eq:vortexMessage} \\ 
		\mathbf{INNERMESSAGE}        = &\langle \mathbf{CP}^{K^{-1}_{host_o}}, \mathbf{H}^{K_{sender_o}}, E^{K^{-1}_{sender_o}}\left(H\left(\mathbf{HEADER}\right)\right), \left[\mathbf{R}^{K_{senderN}}\right], \left[\mathbf{PL}\right]*\rangle^{K_{peerN}} \label{eq:innerMessage}\\
		\mathbf{MP}^{K^{-1}_{hostN}} = &E^{K^{-1}_{hostN}}\left(\mathbf{PREFIX}\langle K_{peerN}\rangle \right)\\ 
		\mathbf{HP}^{K^{-1}_{hostN}} = &E^{K^{-1}_{hostN}}\left(\mathbf{HPREFIX}\langle K_{senderN}\rangle \right)\\ 
		\mathbf{H}^{K_{senderN}}     = &E^{K_{senderN}}\left(\mathbf{HEADER}\right)\\  
		\mathbf{HEADER}              = &\langle K^{1}_{senderN}, serial, maxReplays, validity, [requests, requestRoutingBlock],\nonumber\\ 
		& [puzzleIdentifier, proofOfWork] \rangle \\  
		\mathbf{R}^{K_{senderN}}     = & E^{K_{senderN}}\left(\mathbf{ROUTING}\right)\\ 
		\mathbf{ROUTING}             = & \langle [ \mathbf{ROUTINGCOMBO} ] *, forwardSecret, \mathbf{replyBlock},\mathbf{operations} \rangle\\  
		\mathbf{ROUTINGCOMBO}        = & \langle processIntervall, K_{peerN+1}, recipient, \mathbf{nextMP}, \mathbf{nextHP}, \nonumber \\
		& \mathbf{nextHEADER}, \mathbf{nextROUTING}, \mathbf{assemblyInstructions} \rangle\\
		\mathbf{nextMP}              = & E^{K^1_{host_{o+1}}} \left( K_{peer_{o+1}} \right)\\
		\mathbf{nextHP}              = & E^{K^1_{host_{o+1}}} \left( K_{sender_{o+1}} \right)\\
		\mathbf{nextHEADER}          = & E^{K_{sender_o}} \left( \mathbf{HEADER_{o+1}} \right)\\
		\mathbf{nextROUTING}         = & E^{K_{sender_o}} \left( \mathbf{ROUTING_{o+1}} \right)\\    
		\mathbf{operations}          = & \langle \text{list of operations} \rangle \\
		\mathbf{assembyInstructions} = & \langle  blendingInformation, nextHop, \langle \text{list of mapping operations}\rangle\rangle\\
		\mathbf{PL}                  = &\langle \text{payload octets} \rangle *\\ 
	\end{align}
	%\captionsetup{labelformat=empty}
	\caption{Detailed representation of a \VortexMessage.}
	\label{fig:mathMessage}
\end{figure*}

The routing log block is an onionized block. It contains at least a $forwardSecret$, which must match up with the header blocks $forwardSecret$. This mechanism is required to guarantee that routing blocks are not exchanged within an \defref{eID}. The $replyBlock$ provides a possibility to contact the original sender of the message without knowing him. It is only a routing block with instructions on how to prepare the message to be sent. The routing combos contain all the necessary information and prebuilt blocks to create the subsequent messages.

At the very end, we have the payload blocks. These blocks are simply added to the \defref{eID}s \defref{workspace} according to the operations included in the message.

The routing and header blocks are doubly encrypted. We could argue that the inner message block should not be encrypted with a peer key. This looks like a flaw at first glance but is, in fact, a very important feature. Without this key, any independent observer with knowledge about the blending capabilities of a receiving node may\ldots
\begin{itemize}
	\item More easily identify the block structure.\\ 
	This statement remains regardless of whether ASN.1 or length prefixed structures are used. If the structure of a \VortexMessage{} is easily identified, the messages may be logged or dropped.
	\item Identify the routing block size.\\
	The value of this information is minimal as it only reflects the complexity of the remaining routing information indirectly.
	\item Identify the number of payload blocks and their respective sizes. \\
	Sizing information is valuable when following the path of a message.
\end{itemize}

\subsubsection{Message Structure Related to Censorship Circumvention}
It is important to note that there is no structure dividing the encrypted peer key from the inner message block. The size of the peer key block is defined by the key and algorithm of the host key. 

From an outside perspecive, the whole \VortexMessage{} resembles a structureless data blob with a maximum of entropy caused by the encryption employed. 

This is intentional and by design. Plain embedding also uses a method of splitting, which allows a message block to be embedded in chunks in the carrier information. By design, neither the message nor their embedding display detectable attributes allowing them to identify the message. 

Exactly as with the routing operations, much care has been applied. Any random sequence of bytes may be interpreted as valid chunking. For more exact implementation details on chunking, see \cref{sec:chunkingPlain}.

\subsubsection{Message Structure Related to Information Leaking}
From the inside, the $\mathbf{INNERMESSAGE}$ (see \cref{eq:innerMessage}) is built as a structure leaking the absolute minimum of information. A node receiving and decoding the message will learn the following information:
\begin{itemize}
	\item The IP of the sender of the transport layer.
	\item The address and embedding schemes of all receiving transport layers.
	\item The size of the payload blocks.
	\item The size of the subsequent routing blocks.
	\item The peer key $K_{peer_o}$.
	\item The size of the prefix blocks.
\end{itemize}

It is unable to extract the following information:
\begin{itemize}
	\item The required keys for communicating with the suspected peer node.
	\item Any information related to message size, content, or recipient.
\end{itemize}

\subsection{Routing Operations}\label{sec:operations}\index{message!routing}
The routing operations build the core as they define the capabilities of the mixing. We decided to introduce three different classes of operations. Wherever we employ crypto operations, we may choose the operation required for the operation. No choices exist for the core Reed--Solomon-function, the related padding and spitting operation, and the split and merge operations.

\subsubsection{The \texorpdfstring{$addRedundancy$}{addRedundancy} and \texorpdfstring{$removeRedundancy$}{removeRedundancy} Operations}\label{sec:redundancyOperation}\index{operation!redundancy}
In this section, we focus on the core operation of our system. The $addRedundancy$ and $removeRedundancy$ allow growing message sizes in our system without allowing it to identify the decoy traffic. 
The Lagrange functions have been proposed in~\cite{shamir1979share} and were more generalized in~\cite{mceliece1981sharing} for sharing secrets. The general idea about all proposed schemes is to distribute pieces of information and restrict access to it so that only if a specified number of shares are captured a secret may be rebuilt. Unlike in these papers proposed, we do not apply privacy to our protocol by sharing the data among many points. Instead, we use Lagrange functions to create decoy traffic. By doing so, even a creator of traffic is unable to distinguish message traffic from decoy traffic. 

These operations build the core routing capabilities of a node. The operation allows an \defref{RBB} to add redundancy to a message or parts of it (payload chunk) information to a message or to rebuild a block from a chosen set of information.  

The operation itself is shown in \cref{fig:addRedundancyOperation}. 

\begin{figure}[ht]\centering
	\resizebox{0.49\textwidth}{!}{\input{inc/addRedundancyOp.inc.tex}}
	\resizebox{0.49\textwidth}{!}{\input{inc/removeRedundancyOp.inc.tex}}
	\caption{Outline of the addRedundancy and removeRedundancy operation.}
	\label{fig:addRedundancyOperation}
\end{figure}

It may be subdivided into the following operations:
\begin{itemize}
	\item Padding the original message block in such a way that all resulting blocks are a multiple of the block size ($C_1,\ldots, C_n$) of the encrypting cipher.
	\item Applying a Reed--Solomon-operation in a given $GF(2^\omega)$ space with a Vandermonde matrix.
	\item Encrypt all resulting blocks with unpadded, symmetrical encryption.
\end{itemize}

The padding applied in the first step is non-standard padding. The reason for this lies in the properties required by the operation. The presence of standard padding may leak whether the block has been successfully decrypted or not. Therefore, we created a padding with the following properties:
\begin{itemize}
	\item The padding must not leak whether the rebuild cycle of the operation was successful or not.
	\item Anyone knowing the routing block content and the transmitted message must be able to predict any treated block, including all padding bytes.
	\item The padded content must provide resulting blocks of required size to enable non-padded encryption after the RS operation.
	\item The padding must work with any size of padding space.
	\item The padded and encrypted block must not leak an estimate of the original content.
\end{itemize}

The padded block $\mathbf{X}$ is created from a padding value $p$, the unpadded block $\mathbf{M}$ and a series of padding bytes. We build $\mathbf{X}$ for a function $RS_{\text{m of n}}$ (allows adding $m$ redundancy blocks) and an encryption block $\mathbf{M}$ sized $K$ as follows:
\begin{eqnarray}
	i          & = & len(\mathbf{M}) \label{eqn:sizeOrigMsg}\\
	e          & = & lcm\left(blocksize\left(E^{K}\right), n\right) \label{eqn:sizeOfOpBlock}\\
	l          & = & \left\lceil\frac{i + 4 + C2 }{e}\right\rceil\cdot e \label{eqn:sizeOfPaddedBlock}\\
	p          & = & i + \left( C1 \cdot l \pmod{\left\lfloor\frac{2^{32}-1-i}{l}\right\rfloor\cdot l}\right)\\
	\mathbf{X} & = & \langle p,\mathbf{M},R_{t}\left(s,l-i\right)\rangle\\\nonumber
	& = & \langle p,\mathbf{M},R_{t}\left(s,l-\left(p \pmod{len\left(\mathbf{X}\right)-4}\right)\right)\rangle
\end{eqnarray}    
Variable $i$ denotes the length. By calculating $e$ as the least common multiplyer of the encryption block size and the number of output blocks, we determine the block size required for our operation so that no subsequent padding is required.

The remainder of the input block, up to length $l$, is padded with random data. The random padding data may be specified by RBB through a PRNG spec $R_t$ and an initial seed value $s$. The message is padded up to size $L$. None of the resulting encrypted blocks require any padding, because the initial padding guarantees that all resulting blocks are dividable by the block size of the encrypting function. If not provided by an RBB, an additional parameter $C1$ is chosen as a random positive integer and $C2=0$  by the node executing the operation.

To reverse a successful message recovery information of a padded block $\mathbf{X}$, we calculate the original message size by extracting $p$ and carrying out $i=len(\mathbf{M})=p \pmod{ len\left(\mathbf{X}\right)-len\left(p\right) }$.

This padding has many advantages:
\begin{enumerate}
	\item The padding does not leak if the rebuilding of the original message was successful. Any value in the padding may reflect a valid value.
	\item Since we have a value $C2$, the statement that a message size is within $len(\mathbf{X})>=size>(len(\mathbf{X})-e)$ is no longer true and any value smaller $len(\mathbf{X})-e$ may be correct as well.
	\item An RBB may predict the exact binary image of the padded message when specifying $C1$, $C2$, and $R_{t}(s,)$.
	\item A node knowing the original parameters $C1$, $C2$, and the initial PRNG seed $s$ can detect successful decryption.
\end{enumerate}

Apart from being non-standard padding, the padding has additional disadvantages:
\begin{itemize}
	\item The padding is inefficient compared to simple paddings such as PKCS\#7
	\item The padding requires an initialized PRNG to generate the padding data.
	\item Depending on the chosen parameters, the padding overhead may become significant. 
\end{itemize}

After the padding, the date is ready for the Reed--Solomon-part of the operation. We first group the data vector into a matrix $\mathbf{A}$ with $m$ columns to carry out the operations efficiently. The previous padding guarantees that all columns have a length, which is dividable by the block size of the encryption step applied later.

\begin{eqnarray}
	t          & = & n-1\\%in bytes
	\mathbf{A} & = & vec2mat\left(\mathbf{X},\frac{len\left(\mathbf{X}\right)}{m}\right)\\
	\mathbf{V} & = & \left(\begin{matrix}
		0^0 & 0^1 & 0^2 & \cdots & 0^{(m-1)} \\
		1^0 & 1^1 & 1^2 & \cdots & 1^{(m-1)} \\
		2^0 & 2^1 & 2^2 & \cdots & 2^{(m-1)} \\
		\vdots & \vdots & \vdots & \ddots & \vdots \\
		t^0 & t^1 & t^2 & \cdots & t^{(m-1)}
	\end{matrix}\right)\\
	\mathbf{P} & = & \mathbf{V}\mathbf{A} \left(GF\left(2^\omega\right)\right)\\
	\langle \mathbf{Q_1}, \ldots , \mathbf{Q_n} \rangle & = & row2vec(P)\\
	R_i & = & E^{K_i}\left(Q_i\right)
\end{eqnarray}    

We apply the Reed--Solomon-function by employing a Vandermonde matrix ($\mathbf{V}$). We build the data matrix ($\mathbf{A}$) by distributing the data into $\frac{len\left(\mathbf{X}\right)}{m}$ columns. This results in a matrix with $m$ rows. Unlike in error-correcting systems, we do not normalize the matrix so that the result of the first blocks is equivalent to the original message. Instead, the error-correcting information is distributed over all resulting blocks ($\mathbf{Q_i}$). Since the entropy of the resulting blocks is lowered as shown in \cref{fig:entropy} and may thus leak an estimate of how a resulting block may have been treated, we added the encryption step to equalize entropy again. The previously introduced padding guarantees that there is no further padding required on the block-level. The key used to encrypt the single blocks must not be equivalent. Equivalent keys have the side effect of encrypting equal blocks into the same ciphertext. We observed faint but statistically relevant reminders of the unencrypted graphs when treating the same block with the same key and different redundancy parameters. Details about this analysis are available in \cref{sec:analysisReedSolomon}.

\subsubsection{The \texorpdfstring{$encrypt$ and $decrypt$}{encrypt and decrypt} Operations}\index{operation!encryption}
The $encrypt$ and $decrypt$ operations as shown in \cref{fig:encryptOperation} are essential for the requirement that tagging should not be possible. Unlike the $addRedundancy$ and $removeRedundancy$, the splitting operations do not feature any encryption step after splitting or merging. Reusing a payload block that has only been split or merged would repeat the payload pattern on multiple nodes during transfer. That is why we require encryption.

\begin{figure}[ht]\centering
	\resizebox{0.35\textwidth}{!}{\input{inc/encrypt.inc.tex}}
	\resizebox{0.35\textwidth}{!}{\input{inc/decrypt.inc.tex}}
	\caption{Outline of the encrypt and decrypt operation.}
	\label{fig:encryptOperation}
\end{figure}

The reason for not building this step into the split and merge function was simple. We needed a separate encryption step to be able to work as an onionizing system, and there were use cases where integrated encryption did not make sense. For further details on this topic, see \cref{sec:routingStrategies}.


\subsubsection{The \texorpdfstring{$mergePayload$ and $splitPayload$}{mergePayload and splitPayload} operation}\label{sec:mergeAndSplit}\index{operation!split}
The $splitPayload$ operation shown in \cref{fig:mergeOperation} splits a payload block into two chunks of different or equal sizes. The parameters for this operation are:

\begin{itemize}
	\item source payload block $pb_1$
	\item fraction $f$\\
	A floating-point number describing the size of the first chunk. If the fraction is ``1.0'', then the whole payload is transferred to the second target chunk.
\end{itemize}

\begin{figure}[ht]\centering
	\resizebox{0.43\textwidth}{!}{\input{inc/split.inc.tex}}
	\resizebox{0.35\textwidth}{!}{\input{inc/merge.inc.tex}}
	\caption{Outline of the splitPayload and mergePayload operation.}
	\label{fig:mergeOperation}
\end{figure}
If $len(pb_1)$ expresses the size of a payload block called $pb_1$ in bytes, then the two resulting blocks of the splitPayload operation $pb_2$ and $pb_3$ have to adhere the following rules:

\begin{eqnarray}
	split(f, pb_1) & = &\langle pb_1, pb_2 \rangle\\
	pb_1.startsWith(pb_2)\\
	pb_1.endsWith(pb_3)\\
	len(pb_2) & = & floor(len(pb_1)\cdot f)\\
	len(pb_1) & = & len(pb_2) + len(pb_3)
\end{eqnarray}

The $mergePayload$ operation combines two payload blocks into one. The parameters for this operation are:

\begin{itemize}
	\item first source payload block $pb_1$
	\item second source payload block $pb_2$
\end{itemize}

If $len(pb)$ expresses the size of a payloadblock called $pb$ in bytes then resulting block of the mergePayload Operation $pb_3$ has to adhere the following rules:

\begin{eqnarray}
	merge(pb_1, pb_2) & = & pb_3 \\
	pb_3.startsWith(pb_1)\\
	pb_3.endsWith(pb_2)\\
	len(pb_3) & = & len(pb_1) + len(pb_2)
\end{eqnarray}

Unlike other operations, this operation has no encryption step attached to it. We usually attached an encryption step to remove repeating patterns from the \VortexMessage{} stream.

It has to be mentioned that this operation tuple has some issues when it comes to floating-point implementations. They are solvable but had to be specified unexpectedly precisely in order to enable a true cross-platform implementation. For more information regarding the issue and exact implementation, see \cref{sec:implOperations}.


\section{Summary}
The \MessageVortex{}-Protocol is split into the four layers: ``Transport'' (a common Internet standard protocol), ``Blending'' (extracting and embedding \VortexMessages), ``Routing'' (reassembling messages according to received instructions), and ``Accounting'' (tracks all stored data and discards expired information).

All nodes are realized in decentralized devices such as computers or mobile phones. Messages are hidden with either plain embedding or F5 in the transport layer message. The routing layer processes messages by applying operations to them. Valid operations are: encrypt or decrypt a message chunk, split a message chunk into two parts, merge two parts into one, or add or remove redundancy information. The last operation is the most valuable. This operation allows by employing an extended Reed--Solomon-operation to add decoy traffic to the message flow without enabling a node to identify such traffic. Furthermore, it allows a sender to send parts of a message through multiple chains of routing nodes to a recipient. Each message itself does not leak the message content since, depending on the completing block, any message with the appropriate length may be valid.

The routing itself is achieved in a temporarily allocated storage called ``\defref{workspace}'', which is tied to an ephemeral identity (\defref{eID}) represented by an asymmetric key pair. To obtain an \defref{eID}, a sender typically solves a crypto puzzle. 

Payloads of \VortexMessages{} are mapped into the \defref{workspace}{} and are assigned a unique \defref{ID}{} within that workspace. The subsequent \defref{routing block}s and their \defref{operation}s are added as well and processed in a time interval defined by the \defref{RBB}.

