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

% ********************************************************************************************************
% *** Intro to MessageVortex
% ********************************************************************************************************
% ********************************************************************************************************
% *** Research Preexisting work
% ********************************************************************************************************
\partepigraph{Where does a snake's tail start?}{My son Florian}
\DeclareFixedFootnote{\omitted}{footnotes omitted in quote}
\part{Relevant Concepts and Technologies}\label{sec:concepts}
In this part, we shed light on important concepts and technologies related to our work. Chapter~\ref{sec:anontrustResearch} relates to some basic concepts of anonymity, such as a definition and some metrics. We furthermore introduce Zero Trust and several other concepts often used in conjunction with anonymity-related systems. Chapter~\ref{sec:cryptoResearch} covers cryptographic-related research and summarizes some important facts which form the base for our future design. Lastly, \cref{sec:censorshipResearch} collects some research on the topic of censorship circumvention.

We focus on the general concepts and technologies of anonymity and elaborate on their relation to our problem.

\chapter{Anonymity and Trust-Related Research}\label{sec:anontrustResearch}
While there is much research on anonymity and trust, many basics remain insufficiently researched. Definitions for basic terms such as anonymity or censorship are rare. There is no common agreement for such terms. Measuring degrees of censorship or anonymity is even more challenging. We were unable to find metrics for measuring anonymity that cover all or even most aspects or enable the correct automated measurement of anonymity.

\section{Definition of Anonymity}
As the definition of anonymity, we take the definition as specified in~\cite{anonTerminology}.
\begin{shadequote}{}
	Anonymity of a subject means that the subject is not identifiable within a set of subjects, the anonymity set.\omitted
\end{shadequote}
and
\begin{shadequote}{}
	Anonymity of a subject from an attacker's perspective means that the attacker cannot sufficiently identify the subject within a set of subjects, the anonymity set.\omitted
\end{shadequote}

We define the anonymity set as the set of all possible subjects within a supposed message. A subject's anonymity towards an observing third party is crucially related to our adversary model.

Furthermore, we define that ``sender anonymity'' is available if a sender may send a message and the recipient cannot identify the sender in the anonymity set. Similarly, a system provides ``receiver anonymity'' if the sender cannot identify a message's recipient within an anonymity set.

\section{\texorpdfstring{$k$}{k}-Anonymity}
$k$-anonymity is a term introduced in~\cite{k-anonymous:ccs2003}. This work claims that entities are not responsible for an action if an observer cannot match a specific action to fewer than $k$ entities. In contrast, the metric $k$ may be dependent on the subject's location and personal circumstances.

The paper distinguishes between \textit{Sender $k$-anonymity}, where the sending entity can only be narrowed down to a set of $k$ entities and \textit{Receiver $k$-anonymity}. 

The size of $k$ is a crucial factor. One of the criteria is the legal requirements of the respective jurisdiction. Depending on the jurisdiction, it is usually impossible to prosecute someone if an action is not directly coupled to one person. 

The problem is that under normal circumstances, $k$ is either not constant or decreases over time. Therefore, an anonymity protocol must ensure that a sender or receiver set of $k$ entities is either unidentifiable or has a sufficient size so that $k$ is adequately sized even when decreasing over time.

\section{\texorpdfstring{$\ell$}{l}-Diversity}
In~\cite{machanavajjhala2007diversity} an extended model of $k$-anonymity is introduced. In this paper, the authors emphasize that it is possible to break a $k$-anonymity set if additional information is available, which may be merged into a data set so that a distinct entity can be filtered from the $k$-anonymity set. In other words, if an anonymity set is too tightly specified, additional background information might be sufficient to identify a specific entity in an anonymity set.

It might be arguable that a $k$-anonymity in which a member is not implicitly $k$-anonymous remains sufficient for $k$-anonymity in its sense. However, the point made in this work is right and is taken into account. Their approach is to introduce an amount of invisible diversity into $k$-anonymous sets, so that common background knowledge is no longer sufficient to isolate a single member.

\section{\texorpdfstring{$t$}{t}-Closeness}
While $\ell$-diversity protects the identity of an entity, it does not prevent information gain. A subject in a class has the same attributes. This is where $t$-closeness~\cite{li2007t} comes into play. $t$-closeness is defined as follows:

\begin{shadequote}{}
	An equivalence class is said to have $t$-closeness if the distance between the distribution of a sensitive attribute in this class and the distribution of the attribute in the whole table is no more than a threshold. A table is said to have $t$-closeness if all equivalence classes have $t$-closeness.
\end{shadequote}

While in statistics working with cases and exact figures, we may, possibly, identify the distance between attributes of a class for a single set of classes reflecting a defined distribution at a given point in time. Whenever looking at a varying set of characteristics, such a metric seemed an impractical value. Therefore we discarded this value as a metric for our protocol.

\section{Zero Knowledge Proofs}
In~\cite{goldwasser1989knowledge} and later~\cite{de1987non} the authors introduce Zero-Knowledge Proofs (ZKP), which allow proving the knowledge of a secret without revealing any detail about the secret itself. Other authors further broadened this concept by allowing proof that calculations (e.g., shuffles) have been carried out accordingly. ZKPs are powerful companions in today's anonymity systems to detect cheating nodes.

Their disadvantages are typically a high computational and bandwidth consumption for the proof and possibly a complex interaction between the prover and the verifier.

We attempted to secure the computation of our routing operations with ZKPs and failed. The operations carried out, especially calculations with S-Boxes, as within AES, and the concept of crypto-agility was too complex to be secured. Depending on the crypto-agility scheme used, the verifier would require knowledge of the operations carried out, which was not acceptable for our system. We therefore dropped the attempt to secure our operations through ZKPs.

\section{Censorship}
As a definition for censorship, we take
\begin{shadequote}{}
	Censorship: The cyclical suppression, banning, expurgation, or editing by an individual, institution, group, or government that enforces or influences its decision against members of the public --- of any written or pictorial materials which that individual, institution, group, or government deems obscene and ``utterly without redeeming social value,'' as determined by ``contemporary community standards.''
\end{shadequote}

The definition is attributed to Chuck Stone, Professor at the School of Journalism and Mass Communication, University of North Carolina. Please note that ``Self Censorship'' (not expressing something in fear of consequences) is also a form of censorship.

In our more technical view we reduce the definition to
\begin{shadequote}{}
	Censorship: A systematic suppression, modification, or banning of data in a network by either removal or modification of the data, or systematic influencing of entities involved in the processing (e.g., by creating, routing, storing, or reading) of this data.
\end{shadequote}
This simplified definition narrows down the Internet location as it is the only appropriate location for us. Furthermore, it limits the definition to the maximum reach within that system.

\subsection{Censorship Resistance}
A censorship-resistant system is a system that allows the entities of the system and the data itself to be unaffected from censorship. Please note that this does not deny the presence of censorship per se. It still exists outside the system. However, it has some consequences for the system itself.

\begin{itemize}
	\item The system must be either undetectable or out of reach for a censoring entity.\\
	The possibility of identifying a protocol or data allows a censoring entity to suppress the use of the protocol itself. 
	\item The entities involved in a system must be untraceable.\\
	Traceable entities would result in a means of suppressing real-world entities participating in the system.
\end{itemize}

\subsection{Parrot Circumvention}
In~\cite{oakland2013-parrot} \citeauthor{oakland2013-parrot} express that it is easy for a human to determine decoy traffic as the content is easily identifiable as generated content. While this is true, there is however a possibility to generate ``human-like'' data traffic to a certain extent. As an adversary may not assume that his messages are replied to, the problem does not compare to a real Turing test. There remains only a ``passive observer Turing test'', enabling the potential nodes but not the observer to choose the messages. 

In our design, this is covered by the blending layer, which generates the visible part of the message. The blending layer generates messages which contain either obviously machine-generated contextless messages or simple messages following tweet-styled patterns. 

\section{Single Use Reply Blocks and Multi-Use Reply Blocks}\index{MURB}\index{multi-use reply block|see {MURB}}\index{SURB}\index{single-use reply block|see {SURB}}
Chaum first introduced the use of reply blocks in~\cite{CHAUM1}. In general, a routing block is a structure allowing to send a message to someone without knowing the targets' real address. Reply blocks may be differentiated into two classes ``Single Use Reply Blocks'' (SURBs)  and ``Multi-Use Reply Blocks'' (MURBs). SURBs may be used once, while MURBs may be used a limited or unlimited number of times. 

Our research discovered that if a routing protocol is deterministic, an adversary may use the traffic generated by a MURB to identify some of the message's properties. Depending on the type of attack, the block has to be repeated very often. For this reason, we limited the number of replays. The concept is tha in our case we have a routing block, which might be used up to $n$ times ($0<n<127$). It is easily representable in a byte integer (signed or unsigned) on any system. It is large enough to support human communication sensibly and to not add too much overhead when re-requesting more MURBs. The number should not be too large because if a MURB is reused, the same traffic pattern is generated, making the system susceptible to statistical attacks.

\section{Zero Trust}\label{sec:zeroTrust}
Zero trust is not an academically defined concept. It is widely misused by many marketing departments of well-known devices and applications related to security. The first citation of the idea was in~\cite{kindervag2010no} where \citeauthor{kindervag2010no} introduced this concept.

\citeauthor{kindervag2010no} compares the traditional approach as an M\&M (crunchy shell and soft inner part) and introduces the zero trust principle in three concepts:
\begin{shadequote}{}
	\begin{enumerate}
		\item Ensure That All Resources Are Accessed Securely Regardless Of Location
		\item Adopt A Least Privilege Strategy and Strictly Enforce Access Control
		\item Inspect and Log All Traffic
	\end{enumerate}
\end{shadequote}

This concept applies to security and not to anonymity. We therefore had to adopt this concept, without violating anonymity.
\begin{enumerate}
	\item Ensure that all resources are accessed securely regardless of location\\
	We ensure that control over the security-relevant parameters remains at all times within the originator of a message. The violation of transport security should not be possible by malfunctioning or poorly configured nodes.
	\item Adopt a least privilege strategy and strictly enforce access control\\
	As a design principle, information is kept hidden as much as possible within the system. We always assume that an adversary
	\begin{itemize}
		\item makes some or all information within his reach available to others.
		\item analyzes all information within his reach.
		\item willingly breaks protocol rules to gain information, disrupts information flows, or other advantages.
	\end{itemize}		
	\item Inspect and log all traffic\\
	We skip that part, as it is not suitable for a system offering anonymity. Logs generated over a long period might result in data that allows reducing anonymity sets retrospectively or minimizing their size.
	
\end{enumerate}

\chapter{Related Cryptographic Theory and Algorithms}\label{sec:cryptoResearch}

Whenever handling obfuscating data and maintaining data integrity, cryptography is the first tool in an implementer's hand, as a vast amount of research in this area already exists. For this work, we focused on algorithms either researched in depth and implemented or research, which seemed very valuable when putting this work into place. 

In symmetric encryption\index{symmetric encryption} in this paper always assumes that
\begin{eqnarray}
	D^{K_a}\left(E^{K_a}\left(\mathbf{M}\right)\right) & = & \mathbf{M}
\end{eqnarray} 

For a key $K_b\neq K_a$ this means

\begin{eqnarray}
	D^{K_a}\left(E^{K_b}\left(\mathbf{M}\right)\right) & \neq & \mathbf{M}\\
	D^{K_b}\left(E^{K_a}\left(\mathbf{M}\right)\right) & \neq & \mathbf{M}
\end{eqnarray} 

A good symmetric algorithm has withstood academic crypto-analysis over a considerable period of time and has not been weakened so far. Multiple algorithms are ideally not built similarly and  not rely on the same mathematical problems.

The following candidates have been identified for our work:
\begin{itemize}
	\item AES\\
	NIST announced AES in \citeyear{standard2001announcing} as a result of a contest. The algorithm works with four operations (subBytes, ShiftRows, mixColumns, and addRoundKey). These operations are repeated depending on the key length 10 to 14 times. 
	
	AES is, up until now (2020) unbroken. It has been weakened in the analysis described in~\cite{tao2015improving}, which reduces the complexity by roughly one to two bits. 
	
	\item Camellia\\
	The Camellia algorithm is described in~\cite{rfc3713}. The key sizes are 128, 192, and 256. Camellia is a Feistel cipher with 18 to 24 rounds depending on the key size. Up until 2020, no publication claims to break this cipher. 
\end{itemize}

For all asymmetric encryption\index{asymmetric encryption} algorithms in this paper, we may assume that\ldots

\begin{eqnarray}
	D^{K^{1}_a}\left(E^{K^{-1}_a}\left(\mathbf{M}\right)\right) & = & \mathbf{M}
\end{eqnarray} 

It is important that 
\begin{eqnarray}
	D^{K^{-1}_a}\left(E^{K^{-1}_a}\left(\mathbf{M}\right)\right) & \neq & \mathbf{M}\\
	D^{K^{1}_a}\left(E^{K^{1}_a}\left(\mathbf{M}\right)\right)   & \neq & \mathbf{M}
\end{eqnarray} 

For any other key pair $K^{p}_a \neq K^{p}_b$
\begin{eqnarray}
	D^{K^{-1}_b}\left(E^{K^{1}_a}\left(\mathbf{M}\right)\right)  & \neq & \mathbf{M}\\
	D^{K^{1}_b}\left(E^{K^{1}_a}\left(\mathbf{M}\right)\right)   & \neq & \mathbf{M}\\
	D^{K^{-1}_b}\left(E^{K^{-1}_a}\left(\mathbf{M}\right)\right) & \neq & \mathbf{M}\\
	D^{K^{1}_b}\left(E^{K^{-1}_a}\left(\mathbf{M}\right)\right)  & \neq & \mathbf{M}
\end{eqnarray} 

When looking for well-researched algorithms basing on different mathematical problems and having well-defined outlines, numbers decreased dramatically.

\begin{itemize}
	\item RSA\index{RSA}\\
	In \citeyear{Rivest:1978:MOD:359340.359342} the authors \citeauthor{Rivest:1978:MOD:359340.359342} published with~\cite{Rivest:1978:MOD:359340.359342} a paper which revolutionized cryptography. In their paper, the authors described an encryption method later called RSA, which required a key pair ($K_a$) referenced as public ($K^{1}_a$) and private keys ($K^{-1}_a$). This system's novelty was that anything encrypted with the public key was only decryptable with the private key and vice versa.
	
	RSA is up until 2020 not publicly known to be broken (unless a too small key size is used). 
	However, \citeauthor{Shor97polynomial-timealgorithms} described in \citeyear{Shor97polynomial-timealgorithms} an algorithm that should enable quantum computers to break RSA far faster than traditional computers. In the \cref{sec:keySize} we further elaborate these effects.
	\item ECC\index{elliptic curves}\\
	The elliptic curves were independently suggested by~\cite{Miller1986} and~\cite{Koblitz04guideto} in 1986. Elliptic curve cryptography started to be widely deployed in the public space in 2006. Since then, it seems to compete excellenty with the well established RSA algorithm. While being similarly well researched, ECC has the advantage of far shorter key sizes for the same grade of security.
	\item McEliece\index{McEliece}\\
	McEliece was first implemented and then removed again. The key size to gain equivalent security to RSA1024 was $\approx 1MB$. By utilizing Gaussian elimination the key size may be reduced for transport by approximately factor $10$. Even the resulting key size was still impractical and thus discarded as well. We were unable to identify any quantum capable algorithm that is able to reduce the key size of McEliece algorithm.
	\item NTRU\index{NTRU}\\
	In~\cite{Hoffstein1998} \citeauthor{Hoffstein1998} described the NTRU algorithm. The inclusion of this algorithm was disputed as it is patented in the United States as US7031468. It was included because the company Security Innovation holding the patent released the NTRU algorithm in March \nth{28} 2018 to the public domain, according to a blog entry on the company website. While NTRU is not as well researched as RSA, it has been around for more than 20 years without being significantly affected by known attacks.
	\item ElGamal\index{ElGamal}\\
	We rejected ElGamal as a cryptosystem to include. It bases on the same mathematical problems for cryptoanalysis as RSA (discreet logarithms) but is not as common as RSA.
\end{itemize}


As introduced in~\cite{feldman1987practical}, homomorphic encryption\index{homomorphic encryption} was from the beginning a strong candidate to be used in our work. Unfortunately, we did not find a way to apply the core $addRedundancy$ operation in homomorphic encryption. Transforming the original data to the GF space efficiently to use matrices was not feasible and thus rejected.

%\cite{Gentry:2009:FHE:1536414.1536440} %FIXME dangling reference

\section{Deniable Encryption}
Deniable encryption was considered out-of-bounds for this work. The main reason is that the presence of encryption (which is not deniable in our cases) may be sufficient for a censor to block a message. Adding a layer to ensure that encryption is deniable does not add valuable properties to our system, as the sheer presence of encryption might be sufficient for censorship. 

\section{Key Sizes}\label{sec:keySize}
The question of key sizes is difficult to answer as it depends on the current and future possibilities of an adversary, which again relies on non-foreseeable research. We collected several recommendations.

\href{http://www.ecrypt.eu.org/}{Encrypt II (http://www.ecrypt.eu.org/)} currently recommends for a ``foreseeable future'' 256 bits for symmetric and  asymmetric encryption based on the factoring modulus 15424 bits. Elliptic curve cryptography and hashing should be sufficient if used with at least 512 bits. Assuming the focus is reduced to the next $\approx$ 20 years. In that case, the key size recommendations are reduced to 128 bits for symmetric encryption, 3248 bits for factoring modulus operations, and 256 bits for elliptic curves and hashing.

According to the equations proposed by \citeauthor{Lenstra04keylength.} in~\cite{Lenstra04keylength.} an asymmetric key size of 2644 bits respectively symmetric key length of 95 bits, or 190 bits for elliptic curves and hashing should be sufficient for security up to the year 2048. 

According to~\cite{CNSASuite} (superseding well known and often used~\cite{nsa-fact-sheet-B}) data classified up to ``top secret'' should be signed with RSA 3072+ or ECDSA P-384.  They recommend AES 256 bits for symmetric encryption, for hashing at least SHA-384, and for elliptic curves, a 384 bit-sized key.

As it might seem unwise to consider the recommendation of a potential state-sponsored adversary and the formulas proposed by \citeauthor{Lenstra04keylength.} do not explicitly take quantum computers into account, we follow the advice of ENCRYPT II.

Furthermore, taking all recommendations together, it seems that all involved parties assume the most trust in elliptic curves rather than asymmetric encryption based on factoring modulus.

\section{Cipher Mode}
The cipher mode defines how multiple blocks encrypted with the same key are handled. The main characteristics of cipher modes to us are:
\begin{itemize}
	\item Parallelizable\\ 
	Can multiple parts of a plaintext be encrypted simultaneously? This feature is important for multi CPU and multi-core systems as they can handle parallelizable modes more efficiently by distributing them on multiple CPUs.
	\item Random access in decryption\\
	Random access in decryption allows efficient partial encryption of a ciphertext.
	\item Initialization vector\\
	An initialization vector has advantages and disadvantages. One disadvantage is that involved parties must share an initialization vector with the message or before distributing it. It is essential to understand that the initialization vector itself usually is not treated as a secret, as it is not part of the key.
	\item Authentication\\
	Authentication guarantees that the deciphered plaintext has been unmodified since encryption. It does not make a statement over the identity of the party encrypting the text. Such an identifying authentication is referred to as signcryption.
\end{itemize}

We evaluated the most common cipher modes for suitability. For \MessageVortex, we focused on modes with parallelizable, random access modes and did not carry out authentication. In addition to the characteristics mentioned above, the main focus was on whether there is an open implementation in Java, which is reasonably tested.

\begin{itemize}
	\item ECB (Electronic Code Book)\index{ECB}\\
	ECB is the most basic mode. Each block of the cleartext is encrypted on its own. This results in a big flaw: blocks containing the same data will always transform to the same ciphertext. This property makes it possible to see some structures of the plaintext when looking at the ciphertext. This solution allows the parallelization of encryption, decryption, and random access while decrypting. Due to these flaws, we rejected this mode.
	\item CBC (Cipher Block Chaining)\index{CBC}\\  
	CBC extends the encryption by XORing an initialization vector into the first block before encrypting. For all subsequent blocks, the ciphertext result of the preceding block is taken as XOR input. This solution does not allow parallelization of encryption, but decryption may be paralleled, and random access is possible. As another disadvantage, CBC requires a shared initialization vector. As with most IV bound modes, an IV/key pair should not be used twice, which has implications for our protocol.
	\item PCBC (Propagation Cipher Block Chaining)\index{PCBC}\\
	CBC extends the encryption by XORing, not the ciphertext but a XOR result of ciphertext and plaintext. This modification denies parallel decryption and random access compared to CBC.
	\item EAX\\      
	EAX was broken in 2012~\cite{minematsu2013attacks} and is thus rejected for our use.
	\item CFB (Cipher Feedback)\index{CFB}\\
	CFB is specified in~\cite{dworkin2001recommendation} and works as precisely as CBC with the difference that the plaintext is XORed and the initialization vector, or the preceding cipher result is encrypted. CFB does not support parallel encryption as the ciphertext input from the prior operation is required for an encryption round. CFB does however allow parallel decryption and random access.
	\item OFB\index{OFB}\\
	\cite{dworkin2001recommendation} specifies OFB and works precisely as CFB except for the fact that not the ciphertext result is taken as feedback, but the result of the encryption before XORing the plaintext. This denies parallel encryption and decryption, as well as random access.
	\item OCB (Offset Codebook Mode)\index{OCB}\\
	This mode was first proposed in~\cite{rogaway2003ocb} and later specified in~\cite{krovetz-ocb-04}. OCB is specifically designed for AES128, AES192, and AES256. It supports authentication tag lengths of 128, 96, or 64 bits for each specified encryption algorithm. OCB hashes the plaintext of a message with a specialized function $H_{OCB}(\mathbf{M})$. OCB is fully parallelizable due to its internal structure. All blocks except the first and the last can be encrypted or decrypted in parallel.
	\item CTR\index{CTR}\\
	CTR is specified in~\cite{lipmaa2000ctr} and is a mixture between OFB and CBC. A nonce concatenated with a counter incrementing on every block is encrypted and then XORed with the plaintext. This mode allows parallel decryption and encryption, as well as random access. Reusing IV/key-pairs using CTR is a problem as we might derive the XORed product of two messages. This problem only applies where messages are not uniformly random such as in an already encrypted block.
	\item CCM\index{CCM}\\
	Counter with CBC-MAC (CCM) is specified in~\cite{rfc3610}. It allows for padding and authenticating encrypted and unencrypted data. It furthermore requires a nonce for its operation. The size of the nonce is dependent on the number of octets in the length field. In the first 16 bytes of the message, the nonce and the message size is stored. For the encryption itself, CTR is used. It shares the same properties as CTR. 
	
	It allows parallel decryption and encryption as well as random access.
	\item GCM (Galois Counter Mode)\index{GCM}\\
	GCM has been defined in~\cite{mcgrew2004galois}, and is related to CTR but has some major differences. The nonce is not used (just the counter starting with value 1). An authentication token $auth$ is hashed with $H_{GFmult}$ and then XORed with the first cipher block to authenticate the encryption. All subsequent cipher blocks are XORed with the previous result and then hashed again with $H_{GFmult}$. After the last block the output $o$ is processed  as follows: $H_{GFmult}(o\bigoplus (len(A)||len(B))) \bigoplus E^{K^0}(counter_0)$. As a result, GCM is not parallelizable and does not support random access.
	
	The mode was analyzed security-wise in \citeyear{mcgrew2004security} and showed no weaknesses in the studied fields~\cite{mcgrew2004security}. 
	
	GCM supports parallel encryption and decryption. Random access is also possible. However, the authentication of encryption is not parallelizable. The authentication makes it unsuitable for our purposes. Alternatively, we could use a fixed authentication string.
	\item XTS (XEX-based tweaked-codebook mode with ciphertext stealing)\index{XTX}\\
	This mode is standardized in IEEE 1619-2007 (soon to be superseded). A rough overview of XTS may be found at~\cite{Martin2010}. It was developed initially for disks offering random access and authentication at the same time. 
	\item CMC (CBC-mask-CBC) and EME (ECB-mask-ECB)\index{CMC}\index{EME}\\ 
	In~\cite{Halevi:2003} \citeauthor{Halevi:2003} introduces a cipher mode which is extremely costly as it requires two encryptions. CMC is not parallelizable due to the underlying CBC mode, but EME is. 
	\item LRW\index{LRW}\\
	LRW is a tweakable narrow-block cipher mode described in~\cite{tschorsch:translayeranon}. This mode shares the same properties as EBC but without the same cleartext block's weakness resulting in the same ciphertext. Similar to XEX, it requires a tweak instead of an IV.
\end{itemize}

\section{Summary of Cipher Modes}
Table~\ref{tab:ModeSuitCrit} shows a summary of all modes analyzed previously.
\begin{table}[H]
	\centering\tiny
	\begin{tabular}{|l|l|l|l|l|}\hline
		\diaghead{\theadfont Mode Criteria}{Mode}{Criteria}         & \thead{auth}  &\thead{Requires IV}               & \thead{parallelizable}     & \thead{random access}\\
		\hline
		CBC                                                            & $\times$        & $\checkmark$                      & $\times$                & $\times$\\                      
		CCM                                                            & $\times$        & $\checkmark$                      & $\times$                   & $\times$\\
		CFB                                                            & $\times$        & $\checkmark$                      & $\checkmark$            & $\checkmark$\\              
		CTR                                                            & $\times$        & $\checkmark$                      & $\checkmark$               & $\checkmark$\\              
		ECB                                                            & $\times$        & $\times$                          & $\checkmark$            & $\checkmark$\\   
		GCM                                                            & $\checkmark$    & $\checkmark$                      & $\times$                   & $\times$\\              
		OCB          & $\checkmark$& $\times$\footnotemark[1]    &$\times$                    &$\times$\\
		OFB          & $\times$    & $\checkmark$                &$\times$                    &$\times$\\
		PCBC         & $\times$    & $\checkmark$                &$\times$                    &$\times$\\
		XTS          & $\times$    & $\checkmark$\footnotemark[2]&$\checkmark$                &$\times$\\
		LRW          & $\times$    & $\checkmark$\footnotemark[2]&$\checkmark$                & $\checkmark$\\
		CMC          & $\times$    & $\checkmark$\footnotemark[2]& $\times$                   & $\times$\\
		EME          & $\times$    & $\checkmark$\footnotemark[2]& $\checkmark$                    & $\checkmark$\\              
		\hline          
	\end{tabular}    
	\caption{Comparison of encryption modes in terms of the suitability.}
	\label{tab:ModeSuitCrit}
\end{table}
\footnotetext[1]{included in auth}
\footnotetext[2]{Requires tweak instead of IV}

GCM and OFB are only suitable in special cases for our protocol as they perform authentication, which we usually omit from a message. OCB and ECB are ``IV-less'' modes making them very attractive for us. However, we need to consider that ECB\index{ECB} is deemed broken and the discovered flaws are relevant to us if not handled properly. Especially suitable from performance perspective are CFB, CTR, ECB, LRW, and EME. Most of these implementations are uncommon in crypto-libraries. We will use these findings when defining our supported modes in \cref{sec:modeSelection}.

\section{Padding}
A plaintext stream may have any length. Since we always encrypt in blocks of a fixed size, we need a mechanism to indicate how many bytes of the last encrypted block may be safely discarded. 

Different paddings are used at the end of a cipher stream to indicate how many bytes belong to the decrypted stream.

\subsection{RSAES-PKCS1-v1\_5 and RSAES-OAEP}\index{RSAES-PKCS1-v1\_5}\index{RSAS-OAEP}
This padding is the older of the paddings standardized for PKCS1. It is basically a prefix of two bytes followed by a padding set of non-zero bytes and then terminated by a zero byte and then followed by the message. This padding may provide a clue whether the decryption was successful or not. RSAES-OAEP is the newer of the two padding standards 

\subsection{PKCS7}\index{PKCS7}
This padding is the standard used in many places when applying symmetric encryption up to 256 bits key length. The free bytes in the last cipher-block indicate the number of bytes being used. This makes this padding very compact. It requires only 1 byte of available data at the end of the block. All other bytes are defined but not needed.

\subsection{OAEP with SHA and MGF1 padding}\index{OAEP}
This padding is closely related to RSAES-OAEP padding. However, the hash size is larger, and thus the required space for padding is much higher. OAEP with SHA and MGF1 padding is used in asymmetric encryption only. Due to its size, it is essential to note that the last block's payload shrinks to $keySizeInBits/8-2-MacSize/4$.

In our approach, we chose to allow these four paddings. The allowed SHA sizes match the allowed MAC sizes selected above. It is important to note that padding costs space at the end of a stream. Since we are always using one block for signing, we have to ensure that the chosen signing MAC and the bytes required for padding do not exceed the asymmetric encryption's key size. While this usually is not a problem for RSA as there are keys 1024+ bits required, it is a fundamental problem for ECC algorithms as there are much shorter keys needed to achieve an equivalent strength compared to RSA. 

We introduced an additional type of padding not related to these paddings. We required for the addRedundancy the following unique properties. Unfortunately, we were unable to find any padding which matched the following properties simultaneously:

\begin{itemize}
	\item Padding must not leak successful decryption\\
	For our addRedundancy operation, we required padding that had no detectable structure as a node should not tell whether a removeRedundancy operation did generate content or decoy. 
	\item Padding of more than one block\\
	Due to the nature of the operation, it is required to pad more than just one block.
\end{itemize}

Details of this padding are described in the section "Add and Remove Redundancy Operations'' in \cref{app:rfcMessageVortexMain}. 

\chapter{Censorship Circumvention}\label{sec:censorshipResearch}\index{censorship circumvention}
Several technical ways were explored to circumvent censorship. All seem to share the following main ideas:
\begin{itemize}
	\item Hide data (e.g., Tor pluggable transports).
	\item Copy or distribute data to a vast amount of places to improve the lifespan of data (e.g., Wikileaks).
	\item Outcurve censorship measurements (e.g., use a modified client to ignore connection resets).
\end{itemize}

In the following section, we look at technologies and ideas handling these circumvention technologies.

\section{Covert Channel and Channel Exploitations}\index{covert channel}
The original term of covert channels was defined by \citeauthor{Lampson73anote}~\cite{Lampson73anote} as 

\begin{shadequote}{}
	Not intended for information transfer at all, such as the service program's effect on system load.
\end{shadequote}

This was defined in such a way as to distinguish the message flow from 

\begin{shadequote}{}
	Legitimate channels used by the confined service, such as the bill.
\end{shadequote}

The use of a legitimate channel such as \defref{SMTP} and hiding information within this specific channel is not a usage of a covert channel. We refer to this as channel exploitation.

\section{Steganography}\index{steganography}
Steganography is important when it comes to unlinking information. ~\cite{6828087} and~\cite{subhedar2014current} give a very rough overview. As some of the types and algorithms address specific steganography topics (e.g., some hide from automatic detection and others address a human message stream auditor), we must choose carefully. In our specific case, the main idea is to hide within the sheer mass of Internet traffic. A human auditor screening all messages within a jurisdiction is considered a minor threat for obvious reasons. We will therefore focus on machine-based censorship. 

As we will later identify \defref{SMTP} as one of the main transport protocols, we focussed on the type of traffic found within this and similar protocols. Most of the binary data sent in \defref{SMTP} are jpg images (see \cref{tab:emailAttachments} on page \pageref{tab:emailAttachments}). We limited our search to algorithms capable of hiding binary data within these files. The number of academically researched options was surprisingly low.

After reviewing the options, we decided to go for F5~\cite{f5}\index{F5}. It is a reasonably well-researched algorithm that attracted many researchers. The original F5 implementation had a detectable issue with artifacts~\cite{F5broken} caused by the image's recompression. This issue was caused only due to a problem in the reference implementation, and the researchers meanwhile provided a corrected reference implementation without the weakness.

% We use https://github.com/matthewgao/F5-steganography

YASS, as described in~\cite{solanki2007yass}, was not considered a candidate. Although less researched, researchers found multiple weakness\-es~\cite{kodovsky2010modern,li2009steganalysis}.

%other options : MM3 only good below 5% (unclear ; no implementation found);  PQe or PQt only good below 10% (only Matlab)
% other algorithms nsF5 (only Matlab)

In general, the availability of steganographic implementations was incredibly poor. Most of the algorithms are only available as M-code, simulators, or stream encoders, skipping all real-world implementation problems.

\section{Timing Channels}\index{timing channel}

Timing channels are a specialized form of covert channels. In timing channels, the information itself hides not within the channel's data, but the usage of the channel works in such a way that it is capable of reflecting the data. As we do not have control over the transport channel's timing, this is not an option.

\section{Technical Forms of Censorship}\index{censorship}
There are many types of censorship available within technical systems. An in-depth understanding of the possibilities is required to understand the means of a censoring adversary.

\subsection{Making Systems Unavailable by Censoring Lookups}
This is one of the cheapest methods to create censorship. Lookup systems such as DNS servers are modified so that traffic is no longer deliverable or redirected to a system controlled by the censor.

Many jurisdictions have implemented such measures. It is considered a very cheap measure of censorship. It is, however, very easy to outcurve. As soon as a user no longer uses adversary controlled lookup services, this form of censorship is ineffective. In the case of DNS, this means either: 

\begin{itemize}
	\item Using a public DNS server available worldwide. 
	\item Using another protocol to hide the traffic .
	\begin{itemize}
		\item A protocol with tunneling capabilities like SSH may be used to reach a system outside of the reach of the censoring adversary.
		\item Using a fully blown tunnel such as a VPN.
		\item Piggybacking a legitimate protocol such as DNS-over-HTTPS (DoH)~\cite{rfc8484} or DNS-over-XMPP~\cite{xep0418}
	\end{itemize}
\end{itemize}

\subsection{Making Systems Unavailable by Disrupting System Traffic}
Disruption of traffic is achieved with packet filtering devices commonly referred to as firewalls. These firewalls may filter any traffic to a given system. There are some considerable disadvvantages to this system from the adversary's point of view.

First, a censoring adversary requires high bandwidth. All traffic of a jurisdiction or target must pass through such a filtering device. This is usually not easily feasible for a country. A very high bandwidth system, such as the great China wall, uses a different approach. Instead of filtering each packet, they concentrate on TCP connections. Each slightly suspicious packet is copied to an analyzing system while the original message is routed normally. A subsequent system then analyzes the copied packet or packet sequence. If the subsequent system decides that the traffic should be censored, a connection reset is sent to the sender and the recipient. Any client or server having standard protocol support will immediately cease communication.

Secondly, the target must be identifiable on a technical level (e.g., IP address) as content-based filtering is only feasible with unencrypted or weakly protected systems. This technical identification is challenging as systems may change their addresses dynamically either due to cloud-related elasticity or due to an incomplete view of a distributed system (e.g., only a Loadbalancer is visible). An IP is therefore not necessarily synonymous with a single user or server. 

When looking at the client side, they are often hidden behind a network address translation (NAT) or a proxy collapsing all users onto a single IP address. The same applies to the server-side, where cloud washing and reverse proxy infrastructures optimize bandwidth usage. Sometimes, in-depth information or insight into a protocol may help narrow down a user (e.g., by a set cookie or a fingerprint). When using encrypted connections, ordinary attackers have trouble carrying out a Man in the Middle (MitM) attack. This may be feasible for a larger attacker on a state or Internet service provider (ISP) level. To do so, such an adversary requires access to a publicly accepted CA, creating fake certificates for the attacker. It may be safely assumed that such access is given considering the standard set of CAs, which is trusted nowadays (depending on the delivered trust store, we found between 100 and 200 root CAs).

Identifying a target is especially difficult if a target comprises multiple possible targets from which some may be valid. This is the case when using a reverse proxy and using the same platform for numerous purposes. Streaming or movie platforms may contain content that should be banned from a censors' point of view and content that comprises legitimate content such as educational material. From the censors' point of view, this content can not be reasonably split. This since typically, only the provider of the service can carry our selective censoring on the system. This is why governments try to shift the responsibility of censorship to the providers by establishing self-censorship. 

\subsection{Making Systems Unavailable by Interfering with System Traffic}
Censoring may be achieved in more subtle or less abusive ways, such as traffic shaping or content moderation. We already outlined that the platform provider usually has content moderation in place. This is either achieved by allowing an entity to control the platform directly or indirectly to apply censorship or use legal means to force the platform into self-censorship.

Other means of censorship are:
\begin{itemize}
	\item Redirecting all traffic to certain systems to filter according to the needs of a censor.
	\item Shaping traffic in such a way that the service is deemed no longer available to people of a jurisdiction (e.g., by slowing down traffic in such a way that streaming is no longer a viable option).
	\item Redirecting traffic to similar platforms employing a form of censorship (either a localized form of the respective information or an alternate provider of the same form of information).
\end{itemize}

\section{Spread Spectrum in Networking Protocols}
Another possibility of sending anonymous information is ``spread spectrum'' transmission. In spread spectrum transmission, a radio signal is distributed in the frequency domain. This makes it difficult for an adversary to identify and disrupt those radio signals in question. 

While in use when carrying out radio-electric transmission, the spread spectrum is very uncommon in network protocols. We could employ multiple protocols and packet types to transmit data. Unlike in radio signals, such data is always available as discrete information pieces, and an adversary may choose to block them at any point. Unlike in radio transmission, where the available spectrum is almost indefinite and not fully blockable by practical means, full censorship does not oppose a problem. We may completely disrupt all communication by no longer routing it.
