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

\partepigraph{Limit your inputs to only those that support a certain kind of self-destructive behavior, and you can be cheered with enthusiasm as you drive yourself off a cliff.}{Adam-Troy Castro}
\part{Discussion and Conclusion}

In this chapter, we outline the main results of our work. We emphasize the weaknesses and concentrate on the technologies able to complement our new protocol.

\chapter{The Achieved Properties of the Protocol}
\section{Measuring up to the Requirements\label{sec:reqDiscussion}}
This section analyzes the level of achievement concerning the requirements defined in \cref{sec:requirements}. We will elaborate on ach requirement and discuss the level of achievement. In case of failure, we highlight reasons for the failure and elaborate on the consequences of the current flaws. An overview of all requirements can be found on \cref{tab:requiremnts} on page~\pageref{tab:requiremnts}.

In our opinion, our system meets the requirement \ref{req:undetectable} as long as the blending layer obeys the criterion opposed to it. Assuming that the dummy content is not distinguishable from other traffic by a censoring adversary and F5 is not broken, then a \VortexNode{} should be truly undetectable from the outside.

The requirement \ref{req:P2P} is met as there is no difference in the nodes. All nodes serve as possible endpoints, and all nodes carry out routing. There is no technical difference between the nodes, which may allow differentiation between endpoints and anonymity routers.

The requirement \ref{req:zeroTrust} is met in a wider sense. We do not require any trust in any routing nodes. However, we need either message traffic to trusted nodes from a non-cooperating adversary or an honest \VortexNodes{} with additional traffic within our anonymity set. 

The requirement \ref{req:unlink} is under full control of an RBB. The RBB controls the number of hops and the nodes involved. He may therefore achieve unlinkability by combining the operations accordingly.

The requirement \ref{req:anon} is met if not assuming an adversary within the system. It furthermore can be accomplished in various grades ($k$-Anonymity) by the RBB if an adversary is within the system running nodes by the RBB. In such a case, all independent message paths of a \VortexMessage{} must contain at least one honest \VortexNode{} with additional traffic. As soon as this condition is true, an adversary can no longer conclude any potential anonymity set. Even the sender and recipients alone may be sufficient, assuming additional traffic is being routed through these nodes.

The requirement \ref{req:accounting} is fulfilled as all elements required for accounting have an expiration date. Requests beyond that date are discarded. The information to be kept is limited to an absolute minimum and may accommodate multiple 100K identities per \VortexNode.

The requirement \ref{req:untagable} is fulfilled as no pattern may be followed through the network. All information visible to an outside or inside observer is discarded at the following node.

The requirement \ref{req:unbugable} is only partially met. As we did not specify the type of payload that may be transported but suggested MIME-encoded messages, bugging is possible. However, message bugging in MIME-encoded messages is well known. Most of the clients offer appropriate countermeasures such as suppression of external imagery loading and similar. When sticking to the recommendation to send text-only messages, bugging is not possible.

The requirement \ref{req:unreplayable} is only partially fulfilled. As we allowed the use of MURBS, replaying a message is possible. As it is an optional feature and normal messages have replay protection, this flaw's impact is minimal and intended.

The requirement \ref{req:boot} remains one of the major flaws of our protocol. This flaw has systemic reasons. The possibility of discovering \VortexNodes{} in an environment of a censoring adversary, no matter how built, is enabling the adversary to harvest a network of nodes. It subsequently means that any possibility of narrowing down potential nodes may be hazardous in such an environment. We believe that, unless we have broadly accepted protocols using broadcast into huge domains, a protocol may not solve the problem of identifiable peer nodes. We, furthermore, believe that such protocol support is unlikely to arise due to bandwidth reasons. 

The requirement \ref{req:algVar} is met as we have built in the possibility to vary any algorithm. Wherever possible, we named and included independent alternatives based on different mathematical problems into the standard. It is furthermore possible to signal non-standard algorithms. As long as two nodes support the same standard, they are capable of communicating.

