AOTP - Dateien verschlüsseln und kontrolliert freigeben

AOTP ist einer Idee entsprungen, die ich einmal hatte.

Wenn man heute Dateien ins Internet stellen möchte und kontrollieren möchte, von wann an die Datei verwendet werden kann, muss ich diese verschlüsseln und das Passwort bei Bedarf freigeben, dies hat gewisse Nachteile:

Für jede Datei muss ein anderes Passwort gewählt werden. Passwörter müssen sicher aufbewahrt werden. Es muss sehr genau darauf geachtet werden, welches Passwort wann freigegeben wird. Des Weiteren verrät die Dateigrösse üblicherweise den Inhaltstyp.

AOTP behebt einige dieser Probleme.
*Verschlüsselt mehrere Dateien mit nur einem Schlüssel, der Schlüssel passt aber nur auf eine Datei *Nur 1 Byte RAM wird benötigt pro Stream (3 Bytes für Entschlüsselung oder Verschlüsselung total). Das Programm verwendet mehr RAM aufgrund des enormen Geschwindigkeitszuwachs *byteweise und nicht blockweise Verschlüsselung erlaubt das Springen zu einer beliebigen Stelle *Alle verschlüsselten Dateien haben dieselbe Grösse *Verschlüsselung verwendet XOR Operation, welche auch in RISC CPUs vorhanden ist *Algorithmus ist sehr simpel und kann bei Bedarf einfach aus dem Kopf programmiert werden in jeder beliebigen Umgebung

Werden mehrere Dateien verschlüsselt können diese anschliessend der Reihe nach freigegeben werden. Zuerst Datei 1, anschliessend 2 (erlaubt Entschlüsselung von 1), dann 3 und so weiter. Zum ende der Schlüssel für die letzte Datei.
Dateien enthalten einen verschlüsselten Header, der den originalen Dateinamen enthält. Die verschlüsselte Datei kann daher beliebig umbenannt werden.

Die hier angebotene Anwendung dient als Demonstration. Der Schlüsselgenerator verwendet den Zufallsgenerator aus dem System.Cryptography namespace. Weitere 2 Generatoren liegen zu Testzwecken bei.

Source code und detailiertes Readme: GitHub
Kompilierte EXE Datei: GitHub (Digital signiert)

EDIT: RNG jetzt kryptografisch sicher

Screenshot

Dieser Post erklärt, wie die Verschlüsselung realisiert wird
Das Verfahren zu kennen ist nicht notwendig, hilft aber zu verstehen, warum nur 1 Schlüssel benötigt wird

Schlüssel
unabhängig von der Anzahl Dateien wird immer exakt 1 Schlüssel benötigt. Das Programm scannt alle Dateien und berechnet welche Datei die grösste wird, dabei wird der Header mit eingerechnet. Es wird dann ein Schlüssel erstellt, der exakt diese Länge aufweist und gespeichert. (key.bin).

Verschlüsselung
Die Datei, welche als letztes freigegeben wird wird nun genommen und byteweise XOR verknüpft mit dem Schlüssel (ohne Header). Das Prinzip ist bekannt aus der OTP Verschlüsselung.
Sollte die Datei + Header kürzer sein, als der Schlüssel, werden nun zufällig generierte Bytes an die Datei angehängt. Anschliessend wird der Header ebenfalls verschlüsselt und an die Datei angehängt.

Mehrere Dateien
Werden mehrere Dateien verschlüsselt, wird die zweite Datei mit der ersten verschlüsselt (also mit dem Ergebnis des ersten Durchlaufes). Da ein Schlüssel aus beliebigen Bytes bestehen kann und keiner Form folgen muss, kann jede verschlüsselte Datei selbst als Schlüssel verwendet werden. Dies ist einer der Gründe, warum alle Dateien auf die selbe Grösse aufgeblasen werden.
Wenn wir 5 Dateien verschlüsseln wollen ergibt sich also folgendes:

D - Datei mit padding und Header
S - Schlüssel
V - Verschlüsselte Datei mit Paddung und Header

• • XOR operation

D5 + S -> V5
D4 + V5 -> V4
D3 + V4 -> V3
D2 + V3 -> V2
D1 + V2 -> V1

Kontrollierte Freigabe
Möchte ich nun V2 entschlüsseln, benötige ich Zwangsläufig V3. Das bedeutet, solange der Anbieter V3 nicht freigegeben hat, kann ich V2 nicht entschlüsseln.
Wird V3 freigegeben, kann ich V2 zu D2 entschlüsseln, anhand des Headers kann ich das Padding entfernen (oder besser: dieses gar nicht erst verarbeiten) und den wahren Dateinamen ermitteln.
Habe ich D2, kann ich diese nun verwenden. um wiederum V3 zu entschlüsseln, muss ich warten, bis V4 verfügbar wird.

