Kapitel Sesame, Double Ratchet erweitert; Quellen hinzugefügt die belegen wie...

Kapitel Sesame, Double Ratchet erweitert; Quellen hinzugefügt die belegen wie papatastisch signal ist; Soweit aufgefallen die Kapitel Genderneutral geschrieben

docs/_bib/biblio.bib

@@ -88,6 +88,105 @@
 	timestamp = {2021-09-23}
 }
 
+
+@Online{signaldprotocolinwhatsapp,
+	author    = {moxie0},
+	title     = {{WhatsApp's Signal Protocol integration is now complete}},
+	url       = {https://signal.org/blog/whatsapp-complete/},
+	note      = {Datum des Zugriffs: 20.10.2021},
+	timestamp = {2021-10-20}
+}
+
+@Online{whatsappalternativen,
+author    = {Cornelia Möhring - heise online},
+title     = {{WhatsApp-Alternativen: Welche Messenger gibt es? }},
+url       = {https://www.heise.de/tipps-tricks/WhatsApp-Alternativen-Welche-Messenger-gibt-es-3976153.html/},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+
+@Online{kasperskysignal,
+author    = {Ivan Kwiatkowski - kaspersky daily},
+title     = {{Signal – der sichere Messenger für alle, die Wert auf mehr Datenschutz legen}},
+url       = {https://www.kaspersky.de/blog/signal-privacy-security/27011/},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+
+@Online{signaldoubleratchetaufbau,
+author    = {Signal Technology Foundation},
+title     = {{Double Ratchet Aufbau}},
+url       = {https://signal.org/docs/specifications/doubleratchet/Set0_1.png},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+
+@Online{signaldiffihellmanratchetablauf,
+author    = {Signal Technology Foundation},
+title     = {{Diffi-Hellman Ratchet Ablauf}},
+url       = {https://signal.org/docs/specifications/doubleratchet/Set2_1.png},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+
+@Online{signaldoubleratchetablauf,
+author    = {Signal Technology Foundation},
+title     = {{Double Ratchet Ablauf}},
+url       = {https://signal.org/docs/specifications/doubleratchet/Set3_2.png},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+@Online{signaldoubleratchetablaufmehrfachversand,
+author    = {Signal Technology Foundation},
+title     = {{Double Ratchet Ablauf}},
+url       = {https://signal.org/docs/specifications/doubleratchet/Set3_3.png},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+
+
+@Online{signaldoubleratchet,
+author    = {Signal Technology Foundation},
+title     = {{Double Ratchet Spezifikation}},
+url       = {https://signal.org/docs/specifications/doubleratchet/},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+
+@Booklet{diffihellman,
+title  = {Applied Cryptography: Protocols, Algorithms and Source Code in C, 20th Anniversary Edition},
+author = {Bruce Schneider},
+year   = {2015},
+publisher = {Wiley},
+isbn = {9781119096726},
+note   = {". . .the best introduction to cryptography I've ever seen. . . .The book the National Security Agency wanted never to be published. . . ." -Wired Magazine}
+}
+
+@Online{signalx3dhaufbau,
+author    = {Signal Technology Foundation},
+title     = {{X3DH Aufbau}},
+url       = {https://signal.org/docs/specifications/x3dh/X3DH.png},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+
+@Online{signalx3dh,
+author    = {Signal Technology Foundation},
+title     = {{X3DH Spezifikation}},
+url       = {https://signal.org/docs/specifications/x3dh/},
+note      = {Datum des Zugriffs: 20.10.2021},
+timestamp = {2021-10-20}
+}
+
+
+@Online{signalxeddsa,
+	author    = {Signal Technology Foundation},
+	title     = {{The XEdDSA and VXEdDSA Signature Schemes}},
+	url       = {https://signal.org/docs/specifications/xeddsa/},
+	note      = {Datum des Zugriffs: 20.10.2021},
+	timestamp = {2021-10-20}
+}
+
 @Online{nytinterview,
 	author    = {Nicole Perlroth, Katie Benner - The New York Times},
 	title     = {{Subpoenas and Gag Orders Show Government Overreach, Tech Companies Argue}},

docs/_content/einleitung.tex

@@ -15,40 +15,40 @@ Ziel des Projektes ist es einen Bot für die Nachrichtenapp Signal zu realisiere
 
 \section{Signal} % Das Ganze hier vllt Kapitel 2
 \label{sec:einleitung_Signal}
-Signal ist ein kostenfreier quelloffener Messenger der gleichnamigen Stiftung und besticht durch Sicherheit, sowie Datenschutz. Die Signal Technology Foundation \cite{signalfoundationhome} ist eine gemeinnützige US-Amerikanische Stiftung, welche 2013 gegründet wurde. Diese finanziert sich durch Spenden. Dementsprechend verdient Signal im Gegensatz zu beispielsweise Whatsapp kein Geld durch den Einsatz von Werbung oder mit dem Verkauf von Daten der Nutzer*innen. Die Kommunikation wird nach aktuellstem Stand der Technik QUELLE sicher Ende-zu-Ende verschlüsselt und nur auf den Endgeräten gespeichert. Nach Aussage des Gründers Moxie Marlinspike in der New York Times \cite{nytinterview} wird auf den Signal Servern gerade einmal das Datum der Accounterstellung gespeichert und wann sich der User das letzte Mal mit dem Server verbunden hat. Es wird nicht gespeichert Wer mit Wem kommuniziert oder was Inhalt der Gespräche ist. Daher stellt es kein Problem dar, dass für die Server Anbieter wie Amazon oder Google verwendet werden. 
+Signal ist ein kostenfreier quelloffener Messenger der gleichnamigen Stiftung und besticht durch Sicherheit, sowie Datenschutz. Die Signal Technology Foundation \cite{signalfoundationhome} ist eine gemeinnützige US-Amerikanische Stiftung, welche 2013 gegründet wurde. Diese finanziert sich durch Spenden. Dementsprechend verdient Signal im Gegensatz zu beispielsweise Whatsapp kein Geld durch den Einsatz von Werbung oder mit dem Verkauf von Daten der Nutzer*innen. Die Kommunikation wird nach aktuellstem Stand der Technik \cite{signaldprotocolinwhatsapp} \cite{whatsappalternativen} \cite{kasperskysignal} sicher Ende-zu-Ende verschlüsselt und nur auf den Endgeräten gespeichert. Nach Aussage des Gründers Moxie Marlinspike in der New York Times \cite{nytinterview} wird auf den Signal Servern gerade einmal das Datum der Accounterstellung gespeichert, wann sich der User das letzte Mal mit dem Server verbunden hat und temporär noch nicht zugestellte verschlüsselte Nachrichten. Es wird nicht gespeichert Wer mit Wem kommuniziert oder was Inhalt der Gespräche ist. Daher stellt es kein Problem dar, dass für die Server Anbieter wie Amazon oder Google verwendet werden. 
 
 \subsection{X3DH}
 \label{sec:einleitung_Signal_X3DH}
-\ac{X3DH} steht für die dreifache Ausführung des Diffi-Hellman Algorithmus mit verschiedenen Schlüsselkombinationen, um schlussendlich ein Shared Secret zu berechnen. Für alle verwendeten Schlüsselpaare werden entweder die Funktionen X25519 oder X448 verwendet, welche beide auf eliptischen Kurven basieren. Dabei werden Schlüsselpaare  von den in \ref{sec:einleitung_Signal_XEdDSA_VXEdDSA} beschriebenen Verfahren verwendet.
+\ac{X3DH} steht für die dreifache Ausführung des Diffi-Hellman Algorithmus mit verschiedenen Schlüsselkombinationen \cite{signalx3dh}, um schlussendlich ein \ac{SK} zu berechnen. Für alle verwendeten Schlüsselpaare werden entweder die Funktionen X25519 oder X448 verwendet, welche beide auf elliptischen Kurven basieren. Dabei werden Schlüsselpaare  von den in \ref{sec:einleitung_Signal_XEdDSA_VXEdDSA} beschriebenen Verfahren verwendet.
 
 \subsubsection{Diffi-Hellman Schlüsselaustausch}
 \label{sec:einleitung_Signal_X3DH_Diffi_Hellman_Algorithmus}
-Der Algorithmus ist nach den Erfindern Whitfield Diffie und Martin Hellman benannt. Dieser wurde 1976 veröffentlicht und ermöglicht es einen Schlüssel zwischen zwei Gesprächsteilnehmern auszutauschen ohne diesen zu übermitteln. Für das Beispiel werden die teilnehmenden Personen Alice und Bob genannt.\\
+Der Algorithmus ist nach den Erfindern Whitfield Diffie und Martin Hellman benannt \cite{diffihellman}. Dieser wurde 1976 veröffentlicht und ermöglicht es einen Schlüssel zwischen zwei Gesprächsteilnehmer*innen auszutauschen ohne diesen zu übermitteln. Für das Beispiel werden die teilnehmenden Personen Alice und Bob genannt.\\
 \begin{enumerate}
 	\item Für den Schlüsselaustausch einigen sich beide auf eine große Primzahl $g$ und eine maximale Schlüssellänge $n$, welche aktuell üblicherweise entweder 2048 Bit oder besser 4096 Bit groß ist. Diese Zahlen müssen nicht geheimgehalten werden.
-	\item Anschließend wählen beide Teilnehmer eine Zahl (a für Alice, b für Bob), welche zwischen 0 und $n$ liegt. Die ist der private Schlüssel und wird von Beiden geheim gehalten.
+	\item Anschließend wählen beide Teilnehmer*innen eine Zahl (a für Alice, b für Bob), welche zwischen 0 und $n$ liegt. Die ist der private Schlüssel und wird von Beiden geheim gehalten.
 	\item Der öffentliche Schlüssel wird mit $A = g^a mod(n)$ für Alice und $B = g^b mod(n)$ für Bob berechnet.
-	\item Die öffentlichen Schlüssel($A, B$) geben die beidem Teilnehmer dem jeweils anderen bekannt.
+	\item Die öffentlichen Schlüssel($A, B$) geben die beidem Teilnehmer*innen dem jeweils anderen bekannt.
 	\item Zuletzt berechnen Beide jeweils mit $B^a mod(n)$ beziehungsweise $A^b mod(n)$ den gemeinsamen Schlüssel.
 \end{enumerate}
 
 
 \subsubsection{Erster Gesprächsaufbau}
 \label{sec:einleitung_Signal_X3DH_ErsterGesprächsaufbau}
-Damit eine Kommunikation selbst dann aufgebaut werden kann, wenn Bob offline ist, hinterlegt er bei der Registrierung auf dem Signal Server seinen Identitätsschlüssel, einen signierten und mehrere Einmalschlüssel.  Sollten diese nahezu aufgebraucht sein, wird Bob aufgefordert neue Einmalschlüssel auf dem Server zu hinterlegen.
+Damit eine Kommunikation selbst dann aufgebaut werden kann, wenn Bob offline ist, hinterlegt er bei der Registrierung auf dem Signal Server seinen \ac{IK}, einen \ac{SPK} und mehrere \ac{OPK}.  Sollten diese nahezu aufgebraucht sein, wird Bob aufgefordert neue Einmalschlüssel auf dem Server zu hinterlegen. Für den Kommunikationsaufbau erzeugt Alice im Vorfeld einen \ac{EK}, welcher für jede weitere Nachricht neu generiert wird.
 
 Bei dem \ac{X3DH} werden die folgenden Schlüssel beim ersten Gesprächsaufbau von Alice mit Bob eingesetzt: 
 \begin{itemize}
-	\item IK\textsubscript{A} (Alices Identitätsschlüssel)
-	\item EK\textsubscript{A} (Alices Einmalschlüssel)
-	\item IK\textsubscript{B} (Bobs Identitätsschlüssel)
-	\item SPK\textsubscript{B} (Bobs hinterlegter, signierter Schlüssel)
-	\item OPK\textsubscript{B} (Bobs hinterlegter Einmalschlüssel)
+	\item \ac{IK}\textsubscript{A} (Alices Identitätsschlüssel)
+	\item \ac{EK}\textsubscript{A} (Alices Einmalschlüssel)
+	\item \ac{IK}\textsubscript{B} (Bobs Identitätsschlüssel)
+	\item \ac{SPK}\textsubscript{B} (Bobs hinterlegter, signierter Schlüssel)
+	\item \ac{OPK}\textsubscript{B} (Bobs hinterlegter Einmalschlüssel)
 \end{itemize}
 
 Die drei Diffi-Hellman Ausführungen sind:
 \begin{enumerate}
-	\item IK\textsubscript{A} und SPK\textsubscript{B}
+	\item \ac{IK}\textsubscript{A} und SPK\textsubscript{B}
 	\item EK\textsubscript{A} und IK\textsubscript{B}
 	\item EK\textsubscript{A} und SPK\textsubscript{B}
 \end{enumerate}
@@ -57,46 +57,97 @@ Sollte optional ein Einmalschlüssel von Bob in dem Schlüsselset enthalten sein
 \begin{figure}[H]
 	\begin{center}
 		\includegraphics[width=0.5\textwidth]{X3DH.png}
-		\caption{Visualisierung des X3DH Quelle: https://signal.org/docs/specifications/x3dh/ Abgerufen am 19.10.2021
+		\caption{Visualisierung des X3DH \cite{signalx3dhaufbau}
 			\label{fig:statictext}}
 	\end{center}
 \end{figure}
-Nach der Berechnung löscht Alice ihren privaten Einmalschlüssel und berechnet eine Bytesequenz AD aus dem IK\textsubscript{A} und IK\textsubscript{B}, welche optional mit weiteren Informationen wie dem Accountnamen ergänzt wird. 
+Nach der Berechnung löscht Alice ihren privaten Einmalschlüssel und berechnet eine Bytesequenz \ac{AD} aus dem IK\textsubscript{A} und IK\textsubscript{B}, welche optional mit weiteren Informationen wie dem Accountnamen ergänzt wird. 
 Anschließend kann Alice die erste Nachricht an Bob senden und damit das Gespräch beginnen. \\
 Diese Nachricht enthält:
 \begin{itemize}
-	\item IK\textsubscript{A}
-	\item EK\textsubscript{A}
-	\item welcher EK\textsubscript{B} verwendet wurde
-	\item die mit dem SK verschlüsselte Nachricht und dem AD als Anhang	
+	\item \ac{IK}\textsubscript{A}
+	\item \ac{EK}\textsubscript{A}
+	\item welcher \ac{EK}\textsubscript{B} verwendet wurde
+	\item die mit dem \ac{SK} verschlüsselte Nachricht und dem \ac{AD} als Anhang	
 \end{itemize}
-Abhängig von den Sicherheitseinstellungen nutzt Alice den SK oder davon abgeleitete Schlüssel um Nachrichten an Bob zu senden.
+Abhängig von den Sicherheitseinstellungen nutzt Alice den \ac{SK} oder davon abgeleitete Schlüssel um Nachrichten an Bob zu senden.
 
 \subsubsection{Empfang der ersten Nachricht}
 \label{sec:einleitung_Signal_X3DH_EmpfangDerEstenNachricht}
-Analog zu den Berechnungen die Alice für den SK durchgeführt hat, verwendet Bob die entsprechenden privaten Schlüssel und Alices öffentliche Schlüssel. Durch den Zusammenhang des Public-Private-Key Verfahrens erhält Bob den gleichen SK und kann damit die empfangene Nachricht entschlüsseln.
+Analog zu den Berechnungen die Alice für den \ac{SK} durchgeführt hat, verwendet Bob die entsprechenden privaten Schlüssel und Alices öffentliche Schlüssel. Durch den Zusammenhang des Public-Private-Key Verfahrens erhält Bob den gleichen \ac{SK} und kann damit die empfangene Nachricht entschlüsseln.
 
 \subsection{Double Ratchet}
 \label{sec:einleitung_Signal_Double_Ratchet}
-Der Algorithmus wird verwendet um Nachrichten verschlüsselt zwischen zwei Teilnehmer*innen auszutauschen.
+Der Algorithmus wird verwendet um Nachrichten verschlüsselt zwischen zwei Teilnehmer*innen auszutauschen \cite{signaldoubleratchet}. Dabei werden die Schlüssel aus den vorangegangenen Schlüsseln abgeleitet, so dass im Falle eines Leaks nur die Nachricht entschlüsselt werden kann, welche zu jenem geleakten Schlüssel gehört. Daraus können keine früheren oder nachfolgenden Nachrichten entschlüsselt oder die entsprechenden Schlüssel berechnet werden.
+
+Das Herzstück des Algorithmus ist die \ac{KDF}. Dabei wird eine KDF mit einem Schlüssel und Eingabedaten initialisiert und einer der Ausgabeschlüssel wird als KDF Schlüssel für die nächste KDF verwendet. So lässt sich von der Ausgabe nicht auf frühere Schlüssel schließen, selbst wenn die Eingabe bekannt ist und bei genügend Entropie in den Inputs, auch nicht auf zukünftige.
 \begin{figure}[H]
 	\begin{center}
 		\includegraphics[width=0.5\textwidth]{KDFChain.png}
-		\caption{Visualisierung der KDF Kette Quelle: https://signal.org/docs/specifications/doubleratchet/ Abgerufen am 19.10.2021
+		\caption{Visualisierung der KDF Kette \cite{signaldoubleratchetaufbau}
+			\label{fig:statictext}}
+	\end{center}
+\end{figure}
+
+Bei dem Double Ratchet Algorithmus gibt es drei Ketten:
+\begin{itemize}
+	\item Stammkette
+	\item Sendekette
+	\item Empfangskette
+\end{itemize}
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.6\textwidth]{doubleRatchetDHRatchetSet2_1.png}
+		\caption{Visualisierung des Diffi-Hellman Ratchet Ablauf \cite{signaldiffihellmanratchetablauf}
+			\label{fig:statictext}}
+	\end{center}
+\end{figure}
+
+Bei jeder ausgetauschen Nachricht werden neue Schlüssel ausgetauscht, womit der neu berechnete \ac{SK} als Schlüssel für die Stammkette verwendet wird. Dessen Ausgabe wird als Schlüssel für die Sende- und Empfangskette verwendet (Diffi-Hellman Ratchet). Die ständige Weiterentwicklung der beiden Ketten und die anschließende Nachrichtenver- oder Nachrichtenentschlüsselung mit deren Ausgaben wird als Symmetric-key Ratchet bezeichnet.
+
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.8\textwidth]{doubleRatchetSet3_2.png}
+		\caption{Visualisierung des Double Ratchet Ablauf \cite{signaldoubleratchetablauf}
+			\label{fig:statictext}}
+	\end{center}
+\end{figure}
+
+Der Double Ratchet ist die Hintereinanderschaltung des DH und des Symmetric-key Ratchets. Dabei wird vor jedem Nachrichtenversand ein neues Schlüsselpaar erzeugt und aus dem zuletzt erhaltenen öffentlichen Schlüssel und dem frisch erzeugten privaten Schlüssel mit dem Diffi-Hellman Ratchet ein neuer Schlüssel erzeugt, welcher anschließend für die Symmetric-key Ratchet verwendet wird. Bei jedem Nachrichten Versand wird der aktuelle eigene öffentliche DH-Schlüssel mit geschickt. 
+
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.8\textwidth]{doubleRatchetSet3_3.png}
+		\caption{Visualisierung des Double Ratchet Ablauf Mehrfachversand \cite{signaldoubleratchetablaufmehrfachversand}
 			\label{fig:statictext}}
 	\end{center}
 \end{figure}
 
+Werden mehrere Nachrichten hintereinander versendet, ohne dass eine Nachricht empfangen wurde, wird die Ausgabe des letzten Symmetric-key Ratchet Durchlaufs als Eingabeschlüssel für den Nächsten verwendet. So ändern sich die Schlüssel für jede gesendete Nachricht. 
+Da die Nachrichten auf der Empfänger*innen Seite analog durch die Empfängerkette laufen können diese Entschlüsselt werden.
+
+Da so eine starke Abhängigkeit zur richtigen Verarbeitungsreihenfolge entsteht wird bei jeder Nachricht angegeben wie viele Nachrichten in der vorigen Sendekette waren und welche Position die Nachricht in der aktuellen hat. Dies sorgt dafür, dass eine Anzahl vergangener Nachrichten auf dem Endgerät gespeichert werden, für den Fall dass Welche in der falschen Reihenfolge empfangen werden.
+
 \subsection{XEdDSA und VXEdDSA}
 \label{sec:einleitung_Signal_XEdDSA_VXEdDSA}
-Mit XEdSA beziehungsweise VXEdDSA sind die Diffi-Hellman Funktionen für eliptische Kurven X25519 und X448 gemeint. VXEdDSA ist eine Erweiterung von XEdDSA und sorgt dafür, dass es eine verifizierbar zufällige Funktion ist. Mit diesen Funktionen können Bytesequenzen signiert werden.\\
+Mit XEdSA beziehungsweise VXEdDSA \cite{signalxeddsa} sind die Diffi-Hellman Funktionen für eliptische Kurven X25519 und X448 gemeint. VXEdDSA ist eine Erweiterung von XEdDSA und sorgt dafür, dass es eine verifizierbar zufällige Funktion ist. Mit diesen Funktionen können Bytesequenzen signiert werden.\\
 Mit diesen digitalen Signaturen wird sichergestellt, dass die Absender jene sind, für die sie sich ausgeben. Dafür wird das Public-Private-Key Verfahren angewendet. In diesem Anwendungsfall werden die Nachrichten mit dem privaten Schlüssel des Absenders verschlüsselt und beim Empfänger mit dem öffentlichen Schlüssel des Absenders entschlüsselt. So wird der Absender verifiziert, da nur der Absender Zugriff auf seinen privaten Schlüssel hat.
 
 \subsection{Sesame}
 \label{sec:einleitung_Signal_Sesame}
-Mit Hilfe von asynchronen Schlüsselaustauschverfahren wie X3DH aus Abschnitt \ref{sec:einleitung_Signal_X3DH} können verschlüsselte Nachrichten versendet werden, auch wenn der Empfänger zu beginn der Unterhaltung offline ist. 
+Mit Hilfe von asynchronen Schlüsselaustauschverfahren wie X3DH aus Abschnitt \ref{sec:einleitung_Signal_X3DH} können verschlüsselte Nachrichten versendet werden, auch wenn der Empfänger (Bob) zu beginn der Unterhaltung offline ist. 
 Zudem wird der Schlüssel mit dem Double Ratchet Algorithmus aus Abschnitt \ref{sec:einleitung_Signal_Double_Ratchet} nach jeder Nachricht verändert. 
-Damit dieser ständige Wechsel von Schlüsseln, aber auch das Hinzufügen und Entfernen von Geräten zu Accounts, sowie das Einspielen von Backups funktioniert wird der Algorithmus Sesame verwendet.
+Damit dieser ständige Wechsel von Schlüsseln, aber auch das Hinzufügen und Entfernen von Geräten zu Accounts, sowie das Einspielen von Backups funktioniert wird der Algorithmus Sesame verwendet. Dieser regelt die Sitzungen, indem es immer eine aktive Sitzung pro Gerät gibt mit dem eine Kommunikation stattfindet und bei bedarf Neue erstellt oder Alte gelöscht werden. Sollte eine Nachricht in einer inaktiven Sitzung empfangen werden, so wird Diese zur aktiven Sitzung. Dadurch wird sichergestellt, dass die aktive Sitzung immer jene ist, mit der aktuell kommuniziert wird.
+
+\subsubsection{Nachrichtenversand}
+\label{sec:einleitung_Signal_Sesame_Nachrichtenversand}
+Die zu sendende Nachricht wird verschlüsselt und mit der Empfänger \ac{IK}, sowie einer Liste der Geräte-IDs an den Server gesendet, wo Sie an den Empfänger weiter geleitet wird. Dabei werden sämtliche relevanten User-IDs mit aktiver Sitzung adressiert. Sollte der Server die Nachricht ablehnen wird das sendende Gerät informiert und bekommt gegebenenfalls die aktuellen Daten zugschickt, um die Nachricht erneut zu verschicken.
+
+\subsubsection{Nachrichtenempfang}
+\label{sec:einleitung_Signal_Sesame_Nachrichtenempfang}
+Beim Empfang wird vom Server die verschlüsselte Nachricht, sowie UserID und GeräteID gesendet. Falls bisher noch keine Kommunikation mit dem Sender stattgefunden hat, werden die öffentlichen Schlüssel aus dem Nachrichten Header extrahiert und eine neue Sitzung mit den empfangenen Daten erstellt.
+Sollte bereits eine Sitzung existiert haben und diese inaktiv ist, so wird Sie wieder aktiviert. 
+
 
 \section{Signal-CLI}
 \label{sec:einleitung_SignalCLI}

docs/_content/module.tex

@@ -132,7 +132,7 @@ Mit dem Berechtigungssystem aus Abschnitt \ref{sec:mods_allowlist} wurde die Mö
 Unter \ac{M2M}-Kommunikation wird die automatische Kommunikation zwischen zwei Maschinen, meistens Computern, verstanden. Dies kann als 1 zu 1, 1 zu n oder auch n zu n Beziehung realisiert werden. Als Beispiel für eine M2M-Kommunikation wird eine \ac{MQTT} Schnittstelle implementiert. 
 
 MQTT ist ein weit verbreitetes Protokoll \cite{mqtt}, welches nicht für Echtzeitkommunikation, sondern für sporadische Statusmeldungen in Netzwerken geschaffen wurde bei denen der Datendurchsatz gering ist oder die Verbindung nicht konstant aufrechterhalten wird. Dadurch können stromsparende IoT-Lösungen realisiert werden, da keine konstante Internetverbindung notwendig ist. \\
-Bei MQTT kommunizieren Clients nicht direkt miteinander, sondern senden Ihre Daten an einen Server (Broker) und bekommen Daten vom Broker zugeschickt. Das Senden von Daten an den Broker wird "'publishen"' genannt. Diese werden einem "'topic"' zugeordnet und darauf können sich andere MQTT Clients "'subscriben"'. Beim subscriben bekommen die Clients die Daten vom Broker zugesendet, welche unter dem subscribten topic gepublished wurden. Dadurch kann die Kommunikation bidirektional oder unidirektional realisiert werden.
+Bei MQTT kommunizieren Clients nicht direkt miteinander, sondern senden Ihre Daten an einen Server (Broker) und bekommen Daten vom Broker zugeschickt. Das Senden von Daten an den Broker wird \lstinline|publishen| genannt. Diese werden einem \lstinline|topic| zugeordnet und darauf können sich andere MQTT Clients \lstinline|subscriben|. Beim subscriben bekommen die Clients die Daten vom Broker zugesendet, welche unter dem subscribten topic gepublished wurden. Dadurch kann die Kommunikation bidirektional oder unidirektional realisiert werden.
 
 Im Signalbot wir ein Client mit der Bibliothek \lstinline[breaklines=true]|paho.mqtt.client|\cite{pahomqtt}, Welche unter der EPL V1.0 Lizenz steht, erzeugt. Dieser Client läuft während der gesamten Laufzeit des Signalbots in einem eigenen Task. 
 

docs/main.bcf

@@ -2352,26 +2352,43 @@
     <bcf:citekey order="6">snowdensignaltweet</bcf:citekey>
     <bcf:citekey order="7">signaleucommission</bcf:citekey>
     <bcf:citekey order="8">signalfoundationhome</bcf:citekey>
-    <bcf:citekey order="9">nytinterview</bcf:citekey>
-    <bcf:citekey order="10">gitsignalcli</bcf:citekey>
-    <bcf:citekey order="11">snapcraftrustup</bcf:citekey>
-    <bcf:citekey order="12">gitlibsignalclient</bcf:citekey>
-    <bcf:citekey order="13">gitlibzkgroup</bcf:citekey>
-    <bcf:citekey order="14">gitsignalclibuilding</bcf:citekey>
-    <bcf:citekey order="15">signalcatpchagenerator</bcf:citekey>
-    <bcf:citekey order="16">ctsignalartikel</bcf:citekey>
-    <bcf:citekey order="17">gitsignalsystembus</bcf:citekey>
-    <bcf:citekey order="18">dadjokeapi</bcf:citekey>
-    <bcf:citekey order="19">yesnowtf</bcf:citekey>
-    <bcf:citekey order="20">requests</bcf:citekey>
-    <bcf:citekey order="21">bs</bcf:citekey>
-    <bcf:citekey order="22">schedule</bcf:citekey>
-    <bcf:citekey order="23">mqtt</bcf:citekey>
-    <bcf:citekey order="24">pahomqtt</bcf:citekey>
-    <bcf:citekey order="25">mqttexplorer</bcf:citekey>
-    <bcf:citekey order="26">mqttwildcards</bcf:citekey>
-    <bcf:citekey order="27">fourfours</bcf:citekey>
-    <bcf:citekey order="28">sympy</bcf:citekey>
+    <bcf:citekey order="9">signaldprotocolinwhatsapp</bcf:citekey>
+    <bcf:citekey order="10">whatsappalternativen</bcf:citekey>
+    <bcf:citekey order="11">kasperskysignal</bcf:citekey>
+    <bcf:citekey order="12">nytinterview</bcf:citekey>
+    <bcf:citekey order="13">signalx3dh</bcf:citekey>
+    <bcf:citekey order="14">diffihellman</bcf:citekey>
+    <bcf:citekey order="15">signalx3dhaufbau</bcf:citekey>
+    <bcf:citekey order="16">signalx3dhaufbau</bcf:citekey>
+    <bcf:citekey order="17">signaldoubleratchet</bcf:citekey>
+    <bcf:citekey order="18">signaldoubleratchetaufbau</bcf:citekey>
+    <bcf:citekey order="19">signaldoubleratchetaufbau</bcf:citekey>
+    <bcf:citekey order="20">signaldiffihellmanratchetablauf</bcf:citekey>
+    <bcf:citekey order="21">signaldiffihellmanratchetablauf</bcf:citekey>
+    <bcf:citekey order="22">signaldoubleratchetablauf</bcf:citekey>
+    <bcf:citekey order="23">signaldoubleratchetablauf</bcf:citekey>
+    <bcf:citekey order="24">signaldoubleratchetablaufmehrfachversand</bcf:citekey>
+    <bcf:citekey order="25">signaldoubleratchetablaufmehrfachversand</bcf:citekey>
+    <bcf:citekey order="26">signalxeddsa</bcf:citekey>
+    <bcf:citekey order="27">gitsignalcli</bcf:citekey>
+    <bcf:citekey order="28">snapcraftrustup</bcf:citekey>
+    <bcf:citekey order="29">gitlibsignalclient</bcf:citekey>
+    <bcf:citekey order="30">gitlibzkgroup</bcf:citekey>
+    <bcf:citekey order="31">gitsignalclibuilding</bcf:citekey>
+    <bcf:citekey order="32">signalcatpchagenerator</bcf:citekey>
+    <bcf:citekey order="33">ctsignalartikel</bcf:citekey>
+    <bcf:citekey order="34">gitsignalsystembus</bcf:citekey>
+    <bcf:citekey order="35">dadjokeapi</bcf:citekey>
+    <bcf:citekey order="36">yesnowtf</bcf:citekey>
+    <bcf:citekey order="37">requests</bcf:citekey>
+    <bcf:citekey order="38">bs</bcf:citekey>
+    <bcf:citekey order="39">schedule</bcf:citekey>
+    <bcf:citekey order="40">mqtt</bcf:citekey>
+    <bcf:citekey order="41">pahomqtt</bcf:citekey>
+    <bcf:citekey order="42">mqttexplorer</bcf:citekey>
+    <bcf:citekey order="43">mqttwildcards</bcf:citekey>
+    <bcf:citekey order="44">fourfours</bcf:citekey>
+    <bcf:citekey order="45">sympy</bcf:citekey>
   </bcf:section>
   <!-- SORTING TEMPLATES -->
   <bcf:sortingtemplate name="none">

docs/main.tex

@@ -223,6 +223,13 @@ sorting=none,
 		\acro{X3DH}{Extended Triple Diffie-Hellman}
 		\acro{KDF}{Key-Derivation-Function}
 		\acro{JRE}{Java Runtime Environment}
+		\acro{IK}{Identity key}
+		\acro{EK}{Ephemeral key}
+		\acro{SPK}{Signed prekey}
+		\acro{OPK}{One-time prekey}
+		\acro{PK}{Public key}
+		\acro{SK}{Secret key}
+		\acro{AD}{Associated data}
 	\end{acronym}
 	\renewcommand*{\acffont}[1]{\textit{#1}}
 
@@ -260,7 +267,7 @@ sorting=none,
 	% ANHANG ---------------------------------------------------------------------------------------------------
 	% ----------------------------------------------------------------------------------------------------------
 	
-	\begin{appendix}
-	\input{_content/anhang}
-	\end{appendix}
+	%\begin{appendix}
+	%\input{_content/anhang}
+	%\end{appendix}
 \end{document}
\ No newline at end of file