In our eyes, the requirement \ref{req:easy} turned out to be the least successful of all. While we may automate the \MessageVortex{} protocol and all its needs in an observing adversary environment, the use in an environment of a censoring adversary is not possible for a non-savvy individual or a small organization. This is because the dummy traffic generated to carry \VortexMessages{} has to be individualized and credible. Coding skills are required to meet this requirement, which opposes to \ref{req:easy}. While not unsolvable, we consider this problem as difficult to solve.

The requirement \ref{req:reliable} can be met in various degrees. The degree of reliability depends on the number of stable working nodes in an anonymity set and the strategy chosen by an RBB to build the routing block. We consider this requirement as met. 

The requirement \ref{req:transparent} is met in our opinion as we offer the possibility to explicitly or implicitly diagnose the entire message traffic at any time. 

The requirement \ref{req:available} is met as our system remains functional via alternate message paths if a \VortexNode{} is no longer functional. However, as we cannot adapt a messages' route, the system's availability is controlled by the RBB.

We consider the requirement \ref{req:senderId} as met as the protocol offers the possibility to match two messages to the same sender (even if not knowing its identity) by matching the \defref{eID}. To keep this possibility for a recipient, both sender and receiver have to collaborate as the sender needs to use the same \defref{eID} for all messages, and the recipient must allow usage of such \defref{eID} for the entire period.

Overall, we consider this work in its current state as a partial failure due to the lack of the requirement \ref{req:easy}. This miss causes the protocol to be only of limited use to a single individual operating in a censoring adversary environment.

\section{Achieved Level of Anonymity and Detectability}
We have to emphasize when discussing anonymity that our system is unlike most other systems. As we have an adversary defined that other systems do not withstand, we have to compare anonymity on multiple levels. Within these levels, anonymity and detectability complement each other as breaking detectability might lead to a node or a respective user's de-anonymization. 

These layers relevant to anonymity or detectability are:
\begin{itemize}
	\item The detectability of the system by\ldots
	\begin{itemize}
		\item detecting or identifying transport layer accounts.
		\item detecting or identifying \VortexNodes{}.
	\end{itemize}
	\item The detectability and tracing of single \VortexMessages.
	\item The traceability of a message over multiple \VortexNodes{}.
	\item The identification of \MessageVortex{} users by$\ldots$
	\begin{itemize}
		\item the sending \MessageVortex{} user
		\item the receiving \MessageVortex{} user
		\item an adversary within the anonymity set
		\item an outside adversary
	\end{itemize}
\end{itemize} 

The detectability of a system depends on multiple factors. If the blending is detectable, a \VortexNode{} is identifiable and may uncover the respective user. In environments with a censoring adversary, such identification may be deemed as dangerous. In such environments, our system heavily depends on the individual implementation of the blending. In its current state, coding skills are likely needed to remain undetectable as not following a pattern is their key, and our standard implementation may be deemed a pattern. The traffic generated for accessing a transport layer account is not especially susceptible to detectability as the always-connected pattern is very common among devices and services these days. Special care has to be taken if protocols offer housekeeping features for the transported messages. In these cases, access patterns should match the chosen service pattern (e.g., delete INBOX emails after 30 days). A node may be identifiable by the transport layer owner as an atypically behaving user by not doing so.

Single \VortexMessages{} may be detectable from the outside, as covered in the previous paragraph. Apart from that, sending and receiving \VortexNodes{} are always aware of the transport layer address's identity. This means that anonymity is no longer possible if a censoring adversary is part of an anonymity set. In such a case, the adversary would be capable of uncovering involved \VortexNodes{} by harvesting node transport addresses over time. A solution for this problem does not exist as long as we do not assume a widely deployed protocol employing broadcasting (or at least multicasting) with huge domains.

Messages are not traceable as long as we have at least one honest or non-collaborating (to the current adversary) \VortexNode{} in a message path due to the message properties. As soon as two adjacent \VortexNodes{} collaborate, they may collapse all operations of the two into one workspace.

