INFSEC.de

Hallo zusammen,

vor kurzem hatten ein Kommilitone und ich ein Problem. Wir wollten (über das Internet) ausknobeln, wer von uns mit dem Auto fahren muss und wer dafür Alkohol trinken kann. Ein Schnick-Schnack-Schnuck über das Internet sozusagen. Beide hatten wir nach einer Lösung für dieses Problem gesucht jedoch keine wirklich gute gefunden. Zuletzt entschieden wir uns dazu, es über die Anzahl der Heise.de-News des nächsten Tages zu bestimmen. Je nachdem ob es eine gerade oder ungerade Anzahl ist, muss der eine oder der andere.

Die Frage ist also, ob es dafür bessere Lösungen gibt. Mit Hilfe einer dritten, unabhängigen Instanz sollte dies nicht so schwierig sein, einige Lösungsbeispiele habe ich dafür mal ausgearbeitet:

Beide Parteien könnten mit einem Client auf einen Server verbinden. Sobald alle verbunden sind, gibt dieser eine zufällige Zahl aus. So hat man, synchronisiert, allen Teilnehmern dieses Ereignis zugänglich gemacht.

Oder man könnte eine Webseite bereitstellen, die alle 5 Minuten eine zufällige Zahl ausgibt. So könnten beide Parteien Vermutungen über die nächste Ausgabe treffen und diesbezüglich eine Entscheidung finden. Um dieses Beispiel zu verdeutlichen habe ich diese Webseite angefertigt: http://www.cryptblog.de/random.php.

Eine weitere Möglichkeit wären Kryptogramme eines Servers: Partei A bezieht ein aktuelles Kryptogramm von einem Server, welches eine verschlüsselte Zahl enthält. Er übergibt das Kryptogramm der Partei B und beide einigen sich darauf, welche Entscheidung bei einer geraden/ungeraden getroffen wird. Die Entschlüsselung ist allerdings erst später (~5 Minuten) möglich. Ich denke allerdings, dass diese Lösung unnötig kompliziert ist und kaum einen Vorteil gegenüber den anderen besitzt.

Aber nun die Frage: ist es möglich eine solche Entscheidung zu treffen, ohne dass ein Dritter (Server) beteiligt ist? Meine Antwort darauf ist JA. Folgendes Verfahren habe ich mir überlegt:

Sowohl A, als auch B, denken sich eine möglichst große zufällige Zahl (a und b) aus. Mit Hilfe einer Webseite, die hier lediglich als „Taschenrechner“ dient, berechnen A und B jeweils einen Hash (Fingerabdruck, beispielsweise MD5) ihrer Zahl, also z.B. H(a) und H(b). Über ein beliebiges Kommunikationsmedium kann nun dieser Hashwert ausgetauscht werden. Außerdem müssen sich A und B jeweils für eine gerade oder ungerade Zahl entscheiden. Durch diesen Austausch, haben sich beide auch damit einverstanden erklärt, dieses Verfahren zu nutzen. Nachdem also Hashwerte ausgetauscht sind, ist jeder im Besitz seiner eigenen Zahl und einem Fingerabdruck der Zahl des anderen.

Jetzt kann jeder seine Zahl dem anderen nennen, ob nun A oder B zuerst ist egal. Beide Zahlen werden miteinander addiert, also m = a + b berechnet, und je nachdem ob diese Zahl gerade oder ungerade ist, fällt die Entscheidung für A oder B aus. Aufgrund des vorherigen Austausch der Hashwerte, ist ein nachträgliches ändern der Zahl nicht möglich bzw. A und B können die Aussagen des anderen verifizieren.

Um dieses Beispiel zu verdeutlichen, existiert eine neue Sektion und ein Script um die Durchführung zu vereinfachen: http://cryptblog.de/muenzwurf/.

Nochmal grob zusammengefasst:

A prüft H(b)=H(b‘), B prüft H(a)=H(a‘). Sofern beides wahr, kann von a’=a und b’=b ausgegangen werden.
Beide berechnen m = a+b.

Mittels diesem Protokoll hat jeder Teilnehmer eine 50% Chance zu gewinnen:

In der Anwendung ist folgendes zu beachten:

