Der Weg einer Anfrage
- Eingang: Ein Ordner, rekursiv als Bytes gelesen - Windows Forms
- Orchestrierung: WCF-Service - WCF, .NET
- Parallel
- AES - CBC, aus der .NET-Bibliothek - .NET
- RC6 - Von Hand geschrieben, 20 Runden - C#
- XXTEA - Von Hand geschrieben, Feistel-Netzwerk - C#
- Ausgabe: Eine verschlüsselte Datei je Eingabe - SHA-512 vor und nach dem Durchgang
Überblick
Encryptix arbeitet mit ganzen Ordnern statt mit einzelnen Dateien. Sie wählen ein Verzeichnis, die Anwendung liest alles darin samt Unterordnern, und dann läuft eines von drei symmetrischen Verfahren über den gesamten Inhalt. Den verschlüsselten Baum, den entschlüsselten Baum und das Hash-Protokoll schreibt sie jeweils an einen Ort Ihrer Wahl.
Es sind drei Verfahren, weil nur eines davon fertig mitgeliefert wurde. AES ist die Implementierung aus der .NET-Bibliothek, wie sie jede vernünftige Anwendung verwenden würde. RC6 und XXTEA sind nach ihren Spezifikationen gebaut, und darin lag die eigentliche Arbeit: die Schlüsselexpansion, das Auffüllen der Blöcke, die Rotationen und der bewusste Ganzzahlüberlauf, auf dem XXTEA beruht.
Technologien
- Client
- Windows FormsC#
- Service
- WCF.NETC#
Architektur
Der Client liest den Ordner
Ein Ordnerdialog, dann ein rekursiver Durchlauf, der jede Datei unabhängig von der Endung als rohe Bytes liest und Name, Endung, Verzeichnis und Inhalt als einen Datensatz zusammenhält. Der Inhalt wird nirgends interpretiert, eine .txt und eine .exe nehmen also denselben Weg durch das Programm.
Ein Hintergrund-Task hält das Fenster reaktionsfähig
Windows Forms gibt der Anwendung einen einzigen Thread, und diesem Thread gehören die Steuerelemente. Würde ein großer Ordner auf ihm gelesen, fröre das Fenster ein, und mit ihm die Ladeanzeige, die währenddessen laufen soll. Das Lesen läuft deshalb als Task, und die Fortsetzung läuft wieder im Synchronisationskontext des Formulars, denn nur von dort aus dürfen die Schaltflächen erneut freigegeben werden.
Die Liste geht an den Service
Der Client ruft den WCF-Service über HTTP auf. Für diese Datenmenge mussten beide Seiten umkonfiguriert werden: Die Puffergrenzen stehen auf dem größten Wert, den ein int fassen kann, und der Übertragungsmodus ist von gepuffert auf gestreamt umgestellt, sodass nur der Nachrichtenkopf gepuffert wird und nicht die ganze Dateiliste. Das Zeitlimit liegt auf beiden Seiten bei zehn Minuten.
Der Service verschlüsselt, Datei für Datei
Der gewählte Algorithmus bekommt die Liste, den Schlüssel und - bei AES - den Initialisierungsvektor. RC6 und XXTEA arbeiten nur mit vollen Blöcken, deshalb füllt jedes der beiden Verfahren das Byte-Array auf seine Blockgröße auf und schreibt die ursprüngliche Länge in die ersten vier Bytes. So kann die Entschlüsselung die Auffüllung wieder abschneiden, statt raten zu müssen, wo die Datei endete.
Beide Enden werden gehasht
Neben jeder Datei liegt eine Textdatei mit vier SHA-512-Zeilen: vor dem Verschlüsseln, nach dem Verschlüsseln, vor dem Entschlüsseln, nach dem Entschlüsseln. Entscheidend sind die erste und die letzte, und sie müssen identisch sein. Darin besteht die ganze Integritätsprüfung, und wer die Textdatei öffnet, kann sie selbst nachvollziehen.
Was es kann
Ein ganzer Ordner auf einmal
Unterordner eingeschlossen, in beliebiger Tiefe. Der Ausgabebaum bildet den Eingabebaum nach. Die Struktur ergibt sich aus dem Pfad jeder Datei relativ zum Wurzelordner, nicht aus einem Mitzählen der Rekursion.
Drei Verfahren, ein Formular
AES mit einem Schlüssel aus 32 Zeichen und einem IV aus 16, RC6 und XXTEA mit Schlüsseln aus 16 Zeichen. Jedes hat sein eigenes Fenster, und jedes Feld wird geprüft, bevor irgendetwas geschrieben wird.
Der Beweis, dass nichts verloren ging
Der SHA-512 des Klartexts vor dem Verschlüsseln, verglichen mit dem SHA-512 des Klartexts nach dem Entschlüsseln. Stimmen beide überein, war der Hin- und Rückweg verlustfrei.
Sequenziell oder parallel
Beide Modi sind eingebaut, ein Kontrollkästchen schaltet zwischen ihnen um. Im parallelen Modus wird die Dateiliste auf eine parallele Schleife verteilt, und weil keine Datei von einer anderen abhängt, muss nichts gesperrt oder zusammengeführt werden. Was das bringt, zeigen die Ergebnisse unten.
Ein Fortschrittsbalken, der mit der Arbeit fertig wird
Während der Service arbeitet, richtet sich der Balken nach der Gesamtzahl der Bytes. Kehrt der eigentliche Aufruf zurück, wird der Balken über ein Cancellation Token sofort aufgefüllt, sodass er dem Lauf folgt und mit ihm fertig wird, nicht erst danach.
Der Dateibaum vorab
Eine Baumansicht von allem, was geladen wurde, vollständig ausgeklappt, damit Sie vor dem Start prüfen können, was verschlüsselt wird.
Ergebnisse
| Modus | Dateien | Verschlüsselung (s) | Entschlüsselung (s) |
|---|---|---|---|
| Sequenziell | 150 | 68,91 | 70,13 |
| Parallel | 150 | 44,16 | 40,39 |
Dieselben 150 Dateien, derselbe RC6-Schlüssel, dieselben Ausgabeordner, in jedem Modus ein Durchlauf. Parallel dauerte das Verschlüsseln 44,16 statt 68,91 Sekunden, das Entschlüsseln 40,39 statt 70,13 - in beide Richtungen mehr als ein Drittel weniger.
Der Gewinn kommt daher, dass die Dateien unabhängig voneinander sind: Die parallele Schleife braucht weder Sperren noch eine Reihenfolge, und keine Datei wartet auf die vorige.
Was ich daraus mitnehme
Der eigentliche Zweck des Projekts war, zwei der drei Verfahren selbst zu implementieren, statt sie nur aufzurufen. Es sind kurze Algorithmen, in denen fast jede Zeile zählt: in welche Richtung eine Rotation geht, wo die ursprüngliche Länge steht und dass die Arithmetik bei XXTEA überlaufen muss, statt eine Ausnahme auszulösen. Die übereinstimmenden Hashes belegen, dass all das Byte für Byte stimmt.
Dazu kommt die Trennung in Client und Service. Die Kryptografie läuft im Service und nicht in dem Prozess, der das Fenster zeichnet, und dieselben drei Algorithmen stehen jedem Programm zur Verfügung, das den Service aufrufen kann.