Identification of \MessageVortex{} users may be achieved in multiple ways. If an RBB composes unsuitable routing blocks, anonymity is broken. We outlined before that \MessageVortex{} may build the same messaging patterns as Mix-, onion-, BC- or DC-networks but with additional security-related features such as redundancy or the split of messages. In general, this makes our protocol at least equivalent or even superior to the technologies mentioned earlier. Unlike those systems, our system is not limited to specific message patterns, making our system more suitable in an environment of a censoring adversary. A unique fingerprint of composing messages may identify the sending user. He furthermore may be identified by bugging a message sent with a reply block. For an outside observer, a sending user may be determined if there is no additional traffic running over its routing node. Therefore, receiving traffic (to be routed or not is irrelevant) adds to a message's anonymity. The receiving user may be identified by a bugged message. From the outside, a receiving user may or may not further deliver messages. The same applies to any routing node. This does not give any indication of a received message.

\chapter{Weaknesses of the Protocol}
The protocol has several weaknesses which we were unable to compensate accordingly. The complexity of the algorithms for an RBB is definitely high compared to other protocols. Nevertheless, it is possible for a single RBB to create and maintain a network of ready \defref{eID}s for routing. Given a sufficient set of nodes, this routing works comparable to other protocols. It scales very well under high loads as all nodes act independently, and no non-parallelizable asks are within the whole system. However, once adequately bootstrapped, it is easy to use as a user may use it with typical clients such as email clients and offers an unmatched degree of anonymity in our belief.

\chapter{Missing Research}
\section{Lack of Base Data}

One problem we encountered is the lack of available statistical data regarding true Internet environments. There is much data available that may be easily extracted (such as SNMP MIBs). However, when it comes to true insights into the Internet, we have only very limited data. There is some data available about censorship in China and in Turkey in our specific case. It would have been tremendously welcomed if we had comparisons in the communication patterns of persons. Questions about ``What protocols are used to transfer messages either in human-to-human or machine-to-human communication'', ``Which types of attachments are common among specific protocols'', or ``What are common threats today'' seem not to be researched. There are some pseudo-scientific papers available, shedding light on some questions. However, these papers do not follow scientific standards and are often misunderstood to boost certain products. An excellent example of this trend are papers describing the dangers solely from the perspective of anti-malware or firewalls, which typically fail to list threats related to social engineering. Available data is often collected cheaply by querying SNMP MIBs, using statistics collected by a product cloud, or by filtering traffic of static sources list to identify streaming traffic. Continuously monitored and generally available data about routed traffic within the Internet would have offered tremendous help for our work.

\section{Lack of Implementations}
One of the actual weaknesses of the protocol lies in the lack of implementations available for anonymity. Available implementations of steganographic algorithms in C/C++ or Java are rare. Moreover, we were unable to find any partial essay of implementation for creating dummy traffic. Therefore, one weakness may be found in the lack of adaptation of protocols and algorithms from the scientific world. Most of the anonymity systems exist only as partial implementation or as simulators. Especially an alternative available to the implementation of F5 would be sensible and helpful. While such an implementation may be retrofitted in the system, the lack in the current state is regarded as a weakness. The same may apply to algorithms such as NTRUencrypt. While this algorithm was implemented and specified in terms of encryption and decryption, a binary layout for the key was never specified. Such layouts are, however, crucial for a world of inter-operation. The lack of such specifications and implementations makes our implementation of \MessageVortex{} weaker in portability. We are, of course, capable of creating our implementation and specify our binary layouts. However, such implementations lack a proper peer review and violate interoperability basics, which are a major concern in all protocols. 

The lack of other, comparable protocols makes the \MessageVortex{} protocol weaker. Having no real competitor in a class makes it very difficult to measure and compare a solution. Assuming a censoring adversary is a hard-to-fulfill territory, most people instead seem to focus on a single problem without true implementation than on a solution for a real-world problem. Claiming that anonymity is solvable is acceptable in the authors' eyes as long as we can describe realistic real-world or clean slate approaches, and these approaches must be implementable. The authors encountered multiple solutions, which were good ideas but lacked a realistic view. Achieving in an environment where there is no inside observer or just regional observers is straightforward but not realistic. 

