Fehlerkorrekturen

docs/_bib/biblio.bib

@@ -7,6 +7,15 @@
 	note   = {Besserer Code durch eine professionelle Programmierumgebung - Open Source Press}
 }
 
+@Online{deepl,
+	author    = {DeepL GmbH},
+	title     = {{DeepL API Docs}},
+	url       = {https://www.deepl.com/docs-api},
+	note      = {Datum des Zugriffs: 21.10.2021},
+	timestamp = {2021-10-21}
+}
+
+
 @Online{sympy,
 	author    = {SymPy Development Team},
 	title     = {{SymPy Docs: Sympify}},

docs/_content/einleitung.tex

@@ -15,7 +15,7 @@ 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 \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} werden auf den Signal-Servern lediglich das Datum der Accounterstellung, wann sich der User das letzte Mal mit dem Server verbunden hat und temporär noch nicht zugestellte verschlüsselte Nachrichten gespeichert. Es wird nicht analysiert 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} werden auf den Signal-Servern lediglich das Datum der Accounterstellung, wann sich der User das letzte Mal mit dem Server verbunden hat und temporär noch nicht zugestellte verschlüsselte Nachrichten gespeichert. Es wird nicht analysiert 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. In den Abschnitten \ref{sec:einleitung_Signal_X3DH} bis \ref{sec:einleitung_Signal_Sesame} soll die Funktionsweise von Signals Verschlüsselung erläutert werden.
 
 \subsection{X3DH}
 \label{sec:einleitung_Signal_X3DH}
@@ -85,7 +85,7 @@ Das Herzstück des Algorithmus ist die \ac{KDF}. Dabei wird eine KDF mit einem S
 	\begin{center}
 		\includegraphics[width=0.5\textwidth]{KDFChain.png}
 		\caption{Visualisierung der KDF Kette \cite{signaldoubleratchetaufbau}
-			\label{fig:signaldoubleratchetaufbau}}
+			\label{fig:kdfchain}}
 	\end{center}
 \end{figure}
 
@@ -96,7 +96,7 @@ Bei dem Double Ratchet Algorithmus gibt es drei Ketten:
 	\item Empfangskette
 \end{itemize}
 
-Bei jeder ausgetauschten Nachricht werden neue Schlüssel ausgetauscht, womit der neu berechnete \ac{SK} als Schlüssel für die Stammkette verwendet wird. Dessen Ausgabe wird wiederum als Schlüssel für die Sende- und Empfangskette verwendet. Dieser Ablauf in der Stammkette wird als Diffi-Hellman Ratchet bezeichnet. Das Verfahren wird in Abbildung \ref{fig:signaldiffihellmanratchetablauf} dargestellt und verdeutlicht, wie mit dem zuletzt empfangenen öffentlichen Schlüssel (Bob) und dem neu generierten privaten Schlüssel (Alice) über das Diffi-Hellman Verfahren ein Schlüssel erzeugt wird. Bei dem Versand der Nachricht von Alice zu Bob wird der private Schlüssel des neu generierten Paares übermittelt und so kann Bob den gleichen Schlüssel berechnen. Die ständige Weiterentwicklung der beiden Ketten und die anschließende Nachrichtenver- oder Nachrichtenentschlüsselung mit deren Ausgaben wird als Symmetric-key Ratchet bezeichnet.
+Bei jeder Nachricht werden neue Schlüssel ausgetauscht, womit der neu berechnete \ac{SK} als Schlüssel für die Stammkette verwendet wird. Dessen Ausgabe wird wiederum als Schlüssel für die Sende- und Empfangskette verwendet. Dieser Ablauf in der Stammkette wird als Diffi-Hellman Ratchet bezeichnet. Das Verfahren wird in Abbildung \ref{fig:signaldiffihellmanratchetablauf} dargestellt und verdeutlicht, wie mit dem zuletzt empfangenen öffentlichen Schlüssel (Bob) und dem neu generierten privaten Schlüssel (Alice) über das Diffi-Hellman Verfahren ein Schlüssel erzeugt wird. Bei dem Versand der Nachricht von Alice zu Bob wird der private Schlüssel des neu generierten Paares übermittelt und so kann Bob den gleichen Schlüssel berechnen. 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.6\textwidth]{doubleRatchetDHRatchetSet2_1.png}
@@ -105,7 +105,7 @@ Bei jeder ausgetauschten Nachricht werden neue Schlüssel ausgetauscht, womit de
 	\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. Der Zusammenhang zwischen den den Ratchets wird in Abbildung \ref{fig:signaldiffihellmanratchetablauf} verdeutlicht. Darin ist zu sehen, wie die mit dem DH-Ratchet generierten Schlüssel der Wurzelkette übergeben und deren Ergebnis für die Symetric-key Ratchet in der Sende-/Empfangskette weiterverarbeitet wird.
