Applied Colins feedback.HEADmaster

1 files changed, 73 insertions, 63 deletions

diff --git a/content/cmix.tex b/content/cmix.tex
index 5b6504b..6900918 100644
--- a/content/cmix.tex
+++ b/content/cmix.tex
@@ -1,81 +1,80 @@
 \newcommand{\NODE}[1]{
-	$node_{#1}$
+	\unskip$node_{#1}$\xspace
 }
 
 \section{Anonymity networks}
 \label{sec:anon}
 
-Networks providing anonymity are needed and are being used in the present day. Unfortunately they are partly needed to escape surveillance and prosecution from oppressive governments\cite{jardine2018tor}. Fortunately there are also other applications like voting schemes\cite{park1993efficient}. In any it helps to understand what different types of anonymity networks exist and how they work in relation to \cmix. And how the techniques used in \cmix were pioneer elsewhere and what problems \cmix addresses with regards to other anonymity networks.  
+Networks providing anonymity are needed and are being used in the present day. They are used by journalist and/or activist to escape surveillance and prosecution from oppressive governments\cite{jardine2018tor} or they can be used for electronic voting schemes\cite{park1993efficient}. Either way it is useful to understand what different types of anonymity networks exist, what their goals are, and how they work with regards to \cmix{}. They show how the techniques used in \cmix{} today were pioneered by other anonymity networks. Showing the problems and shortcomings of the various networks and how \cmix{} addresses some of them to better suit their target user base.  
 
-\subsection{The onion router}
-We can't talk about anonymity networks without talking about The Onion Router\cite{goldschlag1999onion} or TOR for short. It's a free software project that provides access to an anonymity network based on Onion Routing.
+\subsection{The Onion Router}
+We can't talk about anonymity networks without talking about The Onion Router\cite{goldschlag1999onion} or TOR for short. It's a popular and free software project that provides access to an anonymity network based on onion routing.
 
 \begin{figure}[!ht]
 	\centering
 	\begin{subfigure}{.5\textwidth}
 		\centering
-		\includegraphics[width=.9\linewidth]{images/tor.png}
-		\caption{A tor route, image taken from\\ \protect\url{https://www.torproject.org/about/overview.html.en}}
+		\includegraphics[width=.9\linewidth]{images/TOR.png}
+		\caption{A TOR route, image taken from\\ \protect\url{https://www.torproject.org/about/overview.html.en}}
 		\label{fig:tor}
 	\end{subfigure}%
 	\begin{subfigure}{.5\textwidth}
 		\centering
 		\includegraphics[width=.9\linewidth]{images/layers.png}
-		\caption{Tor layers, image taken from\\ \protect\url{https://www.cryptologie.net/article/203/how-does-tor-works/}}
+		\caption{TOR layers, image taken from\\ \protect\url{https://www.cryptologie.net/article/203/how-does-tor-works/}}
 		\label{fig:layers}
 	\end{subfigure}
-	\caption{2 figures visualizing how tor works}
-	\label{fig:howtorworks}
+	\caption{Two figures visualizing how TOR works}
+	\label{fig:how TOR works}
 \end{figure}
 
-Tor works by allowing users to select a random path consisting of 3 nodes trough the tor network as you can see in \autoref{fig:tor}. When a user wants to send a message it has to encrypt it with the key of the exit node of the chosen path. This encryption results then needs to be encrypted with the key of the middle node, a relay node. Lastly the encryption result needs to be encrypted with the key of the first node, which also is a relay node. The the user can send this encrypted ``onion'' to the first node. The first node can peel off the outer layer of encryption and send it to the second node which in turn can peel of the new outer layer. The last node removes the last layer of encryption, revealing the plaintext message of the user. This plaintext can be sent to the user chosen destination as you can see in \autoref{fig:layers}. Which from the outside decouples the actual sender and receiver of the message. 
+TOR  works by allowing users to select a random path consisting of three nodes trough the TOR network as you can see in \autoref{fig:tor}. When a user wants to send a message it has to encrypt it with the key of the exit node of the chosen path. This encryption results then needs to be encrypted with the key of the middle node, a relay node. Lastly the encryption result needs to be encrypted with the key of the first node, which also is a relay node. The user can send this encrypted ``onion'' to the first node. The first node can peel off the outer layer of encryption and send it to the second node which in turn can peel of the new outer layer. The last node removes the last layer of encryption, revealing the plaintext message of the user. This plaintext can be sent to the users chosen destination as you can see in \autoref{fig:layers}. Which from the outside decouples the actual sender and receiver of the message. 
 
-This simplified view of TOR reveals that the sender of a certain message remains anonymous so long as at least one of your 3 nodes is not compromised. And you use End to End encryption because the last node will see your plaintext.
+This simplified view of TOR reveals that the sender of a certain message remains anonymous as long as at least one of your three nodes is not compromised. One should also use end-to-end encryption, because the last node will see your plaintext.
 
-Unfortunately there is a fairly simple timing attack that can de anonymize the traffic trough the network. This is exploited by a correlation  attack\cite{Johnson:2013:UGR:2508859.2516651}. This is an attack where the attacker sees incoming traffic of your first node and the outgoing traffic of the last node. It can then try to correlate the entry times, exit times, origin, destination and size of the packets. An attacker can use this data to correlate a packet entering and exiting the network and therefore link a user and a destination with a certain probability. Therefore de-anonymizing the traffic. This attack is highly probabilistic, but could flag users for further targeted investigation. Therefore we really want to prevent this attack from being possible.
+Unfortunately there is a fairly simple timing attack that can de anonymize the traffic trough the network. This is exploited by a correlation  attack\cite{Johnson:2013:UGR:2508859.2516651}. This is an attack where the attacker sees incoming traffic of your first node and the outgoing traffic of the last node. It can then try to correlate the entry times, exit times, origin, destination, and size of the packets. An attacker can use this data to correlate a packet entering and exiting the network and therefore link a user and a destination with a certain probability. Thereby de-anonymizing the traffic. This attack is highly probabilistic, but could flag users for further targeted investigation. Therefore we really want to prevent this attack from being possible.
 
-In the case of TOR, because the timing of a single packet trough the network doesn't differ that much, the attack is relatively simple. This simple form of correlation attack would be mitigated by a mix network, a different type of anonymity network.
+In the case of TOR the attack is relatively simple. The timing of a single packet trough the network is stable enough between consequent packets that you can easily correlate the input into and the output out of the network. This simple form of correlation attack would be mitigated by a mix network, a different type of anonymity network.
 
 \subsection{Mix networks}
 
-The first mix network was proposed and developed by David Chaum \cite{chaum1981untraceable}. This mix network makes use of $N$ nodes. Each of these nodes has a public/private key pair. All users and nodes also have a identifier. Users that want to use the mix network have to package their message by pre-pending the identifier of the destination to the message and encrypts it with the public key of \NODE{N}. It then prepends the identifier of \NODE{N} and encrypts it with the public key of \NODE{N-1}. The client does this for all the nodes in the network working backwards. It can then send the message to the first node.
+The first mix network was proposed and developed by David Chaum \cite{chaum1981untraceable}. This mix network makes use of $N$ nodes. Each of these nodes has a public/private key pair. All users and nodes also have an identifier. Users that want to use the mix network have to create their message by pre-pending the identifier of the destination to the message. The user then encrypts it with the public key of \NODE{N}. It then prepends the identifier of \NODE{N} and encrypts it with the public key of \NODE{N-1}. The client does this for all the nodes in the network working backwards. It can then send the message to the first node (\NODE{1}.)
 
-This first node can now unpack the message it receives and retrieve an identifier for the next node and a encrypted message which only the next node can decrypt. The last node can decrypt the original destination and message which it can send it to the end user. Up until this point this is roughly how the TOR anonymity network operates, but there is a difference. The first node in the \cmix network does not immediately send out the messages it receives. The node first collects up to $P$ messages. When this threshold is achieved it will decrypt all the messages and randomly shuffle the order they were in, otherwise known as mixing. It then sends them to the next node. Another subtle difference is that each message within one mix operation should have the same length, However it is possible to choose a large enough message size and pad all the messages to this fixed length.
+This first node can now decrypt the message it received. It then ends up with an identifier for the next node and a encrypted message which only the node with that identifier can decrypt. The current node sends that encrypted message to the destination with the corresponding identifier. This will continue until it reaches the last node. The last node can decrypt the original destination and message which it can send it to the end user. This is also how the TOR network operates, however we left out some details. The first node in the mix network does not immediately send out the messages it receives. The node first collects up to $P$ messages. When this threshold is reached it will decrypt all the messages and randomly shuffle the order they were in, also known as mixing. It then sends them to the next node. Another subtle difference is that each message within one mix operation should have the same length. However, it is possible to choose a large enough message size and pad all the messages to this fixed length.
 
-This mixing and delaying in the first node causes an arbitrary amount of delay on when a message arrives at the first node and exits the first node. Furthermore, an outsider analyzing the input and output of the nodes cannot see which packet went where in the mixing operation. So it cannot keep track of a specific message. This is what grants the additional anonymity within mix networks, as it mitigates the simple timing attacks possible on TOR. However more complex attacks are still possible. By keeping track of multiple runs of the mix network and probing in between mix nodes. The mix network, without additional mitigations, is still vulnerable to flow analysis attacks\cite{zhu2004flow}.
+The aggregation of messages in the first node cause an arbitrary amount of delay on the arrival of the messages. Either the arrival in the next node or the final destination of the packet. The mixing of hte messages makes it impossible for an outsider analyzing the input and output to correlate the input timing of a packet and it's position in the output buffer of a node. This means it cannot keep track of a specific message. This is what grants the additional anonymity within mix networks, as it mitigates the simple timing attacks possible on, for instance, TOR. However, more complex attacks are still possible. By keeping track of multiple runs of the mix network and probing in between mix nodes. The mix network, without additional mitigations, is still vulnerable to flow analysis attacks\cite{zhu2004flow}.
 
 \subsection{Re-encryption mix networks}
 
-The introduction of Re-encryption mix nets by Park et all \cite{park1993efficient}
-introduces the usage of \elgamal encryption in mix nets. Using it's homomorphic properties to no longer de-encrypt each incoming message but rather just re-encrypt the message which is faster. It also has the effect that the ciphertext no longer lengthens in the order of the amount of nodes in the mix network. Which does happen in the classic Chaum mix network and in TOR.
+The introduction of Re-encryption mix networks by Park et al. \cite{park1993efficient}
+introduces the usage of \elgamal{} encryption in mix networks. Using it's homomorphic encryption properties to no longer de-encrypt each incoming message but rather just re-encrypt the message, which is faster. It also has the effect that the ciphertext does not lengthen in the order of the amount of nodes in the mix network. This does happen in the classic Chaum mix network and in TOR, which needs to be fixed by adding additional padding.
 
-The network operates by each node having a public and private \elgamal key. Each node publishes its public key and a user can use all of the public keys of the nodes to encrypt a message. Each node can re-encrypt the message with it's private key. After the last nodes successfully re-encrypts the value the plain text is revealed. In the original paper this is used as a voting scheme and therefore no mention is made of a Receiver as it just needs to aggregate in one place. But is of course extensible to support sending messages to specific recipients.
+The network operates by each node having a public and private \elgamal{} key. Each node publishes its public key and an user can use all of the public keys of the nodes to encrypt a message. Each node can re-encrypt the message with it's private key. After the last nodes successfully re-encrypts the value the plain text is revealed. In the paper by Park et al. \cite{park1993efficient} this is used as a voting scheme and therefore no mention is made of a ``receiver'' or ``identifier'' as the goal is to aggregate the plaintexts in one place without revealing the original sender of a particular message. This scheme could be extended to support sending messages to specific recipients.
 
-A major downside of these classic mix network is the amount of public key operations the client and nodes need to do when sending single message. This may not be an issue on modern day desktop computers and or low traffic volume applications, but it is an issue for mobile phones' with respect to battery life and low-power devices such as sensors networks. 
+A major downside of these classic mix network is the amount of public key operations the client and nodes need to do when sending a single message. This may not be an issue on modern day desktop computers and/or low traffic volume applications. It is however, an issue for mobile phones with respect to battery life and low-power devices such as sensors networks. 
 
-This is something that \cmix is attempting to resolve by introducing a precomputation phase and the use of the homomorphic properties of \elgamal.
+This is something that \cmix{} is attempting to resolve by introducing a precomputation phase and the use of the homomorphic properties of \elgamal{}.
 
-\section{\cmix}
+\section{\cmix{}}
 \label{sec:cmix}
-\cmix is a new anonymity mix network\cite{cMix}. Just like any other mix network it aims to provide anonymity by hiding timing information of messages. This means hiding the difference in time between a message leaving the client and arriving at its destination.
+\cmix{} is a new anonymity mix network\cite{cMix}. Just like any other mix network it aims to provide anonymity by hiding timing information of messages. This means hiding the difference in time between a message leaving the client and arriving at its destination.
 
-A \cmix network is a fixed network consisting of $N$ nodes. This means there is a fixed network order and all clients know which computer represents each node in the network. It uses \elgamal encryption. And it relies heavily on the homomorphic properties of \elgamal.
+A \cmix{} network is a fixed network consisting of $N$ nodes. This means there is a fixed network order and all clients know which computer represents each node in the network. It uses \elgamal{} encryption and it relies heavily on the homomorphic properties of \elgamal{}.
 
-The \cmix network operates in 3 phases. Initialization, precomputation and realtime. During the initialization phase shared keys are set up between nodes and clients. This is the only time clients need to do public key operations as they have to establish a shared key with every node using Diffie-Hellman key exchange. This is why all communications between the nodes and from client to node have to be authenticated. One way to accomplish this is by using SSL connections for all communications within the network. Remember that the focus of this network is not encrypted traffic, recall that the last nodes sees all the plaintexts, but rather to hide timing information from an attacker.
+The \cmix{} network operates in three phases. Initialization, precomputation, and realtime. During the initialization phase, shared keys are set up between nodes and clients. This is the only time clients need to do public key operations as they have to establish a shared key with every node using Diffie-Hellman key exchange\cite{diffie1976new}. This is why all communication between the nodes and from client to node have to be authenticated. One way to accomplish this is by using SSL connections for all communications within the network. Remember that the focus of this network is not encrypted traffic, recall that the last nodes sees all the plaintexts, but rather to hide timing information from an attacker.
 
-The fact that \cmix minimizes the amount of public-key cryptographic operations for the client, makes it appealing for low power devices. This allows devices that cannot draw high amounts of power at all times due to battery constrains or NFC power limits, or mobile phones of which you want to conserve battery power, to use the \cmix network.
+The fact that \cmix{} minimizes the amount of public-key cryptographic operations for the client, makes it appealing for low power devices. This allows devices that cannot draw high amounts of power at all times due to battery constrains or NFC power limits to make use of this anonymity network with minimal impact on the design. It is also interesting for devices which want to save power instead of having a hard limit, such as mobile phones.
 
-Another advantage is that in theory the latency of the actual messages during the realtime phase should be lower than other mix networks. Again due to the lack of public-key cryptography during this phase.
-
-The fact that \cmix minimizes the amount of public-key cryptographic operations for the client, makes it more appealing for low power devices. So devices that cannot draw high amounts of power all the time due to battery constrains or NFC power limits. Mobile phones of which you want to conserve battery power.
-
-Another advantage is that in theory the latency of the actual messages during the realtime phase should be lower than other mix networks. Again due to the lack of public-key cryptography during this phase.
+Another advantage is that in theory the latency of the communication during the realtime phase is lower than other mix networks. Again due to the lack of public-key cryptography during the realtime phase.
 
 \subsection{Initialization phase}
 
-During the initialization phase the first node sends his public key to the next node, which multiplies his own public key with the value he received and sends it to the next. The last node sends it back to the first node which stores this final value and sends it on the next node which also stores this value. Now all nodes have the product of all the nodes' public keys.
+During the initialization phase the first node sends his public key ($d_1$) to the next node, which multiplies his own public key ($d_2$) with the value it received and sends the product of the two, to the next node. The last node also multiplies it's public key ($d_N$) and sends the product back to the first node which stores this final product ($E$) and forwards it to the next node which also stores the value of $E$. it keeps getting forwarded until it reaches the last node. Now all nodes have the shared network key $E$ as shown in \autoref{eq:E}.
 
-$$ E = \prod_N d_i $$
+\begin{equation}
+\label{eq:E}
+E = \prod_N d_i
+\end{equation}
 \vspace{-1em}
 where:
 \begin{itemize}[label=]
@@ -83,9 +82,12 @@ where:
 \item $E$ is the shared key between nodes
 \end{itemize}
 
-When a client connects, the client agrees upon a key using Diffie-Hellman key-exchange with each node. These keys will be used to send messages into the network, which will happen during the realtime phase
+When a client connects, the client agrees upon a key using Diffie-Hellman key-exchange with each node. Each client will store these keys in a vector $K_c$ as show in \autoref{eq:Kc} These keys will be used to send messages into the network, which will happen during the realtime phase. The Nodes will keep track of a similar vector per user to undo the shared key encryption done by the user in the realtime phase.
 
-$$ K_c = \{k_0, k_1,\ldots, k_{N-1}\} $$
+\begin{equation}
+\label{eq:Kc}
+K_c = \{k_0, k_1,\ldots, k_{N-1}\}
+\end{equation}
 \vspace{-1em}
 where:
 \begin{itemize}[label=]
@@ -93,15 +95,15 @@ where:
 \item $K_c$ The vector of Keys stored by the client
 \end{itemize}
 
-During any part of the protocol a client may send a message into the network. This is done by either multiplying the message with the multiplicative group shared keys $K_c$, or by adding the elliptic curve points shared keys $K_c$ to the message. Because the original paper only referenced multiplicative group \elgamal the rest of this description will refer to this operation as multiplication. But you can refer to the ``$\cdot$'' operation as a ``combine'' operation which either means multiplication or addition within their respective domains. This is also the name of the operation in the \cmix library created by this benchmark framework, together with its companion method ``uncombine'' which multiplies or adds the inverse in their respective domain.
+During any part of the protocol a client may send a message into the network. This is done by either multiplying the message with the multiplicative group shared keys $K_c$, see \autoref{eq:message}, or by adding the elliptic curve points shared keys $K_c$ to the message. Because the original paper only referenced multiplicative group \elgamal{} the rest of this description will refer to this operation as multiplication. But you can refer to the ``$\cdot$'' operation as a ``combine'' operation which either means multiplication or addition within their respective domains. This is also the name of the operation in the \cmix{} library created by this benchmark framework, together with its companion method ``uncombine'' which multiplies or adds the inverse in their respective domain.
  
 \begin{equation}
-Message = M \cdot k_0 \cdot k_1 \cdot ... \cdot k_{N-1} \label{form:message}
+Message = M \cdot k_{c_0} \cdot k_{c_1} \cdot ... \cdot k_{c_{N-1}} \label{eq:message}
 \end{equation}
 \vspace{-1em}
 where:
 \begin{itemize}[label=]
-\item $K_c$ The shared key between client and node $i$
+\item $K_{c_i}$ The shared key between client and node $i$
 \item $M$ The plaintext message
 \end{itemize}
 
@@ -110,79 +112,87 @@ where:
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=.9\linewidth]{images/basic_precomputation.pdf}
-	\caption{\cmix precomputation phase, image provided by Joeri de Ruiter from the \cmix paper \cite{cMix}}
+	\caption{\cmix{} precomputation phase, image provided by Joeri de Ruiter from the \cmix{} paper \cite{cMix}}
 	\label{fig:cmix_pre}
 \end{figure}
 
-The precomputation phase can be started as soon as $P$, the minimum number of messages to have accumulated in \NODE{0}, is known. The first node generates $P$ random values $R$ and $S$. $R$ is a vector of $P$ values as is $S$. When encrypting or multiplying these vectors the component-wise encryption or multiplication is implied. It also generates a random permutation function $\pi$ which can randomly shuffle $P$ messages. 
+The precomputation phase can be started as soon as $P$, the minimum number of messages to have accumulated in \NODE{0}, is known. The whole precomputation phase looks like \autoref{fig:cmix_pre}. The rest of this section will discuss the internals.
 
-The precomputation can be split up into 3 phases.
+In preparation of \emph{each} precomputation phase all the nodes generate 2 vectors of length $P$ random values called R and S. When encrypting or multiplying these vectors the component-wise encryption or multiplication is implied. The nodes also generate a random permutation function $\pi$ which randomly shuffles $P$ messages. 
 
-In the first phase the first node encrypts his $R$ with the key $E$ and sends it to the $node_{next}$. $Node_{next}$ also generates $P$ random values $R$ and $S$ and encrypts his $R$ with the key $E$. $Node_{next}$ multiplies it's encryption result with the values received by the first node, and by the homomorphic encryption property of \elgamal the result of this multiplication is the encryption of the multiplication of the two original $R$ vectors. It then sends the result of the multiplication to the next node which also encrypts his $R$ and multiplies it with his input and sends it on.
+The precomputation can be split up into three parts.
 
-$$ \mathcal{E}_E(R_0 \cdot R_1) = \mathcal{E}_E(R_0) \cdot \mathcal{E}_E(R_1)  $$
+In the first part of the precomputation phase, the first node encrypts his vector $R$ with the key $E$ and sends the encrypted result to $node_{next}$. $Node_{next}$ also encrypts his $R$ with the key $E$. $Node_{next}$ multiplies it's encryption result with the values it received from the first node, and by the homomorphic encryption property of \elgamal{} (\autoref{eq:homo}), the result of this multiplication is the encryption of the multiplication of the two original $R$ vectors. The node then sends the result of this multiplication to the next node which also encrypts his $R$ and multiplies it with his input and forwards the result again.
+
+\begin{equation}
+\label{eq:homo}
+\mathcal{E}_E(R_0 \cdot R_1) = \mathcal{E}_E(R_0) \cdot \mathcal{E}_E(R_1)
+\end{equation}
 \vspace{-1em}
 where:
 \begin{itemize}[label=]
-\item $\mathcal{E}_E$ is \elgamal encryption under key $E$
+\item $\mathcal{E}_E$ is \elgamal{} encryption under key $E$
 \item $R_i$ is the R vector of node $i$
 \end{itemize}
 
-Because of the circular nature of the \cmix network, where the last node is connected to the first node, whenever the result reaches the first node again phase 2 of the precomputation can start. The next phase is called the mix phase. Each node uses its permutation function $\pi$ on the incoming vector of values and multiplies that result with the encryption of $S$. It sends its result to the next node which will do the same. The last node produces the following result.
+Because of the circular nature of the \cmix{} network, the last node is connected to the first node, whenever the result reaches the first node again part two of the precomputation can start. The next part is called the mix part. Each node uses its permutation function $\pi$ on the incoming vector of values and multiplies that result with the encryption of $S$. It sends the result to the next node which will do the same. The last node produces the following end-result (\autoref{eq:EPiRS}).
 
 \begin{align}
-&\mathcal{E}_E( \nonumber \\
-&\hspace{1em}\pi_{N-1}( ... \nonumber  \\ 
+&\mathcal{E}_E( \label{eq:EPiRS} \\
+&\hspace{1em}\pi_{N-1}( \nonumber \\
+&\hspace{2em}... \nonumber  \\ 
 &\hspace{2em}\pi_{1}( \nonumber  \\
 &\hspace{3em}\pi_{0}(R_{0} \cdot ... \cdot R_{N-1}) \cdot S_0 \nonumber  \\
 &\hspace{2em}) \cdot S_1 \nonumber \\
-&\hspace{1em} ... ) \cdot S_{N-1} \label{form:EPiRS} \nonumber  \\
-&) 
+&\hspace{1em} ... ) \cdot S_{N-1} \nonumber  \\
+&) \nonumber
 \end{align}
 \vspace{-1em}
 where:
 \begin{itemize}[label=]
-\item $\mathcal{E}_E$ is \elgamal encryption under key $E$
+\item $\mathcal{E}_E$ is \elgamal{} encryption under key $E$
 \item $R_i$ is the R vector of node $i$
 \item $S_i$ is the S vector of node $i$
 \item $\pi_i$ is the permutation function of node $i$
 \end{itemize}
 
-The third part of the precomputation, is about decrypting this final value. Each node can perform part of the decryption with his private key part of $E$. Together with the encryption specific random value which is part of \elgamal this value is called the decryption share. With this decryption share you can remove your random permutation and the random value vectors $R$ and $S$ from the eventual realtime messages that will be generated in the realtime phase.
+The third part of the precomputation, is about decrypting this final value. Each node can perform part of the decryption with his private key part of $E$. Together with the encryption specific random value, which is part of \elgamal{}, this value is called the decryption share. With this decryption share you can remove your random permutation and the random value vectors $R$ and $S$ from the eventual realtime input message buffer that will be generated by the realtime phase.
 
 \subsection{Realtime phase}
 \label{sec:realpre}
 
-Whenever the first node received $P$ messages as described in formula \eqref{form:message}, and the precomputation has ended, the realtime phase can begin. The realtime phase can also be split into 3 different stages.
+Whenever the first node received $P$ messages as described in \autoref{eq:message}, and the precomputation phase has ended, the realtime phase can begin. The realtime phase can also be split into three different parts. The whole realtime phase looks like \autoref{fig:cmix_real}.
 
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=.9\linewidth]{images/basic_realtime.pdf}
-	\caption{\cmix realtime phase, image provided by Joeri de Ruiter from the \cmix paper \cite{cMix}}
+	\caption{\cmix{} realtime phase, image provided by Joeri de Ruiter from the \cmix{} paper \cite{cMix}}
 	\label{fig:cmix_real}
 \end{figure}
 
-In the first stage each node multiplies the message with the inverse of the key it agreed upon in the initialization phase. It then multiplies that result with $r_i$, where $i$ is the position of the message in the buffer, replacing $K_c$ with the corresponding value in $R$. The result is not yet permuted so the messages stay in the same place. The result gets passed to the next node which does the same steps. So for all the messages in the input we do.
+In the first part, the precomputation part of the realtime phase, each node multiplies the message with the inverse of the key it agreed upon with the sender of the message in the initialization phase. It then multiplies that result with $r_i$, which is the $i^{th}$ value of the random vector R. $i$ is the position index of the message in the buffer. So in fact it replaces $K_c$ with a value of $R$. The result is not yet permuted so the messages stay in the same place. The result gets passed to the next node which does the same steps. This means, for all the messages in the input we do the following (\autoref{eq:MR}).
 
-\[
-M_{out} = M_{in} \cdot K_{ci}^{-1} \cdot R_j
-\]
+\begin{equation}
+\label{eq:MR}
+M_{out} = M_{in} \cdot K_{c_j}^{-1} \cdot r_i
+\end{equation}
 \vspace{-1em}
 where:
 \begin{itemize}[label=]
 \item $M_{in}$ is one of the input messages
-\item $R_j$ the corresponding r of $M_{in}s$ position
-\item $K_{ci}$ Is the shared key of $M_{in}s$ position
+\item $r_i$ is the value of $R$ at $M_{in}s$ position
+\item $K_{c_j}$ Is the shared key of $M_{in}s$ position
 \end{itemize}
 
-The second phase is similar to the second phase of the precomputation, A node takes the message buffer, swaps around the messages according to its permutation function $\pi$ it then multiplies it by $S$, each node does this step.
+The second part of the realtime phase is similar to the second phase of the precomputation phase. A node takes the message buffer, swaps around the messages according to its permutation function $\pi$ it then multiplies it by $S$, each node does this and the computation is described in \autoref{eq:EPIRS}
 
 \begin{align}
-&M_{out} = \pi_{N-1}( \ldots \nonumber  \\ 
+&M_{out} = \pi_{N-1}( \label{eq:PiMRS} \\ 
+&\ldots \nonumber \\ 
 &\hspace{1em}\pi_{1}( \nonumber  \\
 &\hspace{2em}\pi_{0}(R_{0} \cdot \ldots \cdot R_{N-1} \cdot M_{in}) \cdot S_0 \nonumber  \\
 &\hspace{1em}) \cdot S_1 \nonumber \\
-& \ldots ) \cdot S_{N-1} \label{form:PiMRS} \nonumber  \\
+& \ldots ) \cdot S_{N-1} \nonumber
 \end{align}
 \vspace{-1em}
 where:
@@ -192,7 +202,7 @@ where:
 \item $S_i$ is the S vector of node $i$
 \end{itemize}
 
-The last phase is to remove the R and S vectors from the input. The last node stored decryption of formula \ref{form:EPiRS}. The last node calculates the inverse of this group element and multiplies it with the result of \ref{form:PiMRS}. This will cancel out all permuted R and S values, and the last node will be left with $M$.
+The last phase is to remove the $R$ and $S$ vectors from the input. The last node stored decryption of formula \autoref{eq:EPiRS}. The last node calculates the inverse of this group element and multiplies it with the result of \autoref{eq:PiMRS}. This will cancel out all permuted R and S values, and the last node will be left with $M$.
 
 Very critical to see is that during the realtime phase no public-key cryptography is being used, only multiplications. And the clients, outside of the initialization phase, never have to do any public-key cryptography. It is also possible for client and servers to update the shared keys $K_c$ using the old key as a seed. So in theory a client only needs to do the key agreement once per network.