Die Hashfunktion sollte einigermaßen sicher sein und um Rainbowtables entgegenzuwirken, sollten die Zahlen möglichst groß sein. Sofern dies erfüllt ist, können auch JavaScript Lösungen zum berechnen verwendet werden, wie z.B. http://aktuell.de.selfhtml.org/artikel/javascript/md5/ .

Nachtrag:
Grundsätzlich kann man dieses System auch, leicht modifiziert, für das bekannte Stein-Schere-Papier einsetzen, indem ein Hash von Stein|Zufallszahl, Schere|Zufallszahl oder Papier|Zufallszahl gebildet und später ausgetauscht wird. Das macht die vorherige Absprache ob gerade oder ungerade unnötig.

Hallo liebe Gemeinde,

eine Vermutung wurde ja geäußert (siehe Kommentare). Dieser geht in die Richtung, den Klartext mit einem zufälligen Schlüssel zu chiffrieren und diesen wiederrum mit dem geheimen (ausgetauschten) zu verschlüsseln und an die Nachricht anzuhängen. Also: [E_tempkey(Text) | E_key(tempkey)]. Also ein ähnliches System wie bei den DLC-Containern.

Die Idee ist natürlich nicht schlecht, allerdings handelt es sich hierbei um etwas anderes. Und zwar gibt es in der Praxis verschiedene Betriebsmodi; um einige zu nennen: ECB, OFB, CFB. Und an dieser Stelle wurde der CBC „Cipher Block Chaining“ Modus verwendet. Was dies nun genau bedeutet ist etwas schwierig zu eklären, daher beschränke ich mich an dieser Stelle darauf den Unterschied zwischen dem simpelsten (ECB) darzustellen.