+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 Nachrichtenversand wird der aktuelle eigene öffentliche DH-Schlüssel mitgeschickt. Der Zusammenhang zwischen den den Ratchets wird in Abbildung \ref{fig:signaldoubleratchetablauf} verdeutlicht. Darin ist zu sehen, wie die mit dem DH-Ratchet generierten Schlüssel der Wurzelkette übergeben und deren Ergebnis für die Symetric-key Ratchet in der Sende-/Empfangskette weiterverarbeitet wird.
 \begin{figure}[H]
 	\begin{center}
 		\includegraphics[width=0.8\textwidth]{doubleRatchetSet3_2.png}
@@ -139,7 +139,7 @@ Damit dieser ständige Wechsel von Schlüsseln, aber auch das Hinzufügen und En
 
 \subsubsection{Nachrichtenversand}
 \label{sec:einleitung_Signal_Sesame_Nachrichtenversand}
-Die zu sendende Nachricht wird verschlüsselt und mit der Empfänger*in \ac{IK}, sowie einer Liste der Geräte-IDs an den Server gesendet, wo Sie an den/die Empfänger*in 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 zugeschickt, um die Nachricht erneut zu verschicken.
+Die zu sendende Nachricht wird verschlüsselt und mit dem Empfangs-IK, sowie einer Liste der Geräte-IDs an den Server gesendet, wo Sie an das empfangende Gerät 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 zugeschickt, um die Nachricht erneut zu verschicken.
 
 \subsubsection{Nachrichtenempfang}
 \label{sec:einleitung_Signal_Sesame_Nachrichtenempfang}
@@ -223,7 +223,7 @@ Für die Erstellung eines Accounts wird eine Telefonnummer benötigt. Dabei ist
 	\end{itemize}
 	\item Sollte die Registrierung mit der Fehlermeldung \textit{Captcha invalid or required for verification} fehlschlagen, muss ein \ac{CAPTCHA} gelöst werden.
 	\begin{enumerate}
-		\item Aufruf Signal CAPTCHA Website \cite{signalcatpchagenerator} in einem Browser
+		\item Aufruf der Signal CAPTCHA Website \cite{signalcatpchagenerator} in einem Browser
 		\item das CAPTCHA lösen
 		\begin{figure}[H]
 			\begin{center}
@@ -232,7 +232,7 @@ Für die Erstellung eines Accounts wird eine Telefonnummer benötigt. Dabei ist
 					\label{fig:statictext}}
 			\end{center}
 		\end{figure}
-		\item Über die Konsole der Web-Entwickler Werkzeuge kann das Token ausgelesen werden. In den meisten gängigen Browsern ist diese per F12 aufrufbar. Es ist zu beachten, dass die Website keinen weiteren Inhalt hat und somit gänzlich leer ist.
+		\item Über die Konsole der Entwicklungswerkzeuge kann das Token ausgelesen werden. In den meisten gängigen Browsern sind diese per F12 aufrufbar. Es ist zu beachten, dass die Website keinen weiteren Inhalt hat und somit gänzlich leer ist.
 		\begin{figure}[H]
 			\begin{center}
 				\includegraphics[width=0.7\textwidth]{SignalCaptchaToken.png}

docs/_content/module.tex

@@ -10,9 +10,9 @@ In diesem Projekt wurde ein agiler Programmieransatz gewählt. Im Wochentakt wur
 
 \section{Echos und Statische Texte}
 \label{sec:mods_echos}
