diff options
Diffstat (limited to 'content')
| -rw-r--r-- | content/abstract.tex | 3 | ||||
| -rw-r--r-- | content/cmix.tex | 5 | ||||
| -rw-r--r-- | content/cmix_additions.tex | 2 | ||||
| -rw-r--r-- | content/conclusion.tex | 11 | ||||
| -rw-r--r-- | content/discussion.tex | 2 | ||||
| -rw-r--r-- | content/implementation.tex | 3 | ||||
| -rw-r--r-- | content/introduction.tex | 6 | ||||
| -rw-r--r-- | content/results.tex | 2 | ||||
| -rw-r--r-- | content/title.tex | 4 |
9 files changed, 27 insertions, 11 deletions
diff --git a/content/abstract.tex b/content/abstract.tex new file mode 100644 index 0000000..8284b56 --- /dev/null +++ b/content/abstract.tex @@ -0,0 +1,3 @@ +\begin{abstract} +Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus. Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu, consequat vitae, eleifend ac, enim. Aliquam lorem ante, dapibus in, viverra quis, feugiat a, tellus. Phasellus viverra nulla ut metus varius laoreet. Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi vel augue. Curabitur ullamcorper ultricies nisi. Nam eget dui. +\end{abstract}
\ No newline at end of file diff --git a/content/cmix.tex b/content/cmix.tex index 1597057..cc689fd 100644 --- a/content/cmix.tex +++ b/content/cmix.tex @@ -1,4 +1,5 @@ -\section{The \cmix network} +\section{The \cmix network} +\label{sec:cmix} This section will explain how the \cmix network works, it's starts by explaining what a mix network is. Then it explains what the \cmix mix network does differently and why. @@ -35,7 +36,7 @@ where: 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 be used during the realtime phase -$$ K_c = \{k_0, k_1, k_{N-1}\} $$ +$$ K_c = \{k_0, k_1,\ldots, k_{N-1}\} $$ \vspace{-1em} where: \begin{itemize}[label=] diff --git a/content/cmix_additions.tex b/content/cmix_additions.tex index 2443d19..e2c2ee5 100644 --- a/content/cmix_additions.tex +++ b/content/cmix_additions.tex @@ -1,5 +1,5 @@ \section{\cmix additions} - +\label{sec:cmixaddtions} So the base protocol still has some issues, thankfully these issues can be addressed at the cost of some speed and clarity. Because it would not be safe to use \cmix in the wild without these attack mitigations we implemented the extra messages needed. This makes for a more realistic benchmark. \subsection{Tagging attack} diff --git a/content/conclusion.tex b/content/conclusion.tex index 94c6701..5718746 100644 --- a/content/conclusion.tex +++ b/content/conclusion.tex @@ -1 +1,10 @@ -\section{conclusion}
\ No newline at end of file +\section{conclusion} +\label{sec:conclusion} +The big picture shows using elliptic curve for \cmix can be very beneficial. Especially in the realtime phase of the protocol. And I've shown that there is room for optimization of the the protocol implementation itself. These optimizations could even make it perform better in the precomputation phase as well. + +So in general using elliptic curve for \cmix shows promise. However there is more research to be done. Writing optimized backends for both algorithms and rerunning the tests to see if the differences still hold, is one of them. This is one of the fundamental things that need to be checked in further research. The goal of this research was feasibility, and this research shows just that. Now somebody with knowledge of writing fast and constant time cryptography implementations can pickup the topic of writing specialized backends and retest the algorithm. + +Another point to be taken into consideration is that this is the happy flow of the protocol. Checks like the tagging attack mitigation talked about in section \ref{sec:tagging} are implemented in a ``null'' fashion. Meaning the functions are in place and are being called but the implementation just returns a ``null'' byte as hash of the things it supposed to hash. Therefore the hash checking code is not in place. This was a deliberate choice, as these checks would not meaningfully affect the timings. The hashing algorithm scales linearly with the input size and would be the same over the 2 protocols. and checking it would also scale linearly with the input. Therefore it would be a constant time addition which would differ with a factor 8 between the 2 algorithms. In fact it would only pollute the timing results of the other cryptographic operations. However the protocol therefore needs some work to incorporate the hash checking where necessary. Therefore complying to the protocol standard. + + + diff --git a/content/discussion.tex b/content/discussion.tex index 44a7377..b2a2f85 100644 --- a/content/discussion.tex +++ b/content/discussion.tex @@ -1,5 +1,5 @@ \section{Discussion} - +\label{sec:discussion} \newcommand{\ec}[0]{\emph{ec}\xspace} \newcommand{\mg}[0]{\emph{mg}\xspace} diff --git a/content/implementation.tex b/content/implementation.tex index 3188d65..4fe06d8 100644 --- a/content/implementation.tex +++ b/content/implementation.tex @@ -1,4 +1,5 @@ \section{Implementation} +\label{sec:implementation} A large part of this research is actually making an implementation of the protocol in such a way that it; @@ -8,7 +9,7 @@ A large part of this research is actually making an implementation of the protoc \item Allows back-ends to be comparably benchmarked. \end{itemize} -The following section will talk about some implementation specific things, to talk about how I achieved those goals or why something might need some attention for future research. For more information on where to find the implementation see \ref{app:impl} +The following section will talk about some implementation specific things, to talk about how I achieved those goals or why something might need some attention in future research. For more information on where to find the implementation see appendix \ref{app:impl} \subsection{ElGamal in Cyclic Group and Elliptic Curve} diff --git a/content/introduction.tex b/content/introduction.tex index ac26833..aa1ec2a 100644 --- a/content/introduction.tex +++ b/content/introduction.tex @@ -1 +1,5 @@ -\section{Introduction}
\ No newline at end of file +\section{Introduction} + +Showing that one piece of software is faster than another is somewhat of an art. Trying to keep as many of the variables the same while varying the one you are interested in is not easy. Especially when the implementations are not of the same algorithm. This is the case for the \cmix mix network. The only condition for the underlying cryptography is that it is ElGamal based. This means that both multiplicative groups and elliptic curves are valid implementations. This makes benchmarking the fundamental performance differences between these two difficult. This paper and companion framework implementation focuses on providing a fair comparison by between the two, by providing a common interface. + +Section \ref{sec:cmix} will talk about the \cmix network and how it works and why it works with ElGamal. Followed by \ref{sec:implementation}; which talks about some implementation specific things. Section \ref{sec:cmixaddtions} will talk about some flaws in the original \cmix protocol and discusses the fix to them. Then we talk about the results in section \ref{sec:results}, followed by the discussion of the results in section \ref{sec:discussion}. Final thought and further research ideas are in the conclusion section \ref{sec:conclusion}.
\ No newline at end of file diff --git a/content/results.tex b/content/results.tex index abf8093..821886a 100644 --- a/content/results.tex +++ b/content/results.tex @@ -1,5 +1,5 @@ \section{Results} - +\label{sec:results} So the raw results presented in appendix \ref{app-tables} were obtained by running 3 nodes and 500 clients on the same computer. The clients and nodes operated in the way you would normally see a \cmix setup. All connections, either from node to node or client to node, are TCP connections encrypted using TLS. Latency is off course negligible because all the participants are running on the same computer but the goal is not to measure network latency. Rather we want to know if there is a benefit in using elliptic curve as apposed to multiplicative group ElGamal. diff --git a/content/title.tex b/content/title.tex index 57ad054..5986056 100644 --- a/content/title.tex +++ b/content/title.tex @@ -18,9 +18,7 @@ } \date{\today} % Leave empty to omit a date \renewcommand{\maketitlehookd}{% -\begin{abstract} -\noindent -\end{abstract} +\include{content/abstract} } %---------------------------------------------------------------------------------------- |