Updated documentation

docs-de/bfh.cls

@@ -43,7 +43,7 @@
 \RequirePackage{aeguill}
 %\RequirePackage{underscore}
 \RequirePackage{ctable}
-\RequirePackage[english]{babel}
+\RequirePackage[english,ngerman]{babel}
 
 \RequirePackage{tabularx}
 \RequirePackage{wrapfig}
@@ -113,8 +113,8 @@
             %Angaben zum Dokument
             \begin{vfill}
                 \begin{tabularx}{\textwidth}{lX}
-                \textsf{Author} & \@author\\ 
-                \textsf{Tutor}  & \@tutor\\
+                \textsf{Autor} & \@author\\ 
+                \textsf{Betreuer}  & \@tutor\\
 %                \textsf{Expert} & \textsf\DozentA\\
 %                \textsf{Studiengang} & \textsf{\Studiengang}\vspace{5pt}\\
 %                \textsf{Autoren} & \textsf\AutorA\\ 
@@ -123,7 +123,7 @@
 %                                & \textsf\DozentB\vspace{5pt}\\
 %                \textsf{Experten} & \textsf\ExpertA\\
 %                                  & \textsf\ExpertB\vspace{5pt}\\
-                \textsf{Date} & \textsf{\@date}\vspace{5pt}\\
+                \textsf{Datum} & \textsf{\@date}\vspace{5pt}\\
 %                &\\
 %                &\\
 %                \multicolumn{2}{p{\columnwidth-\tabcolsep}}{\textsf{\input{titlepage/titlepage_info}}}\\

docs-de/bibliography.bib

@@ -4,7 +4,7 @@
   publisher = {Bitmessage Wiki},
   urldate = {2015-04-24},
   author = {Warren, Jonathan 'Atheros' and Coe, Jonathan},