-Nach der Installation der Signal CLI aus Abschnitt \ref{sec:einleitung_SignalCLI} sollte die einfachste Art Bot-Antwort getestet werden. Ein beliebter Test für Kommunikationsanwendung stellt die echo-Funktion dar. Dabei bekommt die sendende Person oder Maschine den gleichen Nachrichteninhalt zurück, den sie abgeschickt hat. So kann ein \ac{PoC} realisiert werden. In diesem Projekt wurde ein ähnlicher Ansatz gewählt: der Bot sollte von einem User privat angeschrieben werden können oder die Nachrichten einer Test-Gruppe auslesen, um darauf zu reagieren. Sobald der Befehl \lstinline[breaklines=true]|.echo| geschickt wurde, sollte er ebenfalls mit echo antworten. Dabei ist das erste Grundprinzip für den Bot entstanden. Alle Nachrichten, die nicht mit exakt einem Punkt anfangen, sollen sofort verworfen werden, alle anderen werden auf ein Kommando ausgewertet. So muss nicht jede einzelne Nachricht analysiert werden und die Nutzer*innen haben nicht das Gefühl, dass der gesamte Schriftverkehr dokumentiert wird.
+Nach der Installation der Signal CLI aus Abschnitt \ref{sec:einleitung_SignalCLI} sollte die einfachste Art Bot-Antwort getestet werden. Ein beliebter Test für Kommunikationsanwendung stellt die echo-Funktion dar. Dabei bekommt die sendende Person oder Maschine den gleichen Nachrichteninhalt zurück, den sie abgeschickt hat. So kann ein \ac{PoC} realisiert werden. In diesem Projekt wurde ein ähnlicher Ansatz gewählt: der Bot sollte von einem User privat angeschrieben werden können oder die Nachrichten einer Test-Gruppe auslesen, um darauf zu reagieren. Sobald der Befehl \lstinline[breaklines=true]|.echo| geschickt wurde, sollte er ebenfalls mit \textit{echo} antworten. Dabei ist das erste Grundprinzip für den Bot entstanden. Alle Nachrichten, die nicht mit exakt einem Punkt anfangen, sollen sofort verworfen werden, alle anderen werden auf ein Kommando ausgewertet. So muss nicht jede einzelne Nachricht analysiert werden und die Nutzer*innen haben nicht das Gefühl, dass der gesamte Schriftverkehr dokumentiert wird.
 
-Auf dieser Basis wurden eine Menge einfacher Kommandos angelegt, die einen statischen String zurückgeben. Um den Code gering zu halten wurden Diese in einer Datei im \ac{JSON} Format ausgelagert, welche beim Start als Datentyp \ac{Dict} eingelesen wird. So kann bei einer Nachricht mit Punkt der Inhalt bis zur ersten Leertaste als Kommando interpretiert und als Schlüssel im sogenannten \textit{FUN\_DICT} gesucht werden, falls vorher kein anderes, komplexeres Kommando erkannt wurde. Falls die Nachricht mit einem Punkt beginnt, aber das Kommando nicht gefunden wurde, gibt der Bot eine Rückmeldung wie in Abbildung \ref{fig:statictext} zu sehen ist.
+Auf dieser Basis wurden eine Menge einfacher Kommandos angelegt, die einen statischen String zurückgeben. Um den Code gering zu halten wurden diese in einer Datei im \ac{JSON} Format ausgelagert, welche beim Start als Datentyp \ac{Dict} eingelesen wird. So kann bei einer Nachricht mit Punkt der Inhalt bis zur ersten Leertaste als Kommando interpretiert und als Schlüssel im sogenannten \lstinline|FUN_DICT| gesucht werden, falls vorher kein anderes, komplexeres Kommando erkannt wurde. Falls die Nachricht mit einem Punkt beginnt, aber das Kommando nicht gefunden wurde, gibt der Bot eine Rückmeldung wie in Abbildung \ref{fig:statictext} zu sehen ist.
 
 \begin{figure}[H]
 	\begin{center}
@@ -28,7 +28,7 @@ Zuletzt werden alle unbekannten Kommandos und Fehler durch einen Logger dokument
 
 \section{Programmierschnittstellen}
 \label{sec:apis}