Entschlüsselung
Bei der Entschlüsselung ist der Header sehr wichtig. Ich will nicht für eine Audiodatei 700 MB entschlüsseln, nur weil eine Videodatei im Set beiliegt, die die Grösse massiv erhöht. Die Entschlüsselung funktioniert daher folgendermassen:

Zuerst werden die letzten 4 Bytes entschlüsselt, diese teilen uns die Headergrösse mit.
Wir entschlüsseln mit dieser Information den kompletten Header.
Aus den ersten 8 bytes des Headers ermitteln wir die Dateigrösse, dadurch können wir das Padding ignorieren.
Aus den nächsten 4 bytes ermitteln wir die Länge des Dateinamens.
Anschliessend lesen wir den Dateinamen aus.

Jetzt enschlüsseln wir so viele Bytes vom Anfang der verschlüsselten Datei, wie der Header angegeben hat und benennen die Datei dem header entsprechend.

Da hast du aber ein großes Problem!
Wenn wir + als XOR ansehen verhält es sich nämlich folgendermaßen:
wenn a+b = x dann ist a+a+b = a+x also b = a+x (denn a+a hebt sich auf). Man kann also einfach eine Datei auf die andere Seite der Gleichung bringen.
Jetzt schauen wir mal deine Situation an

D5 + S -> V5
D4 + V5 -> V4
D3 + V4 -> V3
D2 + V3 -> V2
D1 + V2 -> V1

Dann rechnen wir: D4 + V5 = V4, oder umgestellt: D4 = V5 + V4
Man kann sich aus zwei Verschlüsselungsdateien eine Klartextdatei berechnen. Damit kriegt jemand der alle Vx hat auch alle Dx raus, bis auf die letzte (D5).

So eine Überlegung solltest du schnell gesagt bekommen, bevor du das ganze irgendwo einsetzt und es dann jemand knackt 😉

Es ist auch gewollt, dass du die Verschlüsselte Datei X mit der Verschlüsselten Datei X+1 entschlüsseln kannst. X+1 kannst du ohne X+2 nicht entschlüsseln. Ich kann nach und nach Dateien freigeben und das erlaubt jeweils die entschlüsselung der vorangehenden. Wenn ich dir V1 und V2 gebe dann kannst du V2 nicht entschlüsseln, erst wenn ich dir V3 gebe (und dann wiederum kannst du V3 nicht entschlüsseln)

Ok dann hab ich wohl wirklich nicht verstanden für welchen Zweck das ganze überhaupt gedacht ist 😃
Wenns nur darum geht dass eine Datei erst ab einem bestimmten Zeitpunkt verfügbar ist, wärs dann nicht viel einfacher wenn diese Datei erst dann veröffentlicht wird, statt zu diesem Zeitpunkt die darauffolgende Datei zu veröffentlichen mit der dann die jetzige entschlüsselt werden kann?

Kannst du kurz ein Szenario beschreiben für das dein Verfahren gedacht ist?

Spontan würd ich sagen als "Versicherungsfall" wie im Fall Snowden:
Die Datei wird veröffentlicht und der Schlüssel dann, wenn ihm was "passiert". Inwiefern das wirklich sicher ist (bedenkt man die geringe Anzahl an Möglichkeiten durch Int32, das er verwendet) steht das aber auf einem anderen Blatt.

Ich habe den algorithmus angepasst. Dieser verwendet nun den FIPS-140 zertifizierten RNGCryptoServiceProvider, dadurch wird die Int32 Limitation aufgehoben.

Ich hab das so verstanden dass der Schlüssel so lang ist wie die größte Datei, dann wird jedes Byte/Bit (egal) aus der Datei mit dem entsprechenden des Schlüssels ver-XORt und da kommt dann das verschlüsselte raus.

Aber das Problem dass man mit zwei verschlüsselten Dateien ohne den Schlüssel eine Klartextdatei herstellen kann besteht immer noch. Mich würde schon noch interessieren für welchen Einsatz das gedacht ist. Die Snowden Variante macht für mich mehr in der Form Sinn, dass man alles mit einem einzigen Schlüssel codiert und den dann irgendwann rausgibt.

Hallo chilic,

dass man mit zwei aufeinander folgenden verschlüsselten Dateien eine davon entschlüsseln kann und dass man allgemeiner betrachtet mit der letzten Datei einer Kette alle weiter vorne in der Kette liegenden Dateien entschlüsseln kann, stellt insofern kein Problem dar, als dass hier genau das beabsichtigt ist. Works as designed.

Allerdings geht es mir wir dir, dass mir nicht so recht ein Szenario einfallen will, wo man das sinnvoll einsetzen kann.

Auf meine Nachfrage hatte mir AyrA mitgeteilt, dass es sich mehr um einen "Proof of Concept" und eine Spielerei für Programmierer handelt, die sich mit Verschlüsselung auseinandersetzen wollen. Insofern vermute ich, dass wir hier vergeblich nach einem praktisch sinnvollen Szenario suchen bzw. fragen werden. 😃

herbivore