summaryrefslogtreecommitdiff
path: root/content/conclusion.tex
diff options
context:
space:
mode:
authorDennis Brentjes <d.brentjes@gmail.com>2017-05-28 23:26:54 +0200
committerDennis Brentjes <d.brentjes@gmail.com>2017-05-28 23:27:25 +0200
commitdc7a8acf380ed8b3567bf9f8b51f3b15d61b602f (patch)
tree2db7e1a3079c14787303434195946a115d2bb463 /content/conclusion.tex
parent610b3f96ec31ee6192d46767dedae9d9efaedf9b (diff)
downloadthesis-dc7a8acf380ed8b3567bf9f8b51f3b15d61b602f.tar.gz
thesis-dc7a8acf380ed8b3567bf9f8b51f3b15d61b602f.tar.bz2
thesis-dc7a8acf380ed8b3567bf9f8b51f3b15d61b602f.zip
Adds a discussion and introduction and a lorem ipsum abstract.
Diffstat (limited to 'content/conclusion.tex')
-rw-r--r--content/conclusion.tex11
1 files changed, 10 insertions, 1 deletions
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.
+
+
+