Fix typos in assignment

4 files changed, 21 insertions, 21 deletions

diff --git a/doc/class-assignment/idee/gewaehlte_implementation.tex b/doc/class-assignment/idee/gewaehlte_implementation.tex
index 38f5b5c..c41a763 100644
--- a/doc/class-assignment/idee/gewaehlte_implementation.tex
+++ b/doc/class-assignment/idee/gewaehlte_implementation.tex
@@ -1,15 +1,15 @@
 \subsection{Gewählte Implementation}
-Im anbetracht existierender Dateiverifizierungsprogrammen wie Androids dm-verity und mein vorheriges, ähnliches Projekt \href{https://github.com/linux-immutability-tools/FsGuard}{FsGuard}.
+In Anbetracht existierender Dateiverifizierungsprogramme wie Androids dm-verity und mein vorheriges, ähnliches Projekt \href{https://github.com/linux-immutability-tools/FsGuard}{FsGuard}.
 \\
-Für die Implementation habe ich die Blockverifizierung ausgewählt, da sie durch Multithreading sehr schnell sein kann, aber auch neue Datein bemerkt, welches die Per-Datei Verifizierung nicht gewährleistet.
+Für die Implementation habe ich die Blockverifizierung ausgewählt, da sie durch Multithreading sehr schnell sein kann, aber auch neue Dateien bemerkt, welche die Per-Datei-Verifizierung nicht gewährleistet.
 \\
-Um die Hashes zu Speichern wird ein eigenes Partitionsschema benutzt, welches alle Metadaten und die Datenbank beinhaltet. Der minisign öffentliche Schlüssel kann durch mehrere Methoden gespeichert werden, wie einer Textdatei oder einem gerät welches über USB-Serial den Schlüssel übergibt.
+Um die Hashes zu speichern, wird ein eigenes Partitionsschema benutzt, welches alle Metadaten und die Datenbank beinhaltet. Der minisign öffentliche Schlüssel kann durch mehrere Methoden gespeichert werden, wie einer Textdatei oder einem Gerät, welches über USB-Serial den Schlüssel übergibt.
 \\
-Weitere Eintscheidungen für die Implementation sind:
+Weitere Entscheidungen für die Implementation sind:
 \begin{itemize}
 \item Programmiersprache: go\\
-  go ist mir vertraut und memory safe, welches für die Sicherheit des Programmes eine große Rolle spielt.
+  go ist mir vertraut und Memory Safe, welches für die Sicherheit des Programmes eine große Rolle spielt.
 \item Datenbank: bbolt\\
-  bbolt ist eine Datenbank welche direkt in go geschrieben wurde und somit ein Robusteren API als sqlite hat, zudem ist bbolt unter einer richtigen lizens lizensiert und wirkt moderner.
+  bbolt ist eine Datenbank, welche direkt in go geschrieben wurde und somit eine robustere API als sqlite hat; zudem ist bbolt unter einer richtigen Lizenz lizenziert und wirkt moderner.
 \end{itemize}
   
diff --git a/doc/class-assignment/idee/hashquellen.tex b/doc/class-assignment/idee/hashquellen.tex
index 5d6e3c1..130d06b 100644
--- a/doc/class-assignment/idee/hashquellen.tex
+++ b/doc/class-assignment/idee/hashquellen.tex
@@ -1,21 +1,21 @@
 \subsection{Hash Quellen}
 Wie bereits gesagt, braucht das Verifizierungsprogramm eine vertraute Quelle für die korrekten Hashes.
-Hier gibt es auch verschiedene Lösungsansätze, was jedoch alle gemeinsam haben ist, dass sie eine Quelle und eine sichere Methode um diese Quelle zu verifizieren brauchen.
+Hier gibt es auch verschiedene Lösungsansätze, was jedoch alle gemeinsam haben ist, dass sie eine Quelle und eine sichere Methode, um diese Quelle zu verifizieren, brauchen.
 \\
-Für die Quellen gibt es viele verschieden möglichkeiten, bei der Entwicklung von fsverify hatte ich die Wahl auf zwei möglichkeiten begrenzt, da beide sehr einfach zu implementieren sind, und dadurch die Verifizierung der Quellen auch einfach ist.
+Für die Quellen gibt es viele verschiedene Möglichkeiten; bei der Entwicklung von fsverify hatte ich die Wahl auf zwei Möglichkeiten begrenzt, da beide sehr einfach zu implementieren sind und dadurch die Verifizierung der Quellen auch einfach ist.
 \begin{description}
 \item[Externe Partition]
-  Hier wird eine Datenbank an Hashes zusammen mit allen Metadaten in eine extra Partition geschrieben, diese Partition kann auf ein Externes medium geschrieben werden, und nur dann angeschlossen sein, wenn das System die Verizifizierung durchführt.
-  Jedoch braucht dies entweder eine seperate Partition auf der Festplatte, wodurch die nutzbare Speicherkapazität sich verringert, oder ein externes Medium, welches nicht immer vorhanden ist.
+  Hier wird eine Datenbank an Hashes zusammen mit allen Metadaten in eine extra Partition geschrieben; diese Partition kann auf ein externes Medium geschrieben werden und nur dann angeschlossen sein, wenn das System die Verifizierung durchführt.
+  Jedoch braucht dies entweder eine separate Partition auf der Festplatte, wodurch die nutzbare Speicherkapazität sich verringert, oder ein externes Medium, welches nicht immer vorhanden ist.
 \item[Einfache Datei]
-  Hier wird die Datenbank einfach in einem Ort gespeichert, auf die das Program während der Verifizierung zugreifen kann. Dies ist sehr einfach zu implementieren und benötigt keine externen Partitionen oder Speichermedien. Das Problem ist es jedoch, die Datei an einem ort zu speichern, bei der man nicht unverifizierte Dateisysteme anhängen muss oder ungeschützt ohne schreibschutz offen ist.
+  Hier wird die Datenbank einfach in einem Ort gespeichert, auf den das Programm während der Verifizierung zugreifen kann. Dies ist sehr einfach zu implementieren und benötigt keine externen Partitionen oder Speichermedien. Das Problem ist es jedoch, die Datei an einem Ort zu speichern, bei der man nicht unverifizierte Dateisysteme anhängen muss oder ungeschützt ohne Schreibschutz offen ist.
 \end{description}
 \pagebreak
-Um die Quelle zu schützen beziehungsweise zu Verifizieren, gibt es zwei Methoden:
+Um die Quelle zu schützen beziehungsweise zu verifizieren, gibt es zwei Methoden:
 \begin{description}
 \item[Kryptographische Verifizierung]
-  Die Entwickler des Betriebssystems müssen hierbei bei dem aufsetzen des Verifizierungsprogramms die Hash Quelle Kryptographisch mit ihren privaten Schlüsseln signieren (zum Beispiel mit GnuPG oder Minisgin), das Verifizierungsprogramm erhält den öffentlischen Schlüssel der Entwickler, die Signatur und die Quelle, wodurch es anhand der Signatur verifizieren kann, dass die Quelle von den Entwicklern stammt und nicht modifiziert wurde.\\
+    Die Entwickler des Betriebssystems müssen hierbei bei dem Aufsetzen des Verifizierungsprogramms die Hash Quelle kryptografisch mit ihren privaten Schlüsseln signieren (zum Beispiel mit GnuPG oder Minisgin), das Verifizierungsprogramm erhält den öffentlichen Schlüssel der Entwickler, die Signatur und die Quelle, wodurch es anhand der Signatur verifizieren kann, dass die Quelle von den Entwicklern stammt und nicht modifiziert wurde.\\
   Hierbei ist das größte Problem, dass der öffentliche Schlüssel gut geschützt werden muss, damit die Signatur und Schlüssel nicht mit der eines Attackers ersetzt werden kann.
 \item[Verschlüsselung]
-  Die Quelle ist mit einem zufällig generierten Schlüssel verschlüsselt, welcher in dem Quellcode des Verifizierungsprogrammes geschrieben wird, um somit den Schlüssel direkt im Programm zu speichern. Dadurch können keine Schlüssel ersetzt werden, jedoch ist es immer möglich, den Schlüssel aus dem Programm zu extrahieren, ohne überhaupt auf das System zugreifen zu müssen, da man das Betriebssystem selber installieren kann. Sobald der Schlüssel bekannt ist, kann die Datei einfach verschlüsselt und ohne Probleme modifiziert werden.
+  Die Quelle ist mit einem zufällig generierten Schlüssel verschlüsselt, welcher in den Quellcode des Verifizierungsprogramms geschrieben wird, um somit den Schlüssel direkt im Programm zu speichern. Dadurch können keine Schlüssel ersetzt werden, jedoch ist es immer möglich, den Schlüssel aus dem Programm zu extrahieren, ohne überhaupt auf das System zugreifen zu müssen, da man das Betriebssystem selber installieren kann. Sobald der Schlüssel bekannt ist, kann die Datei einfach verschlüsselt und ohne Probleme modifiziert werden.
 \end{description}
diff --git a/doc/class-assignment/idee/idee.tex b/doc/class-assignment/idee/idee.tex
index e8c0092..717ca72 100644
--- a/doc/class-assignment/idee/idee.tex
+++ b/doc/class-assignment/idee/idee.tex
@@ -1,9 +1,9 @@
-Die Idee einer Dateisystem verifizierung ist nichts neues, oft wird sie in embedded geräten oder handys implementiert, wo die sicherheit und integrität des systems von großer bedeutung ist.
-Jedoch ist sie bei Desktop betriebssystemen wie Windows, MacOS oder Linux Distributionen nicht sehr herkömmlich. Dies liegt meißt daran, dass eine effektive verifizierung des Dateisystems sich darauf verlässt, dass das Dateisystem sich nicht über zeit verändert, welches man bei Desktop-Betriebssystemen nicht gewährleisten kann, da Programme oft direkt in den Root des Betriebssystems schreiben (/usr in *nix, C:/Program Files in windows).
+Die Idee einer Dateisystemverifizierung ist nichts Neues; oft wird sie in embedded Geräten oder Handys implementiert, wo die Sicherheit und Integrität des Systems von großer Bedeutung sind.
+Jedoch ist sie bei Desktop-Betriebssystemen wie Windows, macOS oder Linux Distributionen nicht sehr herkömmlich. Dies liegt meist daran, dass eine effektive Verifizierung des Dateisystems sich darauf verlässt, dass das Dateisystem sich nicht über Zeit verändert, welches man bei Desktop-Betriebssystemen nicht gewährleisten kann, da Programme oft direkt in den Root des Betriebssystems schreiben (/usr in *nix, C:/Program Files in Windows).
 \\
-Mittlerweile gibt es jedoch in der Linux-welt eine neue art von Distribution, die sogenannten 'Immutable' Distributionen, welche sich darin unterscheiden, dass der Root schreibgeschützt ist, oder wie bei NixOS oder Gnu GUIX garnicht erst richtig existiert. Dadurch können Programme nur direkt in den Homeordner des Nutzers installiert werden, und das eigentliche System bleibt original bestanden.
+Mittlerweile gibt es jedoch in der Linux-Welt eine neue Art von Distribution, die sogenannten 'Immutable' Distributionen, welche sich darin unterscheiden, dass der Root schreibgeschützt ist oder wie bei NixOS oder Gnu GUIX gar nicht erst richtig existiert. Dadurch können Programme nur direkt in den Homeordner des Nutzers installiert werden, und das eigentliche System bleibt original bestanden.
 
-Hierdurch wird Dateisystem-verifizierung möglich, da der originale zustand sich nie ändern wird, kann ein Programm ohne probleme verizieren, dass sich nichts verändert hat.
+Hierdurch wird Dateisystem-Verifizierung möglich, da der originale Zustand sich nie ändern wird, kann ein Programm ohne Probleme die Partition verifizieren, dass sich nichts verändert hat.
 
 \input{idee/implementierungen}
 \input{idee/hashquellen}
diff --git a/doc/class-assignment/idee/implementierungen.tex b/doc/class-assignment/idee/implementierungen.tex
index a7a4db3..cdee8f2 100644
--- a/doc/class-assignment/idee/implementierungen.tex
+++ b/doc/class-assignment/idee/implementierungen.tex
@@ -4,11 +4,11 @@ Für die Verifizierung eines Dateisystems gibt es verschiedene Methoden:
 \item[Per-Datei verifizierung]
   Bei der Per-Datei Verifizierung wird der Hash von jeder Datei die verifiziert werden soll mit einem vorbestimmten, vertrauten, Hash verglichen, falls der Hash übereinstimmt ist Datei unmodifiziert, wenn sie jedoch abweichen, ist die Datei modifiziert und kann nicht vertraut werden.
 \item[Festplattenverifizierung]
-  Hier wird ein Hash von der ganzen Festplatte oder Partition mit einem vorgegebenen Wert verglichen. Im vergleich zu der Per-Datei verifizierung werden hier auch neue Dateien erkannt, welche eine Per-Datei verifizierung ignoriert hätte. Jedoch kann dies auch erheblich langsamer sein, da die ganze Partition, welche sehr groß werden kann, in einem Thread gehasht wird.
+  Hier wird ein Hash von der ganzen Festplatte oder Partition mit einem vorgegebenen Wert verglichen. Im Vergleich zu der Per-Datei-Verifizierung werden hier auch neue Dateien erkannt, welche eine Per-Datei-Verifizierung ignoriert hätte. Jedoch kann dies auch erheblich langsamer sein, da die ganze Partition, welche sehr groß werden kann, in einem Thread gehasht wird.
 \item[Blockverifizierung]
-  Dies ist ähnlich zu der Festplattenverifizierung, jedoch werden hier nur einzelne Blöcke gehasht und verifiziert, dies ermöglicht es, die Verifizierung durch Multithreading zu beschleunigen, während man weiterhin die ganze Festplatte/Partition verifiziert.
+  Dies ist ähnlich zu der Festplattenverifizierung, jedoch werden hier nur einzelne Blöcke gehasht und verifiziert. Dies ermöglicht es, die Verifizierung durch Multithreading zu beschleunigen, während man weiterhin die ganze Festplatte/Partition verifiziert.
 \end{description}
-Alle drei arten der Verifizierung haben eine Sache gemeinsam, sie brauchen eine vertraute quelle von der sie den korrekten Hash für eine Datei/Partition/Block lesen können.
+Alle drei Arten der Verifizierung haben eine Sache gemeinsam, sie brauchen eine vertraute quelle, von der sie den korrekten Hash für eine Datei/Partition/Block lesen können.
 %%% Local Variables:
 %%% mode: LaTeX
 %%% TeX-master: "../fsverify.tex"