-  note = {\url{https://bitmessage.org/wiki/Protocol_specification}},
+  note = {\\ \url{https://bitmessage.org/wiki/Protocol_specification}},
   year = {2015},
 }
 
@@ -14,16 +14,26 @@
   publisher = {Bitmessage Wiki},
   urldate = {2015-05-22},
   author = {Coe, Jonathan},
-  note = {\url{https://bitmessage.org/wiki/Scalability_through_Prefix_Filtering}},
+  note = {\\ \url{https://bitmessage.org/wiki/Scalability_through_Prefix_Filtering}},
   year = {2015},
 }
 
+@ONLINE{forum:msg7871,
+  url = {https://bitmessage.org/forum/index.php?topic=3725.msg7871},
+  title = {A tweak to enable trust-less BM relay servers (and lightweight mobile clients)},
+  publisher = {Bitmessage Forum},
+  urldate = {2015-05-25},
+  author = {Dan Smith},
+  note = {\\ \url{https://bitmessage.org/forum/index.php?topic=3725.msg7871}},
+  year = {2014}
+}
+
 @ONLINE{issue:112,
   url = {https://github.com/Bitmessage/PyBitmessage/issues/112},
   title = {BigInv and ping/pong},
   publisher = {github.com},
   urldate = {2015-05-22},
   author = {Warren, Jonathan 'Atheros' and ISibbol},
-  note = {\url{https://github.com/Bitmessage/PyBitmessage/issues/112}},
+  note = {\\ \url{https://github.com/Bitmessage/PyBitmessage/issues/112}},
   year = {2015},
 }

docs-de/seminar.tex

@@ -18,17 +18,33 @@
 
   \tableofcontents
 
-  \listoffigures
-
-  \newpage
-  \section*{Abstract}
-
-  Sogar mit Verschlüsselung offenbaren wir viel über uns in den Metadaten welche wir unwissentlich produzieren. Bitmessage verhindert dies indem es eine Nachricht so verteilt, dass der eigentliche Empfänger daraus nicht erraten werden kann.
-
   \newpage
   % Section basics
   \input{basics}
 
+  \newpage
+  \section{PyBitmessage}
+
+  PyBitmessage ist der Standard Bitmessage Client und, wie der Name andeutet, in Python implementiert. Der Client bietet zwar alle Funktionen von Bitmessage, die User Experience ist allerdings nicht ganz optimal. Insbesondere lassen sich Nachrichten nicht in Ordner verschieben oder mit Labels versehen.
+
+  \begin{figure}[h]
+  \centering
+  \includegraphics[width=0.8\textwidth]{images/PyBitmessage-Inbox.png}
+  \caption[PyBitmessage: Inbox]{Der Posteingang von PyBitmessage.}
+  \label{fig:inbox}
+  \end{figure}
+
+  Der Client ist ausserdem ziemlich langsam im Berechnen des Proof of Work. Auf einem MacBook Pro von 2012 kann es durchaus einige Minuten dauern bis eine Nachricht gesendet werden kann.
+
+%  \begin{figure}[h]
+  \begin{wrapfigure}{r}{0.5\textwidth}
+  \centering
+  \includegraphics[width=0.5\textwidth]{images/PyBitmessage-Send.png}
+  \caption[PyBitmessage: Senden]{Eine neue Nachricht erfassen.}
+  \label{fig:inbox}
+  \end{wrapfigure}
+
+  Man braucht natürlich nur schon die Idee des Protokolls, um auf die Idee zu kommen Meldungen an mehrere Empfänger gleichzeitig zu senden. Dies geht so, dass die Adresse selbst in einen privaten Schlüssel umgewandelt wird und so zum \textit{entschlüsseln} der Broadcasts benutzt werden kann. Entsprechend kann man beim Erfassen einer Nachricht wählen ob sie an einen bestimmten Empfänger gehen soll, oder an alle, die unsere Broadcasts abonniert haben. Jeder, der die Adresse kennt kann dabei allerdings ihre Broadcasts lesen.
 
   \newpage
   \section{Protokoll}
@@ -196,34 +212,30 @@ $$ d = \frac{2^{64}}{n (l + \frac{t l}{2^{16}})} $$
 
   Perfect Forward Secrecy scheint nicht praktikabel implementierbar zu sein, da man dazu vor dem Senden der eigentlichen Nachricht Informationen austauschen muss. Diese brauchten wiederum Proof of Work um das Netzwerk zu schützen, was für den Sender die doppelte Arbeit bedeutet und dreimal solange dauert um sie zu senden --- das heisst, falls beide Clients online sind. Der Austausch von Nachrichten würde so gut wie unmöglich wenn beide Benutzer nur sporadisch online sind.
 
+  \subsection{Mobile Client}
+
+  Es gibt zwar inzwischen einen Client für Android,\footnote{Bitseal: \url{https://play.google.com/store/apps/details?id=com.github.bitseal}} dieser benötigt jedoch sehr viel Traffic, der Proof of Work dauert ewig und die Batterie hält nicht sehr lange.
+
+  In PyBitmessage gibt es die Option, den Empfänger eindeutig identifizierbar zu machen. Dies würde es einem Server erlauben nur die relevanten Meldungen weiterzuleiten. Zwar gibt man dabei seine Anonymität auf, aber das ist immer noch besser als die Ansätze der E-Mail-Relays, wo der private Schlüssel gleich beim Server liegt.
+
+  Ein Ansatz, der Anonymität trotz unterstützendem Server erlaubt, schlug Dan Smith vor.\cite{forum:msg7871} Dabei wird ein drittes Schlüsselpaar generiert, mit dem der String "IDENTIFICATION" und einige zufällige Bytes verschlüsselt wird. Der Relay-Server muss dabei den privaten Identifikationsschlüssel erhalten --- soweit muss man ihm also noch vertrauen. Wenn er also mit Hilfe des Identifikationsschlüssels den Text "IDENTIFICATION" extrahieren kann, ist die Meldung für einem bestimmt und wird weitergeleitet.
+
+  Der Proof of Work schliesslich lässt sich sehr einfach auf einem Server erledigen. Mit einer optimierten Implementation sollte er aber auf einem modernen Smartphone in vernünftiger Zeit machbar sein. Die Geräte haben inzwischen oftmals mehr als vier Prozessorkerne und einen dedizierten Grafikchip, der sich ausgezeichnet zum parallelen Berechnen von Hashes eignet.
+
   \newpage
   \section{Diskussion}
 
   Anonymität hat ihren Preis. Bei Bitmessage ist es Traffic, Speicherplatz und Rechenpower. Bei E-Mail ist es Vertrauen. Wenn wir unserem E-Mail-Provider nicht vertrauen können (wer kann das?), ist Bitmessage eine alternative, wenn auch nicht vollständig ausgereift.
 
-  TODO
+  Ich finde die Idee eines Trustless-Protokolls\footnote{Ein Protokoll, das kein Vertrauen benötigt.} und Peer-To-Peer Netzwerke die üblicherweise soche Protokolle verwenden äusserst interessant. Zu Beginn war das Internet ein riesiges Netzwerk gleichberechtigter Teilnehmer, aber heutzutage scheint alles zu Google oder Facebook zu führen. P2P und Trustless-Protokolle geben uns ein Stück dieser Freiheit zurück welche in der Cloud verlorengegangen ist.
 
-  .
-
-  .
-
-  .
-
-  .
-
-  .
-
-  .
+  Dass es nun einen P2P E-Mail-Ersatz gibt finde ich absolut grossartig.
 
+  Ja, es skaliert nicht so gut wie E-Mail. Aber dank Proof of Work denke ich, dass wir kein mit E-Mail vergleichbares Spam-Problem haben, was den Traffic schon mal gut halbiert. Falls Bitmessage E-Mail jemals ersetzt, würde ein grosser Teil des E-Mail-Verkehrs wohl eher durch Instant-Messaging ersetzt. Vor allem Firmenintern, wo eine eigene Infrastruktur aufgebaut werden kann, muss nicht unbedingt Bitmessage verwendet werden.
 
+  \newpage
   \bibliographystyle{plain}
   \bibliography{bibliography}
-
-  \appendix
-  \addcontentsline{toc}{section}{Appendix}
-  \section*{Appendix}
-  \renewcommand{\thesubsection}{\Alph{subsection}}
-
-  \subsection{TODO}
+  \listoffigures
 
 \end{document}

docs/seminar.tex

@@ -29,6 +29,10 @@
   % Section basics
   \input{basics}
 
+  \newpage
+  \section{PyBitmessage}
+
+  TODO
 
   \newpage
   \section{Protocol}
@@ -217,6 +221,12 @@ $$ d = \frac{2^{64}}{n (l + \frac{t l}{2^{16}})} $$
 
   Anonymity has its price. With Bitmessage it's traffic and disk space, with E-Mail it's trust. If we can't trust our e-mail providers (who can?), Bitmessage is a very interesting alternative, albeit not fully matured.
 
+  I find the idea of trustless protocols, and peer to peer networks that typically leverage them, intriguing. In the beginning, the internet was a huge network of equal participants, but nowadays it all seems to end up at google or facebook. P2P and trustless protocols give us back some of that freedom that got lost in the cloud.
+
+  That there is now a p2p e-mail replacement I think is absolutely amazing.
+
+  Yes, it doen't scale as well as e-mail. But as I don't think we'll have the spamming problem with Bitmessage, thanks to Proof of Work, it might not have to.
+
   TODO
 
   .