-Eine \ac{API} ist ein offengelegter Teil eines Softwaresystems, der es einem anderen Programm ermöglicht bestimmte Ressourcen abzufragen. Die Nutzung verschiedener APIs sind für Bots äußerst wertvoll, da man mit wenigen Zeilen Code viel Funktionalität anbieten kann. Zudem wurde in diesem Projekt eine frühe Implementierung der APIs bevorzugt, um zu beobachten ob der Bot auf Langzeit ohne Einschränkungen mit webbasierten Diensten kommunizieren kann. Bis dato wurde die Dadjoke-API \cite{dadjokeapi}, sowie die Foolproof Decision-Making API \cite{yesnowtf} implementiert. Bei Beiden ist die Arbeitsweise vergleichbar. Bei den Befehlen \lstinline[breaklines=true]|.dadjoke| und \lstinline[breaklines=true]|.yesno| oder \lstinline[breaklines=true]|.yn| wird ein \ac{REST} Get-Request an den jeweiligen API-Server gestellt. Dafür wird die Requests-Bibliothek \cite{requests} genutzt. Die Antwort ist ein String im JSON-Format, welcher mithilfe der gleichnamigen Bibliothek in den Datentyp \ac{Dict} übersetzt werden kann. Dictionaries sind syntaktisch ähnlich zu JSON und bieten eine Möglichkeit an, um mit Schlüssel-Wert-Paaren zu arbeiten. Auf Basis dieses Dicts kann die Antwort des Bots in Form von Text und optionalem grafischem Anhang zusammengebaut und versendet werden. Da die Inhalte der Antworten bei jeder Anfrage individuell sind, muss die API bei jeden Bot-Command aufgerufen werden. In der Abbildung \ref{fig:yesno} wird die Funktionsweise des Commands \lstinline[breaklines=true]|.yesno| dargestellt.
+Eine \ac{API} ist ein offengelegter Teil eines Softwaresystems, der es einem anderen Programm ermöglicht bestimmte Ressourcen abzufragen. Die Nutzung verschiedener APIs sind für Bots äußerst wertvoll, da man mit wenigen Zeilen Code viel Funktionalität anbieten kann. Zudem wurde in diesem Projekt eine frühe Implementierung der APIs bevorzugt, um zu beobachten ob der Bot auf Langzeit ohne Einschränkungen mit webbasierten Diensten kommunizieren kann. Bis dato wurde die Dadjoke-API \cite{dadjokeapi}, die Foolproof Decision-Making API \cite{yesnowtf}, sowie die DeepL API \cite{deepl} implementiert. Bei allen APIs ist die Arbeitsweise vergleichbar. Bei den Befehlen \lstinline[breaklines=true]|.dadjoke|, \lstinline[breaklines=true]|.yesno| oder \lstinline[breaklines=true]|.yn| oder \lstinline[breaklines=true]|.deepl| wird eine \ac{REST} Get-Request an den jeweiligen API-Server gestellt. Dafür wird die Requests-Bibliothek \cite{requests} genutzt. Die Antwort ist ein String im JSON-Format, welcher mithilfe der gleichnamigen Bibliothek in den Datentyp \ac{Dict} übersetzt werden kann. Dictionaries sind syntaktisch ähnlich zu JSON und bieten eine Möglichkeit an, um mit Schlüssel-Wert-Paaren zu arbeiten. Auf Basis dieses Dicts kann die Antwort des Bots in Form von Text und optionalem grafischem Anhang zusammengebaut und versendet werden. Da die Inhalte der Antworten bei jeder Anfrage individuell sind, muss die API bei jeden Bot-Command aufgerufen werden. In der Abbildung \ref{fig:yesno} wird die Funktionsweise des Commands \lstinline[breaklines=true]|.yesno| dargestellt.
 
 \begin{figure}[H]
 	\begin{center}
@@ -161,7 +161,7 @@ Für die Initialisierung des Clients wird sowohl ein User, als auch ein Passwort
  	\end{center}
  \end{figure}
 
-In der Grafik \ref{fig:mqttpubsub} ist die für dieses Projekt umgesetzte Architektur zu sehen, um den Anwendungsfall zu testen. Dabei wird im Signalbot ein MQTT client erstellt, welche das topic \lstinline[breaklines=true]|test/temperature| subscribed. Wann immer Daten unter diesem topic gepublished werden, wird eine Nachricht mit dem Wert und topic an einen Signalaccount gesendet. Zu Kontrolle der Kommunikation werden mit dem Programm MQTT Explorer \cite{mqttexplorer} sämtliche topics subscribed, welche mit \lstinline[breaklines=true]|test/| beginnen. Dafür wird mit das Wildcard \cite{mqttwildcards} \lstinline[breaklines=true]|\#| verwendet, welches ein Platzhalter für sämtliche topics und sub-topics ist die in diesem Fall mit \lstinline[breaklines=true]|test/| beginnen.
+In der Grafik \ref{fig:mqttpubsub} ist die für dieses Projekt umgesetzte Architektur zu sehen, um den Anwendungsfall zu testen. Dabei wird im Signalbot ein MQTT client erstellt, welche das topic \lstinline[breaklines=true]|test/temperature| subscribed. Wann immer Daten unter diesem topic gepublished werden, wird eine Nachricht mit dem Wert und topic an einen Signalaccount gesendet. Zur Kontrolle der Kommunikation werden mit dem Programm MQTT Explorer \cite{mqttexplorer} sämtliche topics subscribed, welche mit \lstinline[breaklines=true]|test/| beginnen. Dafür wird mit die Wildcard \cite{mqttwildcards} \lstinline[breaklines=true]|#| verwendet, welche ein Platzhalter für sämtliche topics und sub-topics ist die in diesem Fall mit \lstinline[breaklines=true]|test/| beginnen.
 
 \begin{figure}[H]
 	\begin{center}