\section{Further and Missing Research}
The current blending layer is by far too simple in its inner workings. It creates contextless messages based on an easily recognizable scheme and is not suitable to mimic human communication. A good blending layer would be capable of mimicking not only machine-like traffic but even human-like traffic. Atypical communication patterns such as 24x7 communication may be broken into typical patterns by mimicking three sending accounts with different overlapping communication patterns. The system does not necessarily have to pass a full Turing test. It would be sufficient to create credible human communication between machines sounding human-like. Research in AI already succeeded in generating credible communications between two robots. It is unknown whether such ``small-talking'' implementations would create credible content. As we defined that an adversary has enormous but limited resources, this blending is sufficient if it is carried out ``good enough'' so that an adversary cannot identify the traffic as generated content. What criteria would apply here is a topic for further research. Applying more research to this topic would require adding a more precise adversary model.

The currently applied choice of transport layer protocol is a snapshot of current Internet traffic. While done with great care, it must be adapted to the changing communication habits of humanity. Identifying new or depreciated communication protocols and blending schemes would be another field of research.

A comprehensive survey of the newest trends and techniques in steganography is another topic to be covered. It would allow identifying new candidates for blending techniques. Of special interest are steganography algorithms covering movie and audio file formats. This may be especially interesting when it comes to mimicking other communication patterns such as social network apps using voice messaging.

Anonymity has effects on the behavior of humans. We have found that although there is some research in this field (such as~\cite{postmes2001social}), the evidence is very weak. Although the possibility of anonymity is undisputed among so-called free countries, the disadvantages (e.g., misuse for criminal acts) of anonymity are apparent. More research in this field is required. On the other hand, a lack of anonymity awareness, especially in ``non-free'' jurisdictions, has been observed, which would be another relevant field of research. 

\chapter{Potential and Improvements}
\section{Improvements in Blending}
Our current implementation is very rough and requires coding or individualization when used in a censoring adversary environment. Generating the decoy traffic should be far better feasible by using recent developments in deep learning (DL) and natural language processing (NLP). 

Such implementations would have the potential of generating undetectable decoy traffic. While the current traffic is bound to machine-to-human communication, deep learning implementations would have the possibility of building proper communication between two artificial identities. The implementation would not have to pass a Turing test. Instead, it would be sufficient if an outside observer cannot identify the communication partners as ``non-human'' or ``suspicious''.

\section{Operations Agility}
In our current implementation, operations are statically encoded. While the current set was chosen carefully, it would have been better to, analogous to the requirement of crypto agility, select a set of supported operations. Such selection possibility was forgotten at the start, and adding it to the work's current state turned out to be very challenging. Nevertheless, we believe that such ``Operations Agility'' would add to the system's value.

It would allow extending the system with new types of operations reflecting state-of-the-art anonymity research without disrupting an existing network.

\section{Simplified and Anonymity-Conformant Bootstrapping}
Bootstrapping is currently based on human-to-human communication. While this is possible and, in most cases, feasible, it is impractical and reduces the ease of use of the system. The handshake forces us to exchange transport endpoint addresses and node keys. We could simplify our approach by introducing decentralized stores offering SURBs if a short common secret is known. Analogous to a PIN when using WPS in a WiFi system, such small secrets could be used to do the first handshake simplifying the tedious procedure a bit.

Such an approach will be secure if the rendezvous-point is under the control of an observing adversary, as only the common knowledge of both short secrets allows the identification of the SURB. By trying to brute-force the SURB, an adversary would invalidate the SURB on its first use.

\chapter{Closing Words}
While working on our system, we were amazed at how broad the field of anonymity and the number of means to attack anonymity is. Anonymity is, in our belief, achievable in any environment. Depending on the type of anonymity and environment, it has a relatively high price tag for the user. It will always be more comfortable to remain traceable than to be anonymous. It is up to all researchers in the field of anonymity to reduce this pricetag. In our belief, this is a topic research has to pursue in subsequent works. Our statement here would be: Challenge accepted.

Our tool is neither good nor bad. Precisely as a crowbar is a useful household tool, it may be misused to carry out illegal things or threaten life. On the other hand, recent development in many countries shows that there is always an excuse for legislative power to intimidate people not in favor of their opinions. Therefore, it is our firm belief that despite the inherent disadvantages of all anonymity systems, they are necessary to keep at least the world as free as it already is.