Beim ECB-Modus wird der Klartext in gleiche Stücke getrennt. Im Beitrag zur Bildverschlüsselung (http://cryptblog.de/2008/10/06/bildverschlusselung/) hatte ich dieses Verfahren bereits erläutert. Dort wurde

“Hallo, wie geht es dir  ”

in:

“Hallo, w”, “ie geht “, “es dir  ”

aufgeteilt. Jeder dieser Blöcke wird mit dem gleichen Key verschlüsselt und so erhalten wir am Ende wieder 3 Blöcke. Beispielhaft dargestellt:

“mdjwbcxg”, “ötüeoejd”, “ndkrdkdp”.

Angenommen ich ändere das „Hallo“ im Klartext in ein „Hello“, so würde sich nur der erste Block ändern, die anderen zwei blieben unberührt. Und um diesen Einfluss zu vergrößern gibt es die oben genannten Betriebsmodi. Ein Bild dazu aus Wikipedia zum CBC-Modus:

Zunächst schwierig zu verstehen. Auf der linken Seite haben wir den sehr bekannten Initialisierungsvektor. Bei der Blowfish-Implementierung wird dieser einfach zufällig gewählt. Er wird mit dem Klartext verrechnet (XOR). Das Ergebnis daraus, wird verschlüsselt und ergibt den Chiffretext welches wiederrum auf den nächsten Klartextblock Einfluss nimmt. Durch diese Pfeile ist also zu sehen, dass der Vorgänger immer auf den unmittelbaren Nachfolger einwirkt.

Dadurch ergibt sich eine Kette: wird am Anfang eine Veränderung vorgenommen, ändert dies den kompletten restlichen Chiffretext. Und da, wie schon erwähnt, der IV gewürfelt wird, ergibt sich bei jeder Verschlüsselung einen anderen Chiffretext. Zur Entschlüsselung wird allerdings dieser Vektor benötigt, daher wird er einfach mitgeschickt. Aus dem Plaintext P wird also nicht nur ein Chiffretext C, sondern beinhaltet auch einen IV.

Verstanden sollte sein, dass diese „Block für Block“-Verschlüsselung Probleme bereiten kann und ein Betriebsmodus, wie der CBC, für noch mehr Einflussnahme des Klartextes sorgt.

Nicht grade traditionsgemäß, aber um mal Abwechslung in den Cryptblog Alltag zu bringen.

Wir betrachten folgende Internetseite:
http://www.php-einfach.de/sonstiges_generator_blowfish_js.php

Der angezeigte Key wird zufällig ausgewürfelt und kann ähnlich wie der Klartext geändert werden, muss aber nicht. Danach besteht die Möglichkeit, die Eingabe zu verschlüsseln, worauf eine Ausgabe des verschlüsselten Textes im Base64 erfolgt. Mal als Eingabebeispiel:

Key: tsu15bdi
Klartext: test

Und nun? Jetzt kann mit dem „Verschlüsseln“-Button chiffriert werden. Um dies hier alles nachvollziehen zu können, sollte dies nun jeder einmal durchführen. Nun kommt das große „Problem“. Mit den oben genannten Daten ergibt sich:

AAtRZQALh6Bkp67o8pNUbg==

Wenn ich aber mehrmals den Button betätige, entsteht immer wieder etwas anderes:

AAUYzgALLpTtP2+zdG0O4A==
AAD+sgAJaAF/3D3mdFxHWw==
AA874gALmyCaU23yyjVKcQ==
AAHn2gAKE4mfFu4zg/muTQ==

Und es handelt sich dort jeweils um „test“. Jeder dieser Ergebnisse kann mit dem oben genannten Passwort auch wieder nach „test“ dechiffriert werden. Genaugenommen zu

„test    „

was 8 Zeichen mit jeweils 16 Bit = 128 Bit (Blockgröße) entspricht, dies allerdings nur am Rande.

Normalerweise geht man davon aus, das ein fester Klartext P mit dem festen Schlüssel K nur EIN eindeutiges Ergebnis zurückliefert, um das Entschlüsseln bzw. die Umkehrbarkeit eben möglich ist. Bei der einfachen (additiven) Cäsar Verschiebechiffre ist das ja ähnlich (Schlüssel 2):

A -> C
B -> D
C -> E

etc.

Das oben gezeigte verhält sich also so, als würde A (nach Verschlüsselung) sowohl zu C als auch zu D und E verschlüsselt werden. Und dies jeweils zufällig.

Frage: Wieso ist hier eine eindeutige Entschlüsselung möglich?

Als Kaskadierung wird das Hintereinanderschalten mehrerer Systeme, in diesem Fall Kryptoalgorithmen, bezeichnet. Ein Beispiel:

AES(3DES(Blowfish(„Hallo“,key1),key2),key3)

Wobei key1 != key2 != key3 ist. Der erste Parameter ist der zu verschlüsselnde Text, der zweite der Schlüssel.

Das bemerkenswerte an diesem Beispiel ist, das der 3Des (Tripple-DES) schon in sich aus einer Kaskadierung von drei DES Algorithmen besteht:

3DES = DES(DES(DES(text,key1),key2),key3)

Allerdings ist hier zu bemerken, das der mittlere Baustein eine Entschlüsselung ist. Der 3DES arbeitet nämlich üblicherweise im EDE-Modus: encryption – decryption – encryption.

Wieso? Nunja, der DES hat eine effektive Schlüssellänge von 56 Bit und diese wurde durch das Verwenden von drei unabhängiger Schlüssel auf 168 Bit vergrößert.

Die große Frage ist nun: ist das Brechen einer kaskadierten Verschlüsselung schwieriger, als das einer einzelnen. Die Antwort ist simpel: JAIN.

Ein Beispiel: Wir definieren eine Verschlüsselung E und E‘ wobei E‘ = E^-1 also: E‘ ist die inverse von E. Wir verschlüsseln im ECB Modus, B entspricht dem ersten Block:

E'(E(B,key1),key1) = B

Wir erhalten also nun nach dieser doppelten Verschlüsselung, den Ausgangsblock. Nun würde jeder dagegen halten, das bei einer Kaskadierung unabhänige Schlüssel verwendet werden. Das ist richtig. aber es gibt noch andere Probleme. Z.B. nehmen wir eine additive Chiffre, dann verschlüsselt wir mit:

c = (p+k) mod m

Das p entspricht dem Plaintextzeichen, das k dem Schlüssel und das m der Länge des Alphabets. Nun kaskadieren wir diese Chiffre:

c = (((p+k1) mod m) + k2) mod m

an dieser Stelle darf das innere „mod m“ entfernt werden, ohne das sich dabei die Gleichung ändert:

c = (p+k1+k2) mod m

Und nun definieren wir ein k=(k1+k2):

c= (p+k) mod m

Wer hat’s gemerkt? Es handelt sich dabei um die ursprüngliche additive Chiffre. Wir haben also an dieser Stelle nichts gewonnen. Das liegt daran, das hier „Strukturgleichheit“ herrscht. Die Kaskadierung der gleichen Chiffre führt unter Umständen also nur dazu, das der Schlüssel sich ändert.

So ganz genau weiß man nicht, ob es sinnvoll ist, zwei konkrete Chiffren zu kaskadieren. Es könnte sich herausstellen, das es einfacher ist ein AES+Blowfish zu entschlüsseln, als lediglich ein AES, wenn sich der Blowfish invers verhält. Zugegeben, ist dies sehr unwahrscheinlich, aber nicht unmöglich.

Im Allgemeinen sagt man, das die Kaskadierung mindestens so sicher ist, wie die erste Chiffre der Kette. Es ist sehr wahrscheinlich das eine Kaskadierung mit verschiedenen Schlüsseln eine größere Sicherheit bietet, es ist allerdings nicht bewiesen.

Jajaja ich weiß, es wäre mal wieder Zeit für etwas Neues. Und ich verspreche auch innerhalb der nächsten Zeit noch etwas Interessantes zu berichten. Zwischendurch jedoch, wie bei Privatanbietern üblich, etwas Werbung.

Und zwar bin ich auf folgende Webseite gestoßen: http://www.cryptool.de/

Was ist das? Das wusste ich zunächst auch nicht; der Name verspricht jedoch viel. Also habe ich es mir genauer angeschaut und wurde nicht enttäucht. Hierbei beziehe ich mich auf die aktuelle stable Version 1.4.21. Selbiges wird zunächst installiert und nach dem Start fühlt man sich leicht in das Jahr 1999 zurück versetzt. Aber hier geht es ja nicht um Design, sondern um die Technik bzw. die Möglichkeiten dahinter und die sind sehr erstaunlich. Es erscheint ein Textfenster mit einem Willkommenstext. Seinen angeborenen Instinkt diesen möglichst schnell zu schließen sollte man an dieser Stelle unterdrücken, denn mit wenigen Handgriffen im Menü können wir daraus beachtliches zaubern. Ein Beispiel: wir wählen eine klassische symmetrische Chiffre, den Caesar (sollte mittlerweile bekannt sein), woraufhin sich ein Dialog mit weiteren Eingabemöglichkeiten öffnet. Hier lässt sich nun das Delta, also der Schlüssel, wählen. Wahlweise auch ROT13 was nunmal nichts anderes als ein Caesar mit Schlüssel 13 auf einem 26 stelligen Alphabet ist. Sobald die Konfiguration abgeschlossen ist, öffnet sich neben dem Willkommenstext ein zweites Fenster mit dem gewünschten verschlüsselten Inhalt.

Aber dem ist nicht genug. Wir können mit sehr wenig Aufwand auch moderne Chiffren wie z.B. den AES oder eine Hashfunktion z.B. MD5 wählen. Es ist auch möglich den Text mit einem Eigenen oder neu erstellten Zertifikat zu signieren. Es enthält auch viele kleine Demos, um die Funktionsweise einiger Verfahren zu verdeutlichen. Allerdings gibt es bei der modernen Kryptographie eben die Grundsätze der guten Diffusion und Konfusion. Letzteres zeigt sich nunmal auch bei der besten Demo.

Alles in allem sehr viele Möglichkeiten, also schaut es euch mal an.

Zur 2.0 Beta des Tools: wer hier nur hübchere Bedienoberflächen erwartet, irrt sich gewaltig. Natürlich wurde auch daran gearbeitet, allerdings handelt es sich hierbei (im Gegensatz zum Vorgänger) um einen Kryptobaukasten. Um die oben geschilderte Caesar-Verschlüsselung auch hier zu wiederholen, muss objektorientiert vorgegangen werden. Man nehme:

• 1 Textbaustein zur Dateneingabe
• 1 Baustein „Caesar“
• 1 Textbaustein zur Datenausgabe bzw. Anzeige

Diese werden in geeigneter Weise verbunden und erhält das gleiche Ergebnis wie oben geschildert. Nun wird wohl sicherlich der Einwand kommen, das dies ziemlich kompliziert ist… und dieser ist auch berechtigt. Allerdings lasses sich hierdurch sehr komplexe Mechanismen erstellen und analysieren. Es ist ein mächtiges Tool und wie alle Werkzeuge dieser Art nunmal etwas unhandlich für die kleinen Dinge.

Zum professionellen Arbeiten, ist die 2.0 der alten Version weit überlegen, auch wenn einige Funktionen noch nicht fertiggestellt sind. Auch sehr empfehlenswert.

Dies ist der (bisher) aufwändigste Eintrag.

Nachdem ich einen Interessanten Artikel [1] gelesen hatte, wusste ich direkt das es ein gutes Thema für den cryptblog ist. Und zwar geht es um Probleme beim Verschlüsseln von Bildern.

Zuerst jedoch noch eine wichtige Grundlage: bei Kryptosystemen gibt es verschiedene Betriebsmodi, die bekannteste ist der ECB-Mode (Electronic Code Book). Es ist ja in der Regel so, das nicht nur lediglich 128 Bit verschlüsselt werden sollen, sondern Gigabyte an Daten. Dafür wird dieser große Haufen bei Blockchiffren entsprechend aufgeteilt in kleinere. Ein Beispiel:

„Hallo, wie geht es dir  “ wird (sofern 1 Zeichen = 16 Bit) in:

„Hallo, w“, „ie geht „, „es dir  “

aufgeteilt. Wie man sieht wurde hier der letzte String aufgefüllt damit er ein Vielfaches von 8 entspricht. Dies ist auch in der Praxis üblich.  Wir besitzen also am Ende eine große Liste von 128-Bit blöcken welche nacheinander ins Kryptosystem eingespeist und damit verschlüsselt werden. Heraus kommt z.B:

„mdjwbcxg“, „ötüeoejd“, „ndkrdkdp“.

Das Problem bei diesem Modus ist, das gleicher Klartext auch in den gleichen Chiffretext verschlüsselt wird. D.h. wenn ich „12345678“ an 2 unterschiedlichen Stellen im Text verschlüssele, würde auch jeweils die gleiche Verschlüsselung entstehen.

aus: „Hallo, wie geht es dir Hallo, wie geht es dir “ wird also:
„mdjwbcxgötüeoejdndkrdkdpmdjwbcxgötüeoejdndkrdkdp„.

Und das ist ein Problem bei Bildern, denn dort finden sich an vielen Stellen gleiche/ähnliche Werte. An dieser Stelle ein Beispiel mit zwei 2×2 Pixel Bildern:

Sei also links unser Klartext (das normale Bild) und rechts der Chiffretext (die Verschlüsselung). Aus dem schwarz und dem dunkelgrau werden jeweils gelb und grün. Jedoch diese zwei silbergrauen Flächen werden identisch verschlüsselt (blau). Dies wäre natürlich nur der Fall wenn die Chiffre nur eine 32 Bit Blockgröße hätte (Rot, Grün, Blau, Alpha), jedoch bleibt das Problem bei 128 Bit ebenso: gleiche Flächen werden gleich verschlüsselt und dies ist vorallem bei kontrastreichen und großen Bildern durch wiederholende Muster zu sehen.

Da mir das jedoch noch nicht genügte, habe ich ein Programm gebaut, welches die Bilder mit Blowfish (24 lässt grüßen) im ECB Modus verschlüsselt.

Oben zu sehen das Originalbild, unten jeweils die Verschlüsselungen mit zwei unterschiedlichen Passwörtern. Hier ist das Problem deutlich zu erkennen: im vertikalen Bereich sind die Farbcodes jeweils identisch. Die kleinen Ungenauigkeiten stammen wahrscheinlich aus der JPG Komprimierung.

Zuletzt das ganze auch mal mit einem richtigen Bild. An dieser Stelle danke ich Tobias Gräber für die Bereitstellung:

Besonders gut zu erkennen ist das Geländer an der rechten Seite. Auch einige Konturen finden sich in der verschlüsselten Version wieder.

Abschließend lässt sich also sagen, das eine Verschlüsselung alleine nicht immer genügt. Die Verschlüsselung und dessen Modus muss auch zum Einsatzzweck passen.

Quellen:
[1] http://www.turbocrypt.com/eng/content/TurboCrypt/Backup-Attack.html