@@ -181,7 +181,7 @@ Wird eine Nachricht als Test über den MQTT Explorer an das im Signalbot abonier
 	\end{center}
 \end{figure}
 
-Dies stellt ein PoC dar und kann wie in \ref{sec:fazit_ausblick} erwähnt einen industriellen Einsatz bekommen. Dabei wäre die Benachrichtigung bei Events oder Grenzwertabweichungen per Signal, für eine schnelle Reaktio,n denkbar. Für dieses Projekt wurde der Status und die Temperatur eines 3D Druckers als Datenquelle \ref{fig:mqttsubrecv3dprinter} verwendet. Dadurch kann eine Benachrichtigung versendet werden, sobald ein Druck beendet wurde.
+Dies stellt einen PoC dar und kann wie in \ref{sec:fazit_ausblick} erwähnt einen industriellen Einsatz bekommen. Dabei wäre die Benachrichtigung bei Events oder Grenzwertabweichungen per Signal, für eine schnelle Reaktion denkbar. Für dieses Projekt wurde der Status und die Temperatur eines 3D Druckers als Datenquelle \ref{fig:mqttsubrecv3dprinter} verwendet. Dadurch kann eine Benachrichtigung versendet werden, sobald ein Druck beendet wurde.
 
 \begin{figure}[H]
 	\begin{center}

docs/main.bcf

@@ -2380,15 +2380,16 @@
     <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:citekey order="37">deepl</bcf:citekey>
+    <bcf:citekey order="38">requests</bcf:citekey>
+    <bcf:citekey order="39">bs</bcf:citekey>
+    <bcf:citekey order="40">schedule</bcf:citekey>
+    <bcf:citekey order="41">mqtt</bcf:citekey>
+    <bcf:citekey order="42">pahomqtt</bcf:citekey>
+    <bcf:citekey order="43">mqttexplorer</bcf:citekey>
+    <bcf:citekey order="44">mqttwildcards</bcf:citekey>
+    <bcf:citekey order="45">fourfours</bcf:citekey>
+    <bcf:citekey order="46">sympy</bcf:citekey>
   </bcf:section>
   <!-- SORTING TEMPLATES -->
   <bcf:sortingtemplate name="none">

docs/main.tex

@@ -195,41 +195,41 @@ sorting=none,
 	
 	\chapter*{Abkürzungsverzeichnis}
 	\addcontentsline{toc}{chapter}{Abkürzungsverzeichnis}
-	\begin{acronym}[PMSM]	% längste Abkürzung	
+	\begin{acronym}[CAPTCHA]	% längste Abkürzung	
+		\acro{AD}{Associated data}
 		\acro{API}{Application Programming Interface - Programmierschnittstelle}
 		%\acro{CSS}{Cascading Style Sheets}
 		\acro{CAPTCHA}{completely automated public Turing test to tell computers and humans apart}
 		\acro{CSV}{Comma/Character-separated values}
 		\acro{CLI}{Command Line Interface}
 		\acro{Dict}{Dictionary}
+		\acro{EK}{Ephemeral key}
 		%\acro{ERP}{Enterprise Resource Planning}
 		%\acro{GUI}{Graphical User Interface}
 		\acro{HTML}{Hypertext Markup Language}
 		\acro{HTTP}{Hypertext Transfer Protocol}
 		\acro{IDE}{Integrated Development Environment}
+		\acro{IK}{Identity key}
 		\acro{IMS}{IMS Messsysteme GmbH}
+		\acro{JRE}{Java Runtime Environment}
 		\acro{JSON}{JavaScript Object Notation}
 		\acro{JS}{JavaScript}
+		\acro{KDF}{Key-Derivation-Function}
 		\acro{M2M}{Machine to Machine}
 		\acro{MQTT}{Message Queuing Telemetry Transport}
+		\acro{OPK}{One-time prekey}
 		\acro{PDF}{Portable Document Format}
+		\acro{PK}{Public key}
 		\acro{PoC}{Proof of Concept}
 		\acro{REST}{Representational State Transfer}
 		\acro{Sesame}{Session Management for Asynchronous Message Encryption}
+		\acro{SK}{Secret key}
+		\acro{SPK}{Signed prekey}
 		\acro{SVG}{Scalable Vector Graphics}
 		\acro{td}{table data}
 		%\acro{TS}{TypeScript}
 		\acro{URL}{Uniform Resource Locator}
 		\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}}