Arbeitsweise von Verschlüsselungsalgorithmen.


Autor: DarkBug Productions

Dieses Verfahren wird verwendet in CHEW Version 2.0 (engl.chew - kauen, zermalmen) - Download Beispielprogramm

Vorwort:
Dateiverschlüsselungen sind so alt wie die Computer selbst. Dabei sollten diese Daten immer "unlesbar" gemacht werden, um Manipulationen oder auch nur die Einsicht zu verhindern. Da ich jedoch keinem Programm traue, was ich nicht selber geschrieben habe, blieb mir keine andere Wahl, als mir ein Verschlüsselungsprogramm selbst zu schreiben. Die Routine muß folgende Voraussetzungen erfüllen:

  • weder Format, noch Inhalt der Originaldatei dürfen auch nur Ansatzweise zu erraten sein.
  • die Verschlüsselung darf die Zieldaten nicht aufblähen.

Einleitung:
Die recht hohe Sicherheit basiert auf einem gesteuerten Zufallsgenerator, der "Datenmüll" aus der Quelldatei erzeugt. Um die Verschlüsselungstiefe zu prüfen, habe ich den Datenblock von WAV und BMP Dateien verschlüsselt. Diesem Datenblock habe ich danach wieder den originalen Header verpaßt und geöffnet. Ergebniss: Aus einem recht unansehnlichen Bild von meiner Fresse wurde ein gleichmäßig, buntes, pixeliges (und recht beschauliches) Bild von überhaupt gar nichts. Aus einer klangvollen Musikdatei wurde ein gleichmäßiges, nervtötendes Rauschen.

Arbeitsweise:
Der Zufallsgenerator (RND) ist sicher nicht das, was der Name vermuten läßt. Denn in einem Computer passieren zwar "Unfälle", aber diese sind absolut nicht "zufällig".

Der Zufallsgenerator (RND) kann zwar durch setzen eines Startwert (RANDOMIZE) gesteuert werden, aber er produziert dabei auch wirklich nur "zufällige" Zahlenreihen, auch wenn der Startwert immer der selbe ist. Um immer die selben "zufälligen" Zahlenreihen zu ermitteln, muß der RND einen "RESET" ausführen. Das geht über den Befehl "A = RND(-1)". Dieses Kommando resetiert den Zufallsgenerator vollständig, daß dieser danach keine "zufälligen" Zahlen mehr ermitteln kann (auch wenn diese immer noch "zufällig" aussehen). Nach einem solchen "RESET" kann der RND mit einem Startwert weiter gesteuert werden. Das Ergebnis sind "zufällig-aussehende" Zahlenreihen, die bei gleichen RANDOMIZE die gleichen Werte haben.

Wenn nun die Wertebereiche des RND auf Bytegröße (0-255) begrenzt werden, kann man diese "nicht zufälligen" Zahlenreihen für eine "hundsgemeine" Verschlüsselung verwenden. Obwohl der RANDOMIZE nur Zahlenwerte mit maximal 64bit verarbeiten kann, ist eine Verschlüsselung dieser Art kaum (oder nur mit gigantischem Aufwand) zu knacken und der Aufwand würde in keinem Verhältnis zum Nutzen stehen.

Im Beispielprogramm habe ich einen String (Block$ = "Arbeitsweise Chew") benutzt, der die Arbeitsweise veranschaulichen soll. Die Bildschirmausgabe ist zweckgebunden einfach.



Ganz links stehen die ASCII-Zeichen des Strings und daneben dessen ASCII-Werte. In der zweiten Spalte (unter Code100) stehen die ASCII-Ergebnisse der ersten Verschlüsselung (mit RANDOMIZE 100). Daneben die "wiederhergestellten" Bytes. Unter "Code200" stehen die Werte der zweiten Verschlüsselung (mit RANDOMIZE 200) und daneben die "wiederhergestellten" Originale.

Verwendet man jetzt den Datenpuffer (BLOCK$) zum Lesen von Dateien, kann man diesen String an das Unterprogramm "Coden" übergeben und erhält einen "zerkauten" Block$ mit Datenmüll, den man dann wieder schreiben kann. Das Ergebnis ist eine Zieldatei mit der gleichen Größe, die aber nur noch Müll zu enthalten scheint. Wie in meinem Beispiel erklärt, funktioniert dieser Vorgang natürlich auch in umgekehrter Richtung.

Noch ein Hinweis...
Um so größer der String ist, um so schneller werden Zugriffe auf den Datenträger. Jedes Byte einzeln gelesen, verschlüsselt und geschrieben dauert unverhältnismäßig länger, als Blöcke von z.B. 32KB Länge.

Ganz Wichtig !!!
Diese RND-Verschlüsselung ist nicht mit BlitzBasic realisierbar, weil BlitzBasic einen RND-Generator benutzt, dessen Funktion durch die DirectX Version und Windows eigene Komponenten bestimmt wird. Das führt bei bestimmten Kombinationen zu "Berechnungsfehlern" beim "Zufall". Meine RND-Routine für QuickBasic arbeitet überall zuverlässig. Bis jetzt ist mir nur bei der BlitzBasic-Version aufgefallen, daß diese Routine nicht zuverlässig arbeitet. Warum das so ist, oder was da schief läuft, kann ich noch nicht genau sagen. Dazu müßte ich mehr über den Kern von BlitzBasic in Erfahrung bringen...