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.

Tim Kryptographie

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.

Tim Kryptographie

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

Tim Kryptographie

Nachdem ich nun in den letzten Wochen Staffelweise 24 geschaut habe, will ich einige Aussagen (die ich so gehört habe) kommentieren.

“das ist Blowfish verschlüsselt, das erkennt man am Header.”

Klingt gut, ist aber Unsinn. Eine verschlüsselte Datei bzw. ein verschlüsselter Container besitzt keinen besonderen Header. Natürlich könnte man dem zurecht entgegenhalten das dies Anwendungsspezifisch ist. Jedoch wo liegt der Sinn einem Angreifer schon vor Eingabe des Passworts den Algorithmus zu verraten (lassen wir Kerkhoff außen vor).  Sofern kein besonderer Verschlüsselungsalgorithmus ausgewählt ist, führen Programme “Probeentschlüsselungen” durch und prüfen auf Plausibilität. 

Decryption is considered successful if the first 4 bytes of the decrypted data contain the ASCII string “TRUE”, and if the CRC-32 checksum of the last 256 bytes of the decrypted data (volume header) matches the value located at byte #8 of the decrypted data (this value is unknown to an adversary because it is encrypted – see the section Header Key Derivation, Salt, and Iteration Count). If these conditions are not met, the process continues from (3) again, but this time, instead of the data read in (1), the data read in (2) are used (i.e., possible hidden volume header). If the conditions are not met again, mounting is terminated (wrong password, corrupted volume, or not a TrueCrypt volume).

Quelle: http://www.truecrypt.org/docs/encryption-scheme.php

Außerdem ist Blowfish (128 Bit) schwer veraltet.

Definieren wir das Ganze einfach mal als zweifelhaft.

Als nächstes:

“das ist eine affine Chiffre, die kann man nicht knacken”

Okay, Blowfish geht, aber eine (linear) affine Chiffre nicht. Die Affine Chiffre ist (das findet auch jeder in Google) eine einfache Blockchiffre, welche allerdings im Gegensatz zur einfachen Verschiebechiffre noch einen 2. Schlüssel hat. Der Schlüssel ist also ein zwei-Tupel: k=(a,b). Wenn wir eine Alphabetsgröße von 26 festlegen, verschlüsselt sich Text mit Hilfe folgender Formel:

c = a*p + b mod 26

Wobei c das neue Chiffre- und p ein Klartextzeichen ist. Ein Beispiel:

Klartext: “ABC”, Key: (2,3)

2 * 0 (A) + 3 mod 26 = 3 (C)
2 * 1 (B) + 3 mod 26 = 5 (E)
2 * 2 (C) + 3 mod 26 = 7 (G)

Chiffretext = “CEG”

Zum entschlüsseln muss ein mulitplikatives Inverses berechnet werden.

Das versteht man also unter einer affinen Chiffre. Natürlich ist etwas kniffeliger als eine reine Verschiebe oder Vignerechiffre, jedoch nicht wirklich ein Problem. Mit ein wenig Verstand bekommt man es auch noch gut auf dem Papier hin.
Diese Aussage können wir zweifelsfrei als Unsinn bezeichnen.

Tim IT-Sicherheit, Kryptographie

Dieses Thema ist mir persönlich sehr wichtig da darüber sehr viel Unwissen herrscht. Rein theoretisch könnten digitale Signaturen dafür sorgen, das unsere E-Mail Postfächer fast spamfrei bleiben. In der Praxis werden Sie jedoch leider (auch aus Kostengründen) nicht dafür verwendet. Dafür gibt es andere gute Anwendungsmöglichkeiten die ich auch präsentieren möchte.

Im ersten Teil jedoch, will ich eine kurze Einführung in die Technik “dahinter” geben um im zweiten Teil das organisatorische, also PKI (Public-Key-Infrastruktur), zu erklären.

Wie funktionieren überhaupt diese digitalen Unterschriften? In der realen Welt stellen wir mit einer persönlichen Unterschrift Verbindlichkeit zwischen dem Text auf dem Papier und dessen Inhalt her. Wenn ich also etwas unterschreibe, nehme ich den Text (inhaltlich) zur Kenntnis. Dies hat auch eine gewisse Beweiskraft, da die Authentizität der Unterschrift geprüft werden kann.

Im Gegensatz zum realen Leben, lässt sich im Internet allerdings alles “kopieren”. Ich könnte eine Unterschrift also einfach irgendwo ausschneiden und unter einen anderen Text kleben. Ob das nun auch in der wirklichen Welt möglich ist lasse ich einfach mal offen. Sicher ist jedoch, das es auf dem Computer viel einfacher geht.

Also muss die digitale Unterschrift in Zusammenhang mit dem Text stehen, so das ein Verändern des Textes auch gleich die Unterschrift zerstört. Und genau so funktioniert das auch. Kommen wir also zu den Details.

Zunächst der Text:

Hiermit nehme ich Ihr Angebot auf Abschluss eines Kaufvertrags vom 25.06.2008 bzgl. drei Gläser Weizenbier schriftlich an.

Dies ist also der Text (z.B. in einer E-Mail) der zu unterschreiben ist. Der erste Schritt besteht nun darin, aus diesem Text ein Fingerabdruck zu erstellen. Wie wir bereits wissen, ist dies mit Hashfunktionen wie z.B. MD5 oder SHA möglich. Der Grund dafür ist eigentlich nur, die Länge der Signatur möglichst klein zu halten.

Hash(Text) = f998fb1e1a73549287404a43a2506801

Ich habe aus meinem Text also nun einen kompakten Hash (MD5) erstellt. Weiter geht es…

… und zwar mit dem RSA Verfahren. Ja, es taucht überall auf und das ist auch Grund warum dieses System so wichtig ist. Ich möchte nicht nochmal im Detail darauf eingehen wie damit ver- und entschlüsselt wird denn dies ist in den Grundlagen schon hinreichend beschrieben. Diese komplett im Detail zu verstanden haben ist allerdings auch nicht so unbedingt notwendig. Sehr wichtig dagegen ist folgendes:

Sei E( text ) die Funktion zum verschüsseln (RSA), sei D( text ) die Funktion zum entschüsseln (RSA), jeweils mit dem gleichen Schlüssel.

1) E ( Klartext ) = Chiffretext
2) D ( Chiffretext ) = Klartext
3) D ( E ( Klartext ) ) = Klartext
4) E ( D ( Klartext ) ) = Klartext

Zeile 1 und 2 sind denke ich recht offensichtlich. Ich verschlüssel einen Text und erhalte den verschlüsselten Chiffretext und umgekehrt. In Zeile 3 wird das beschrieben, was im Internet so geläufig ist: ich verschlüssel einen Text (mit E), sende ihn und erhalte (durch D) den Klartext zurück. Wichtig ist also die Zeile 4: wenn ich einen Text entschlüssel, also D anwende, erhalte ich auch eine Art von Chiffretext. Und wenn ich diesen entschlüsselten Text wieder verschlüssel, erhalte ich den Klartext.

Dieses Verfahren wird auch bei den digitalen Signaturen eingesetzt. Ich bilde (wie oben beschrieben) einen Hash aus dem Text und entschlüssel ihn mit meinem (geheimen) privaten Schlüssel. Niemandem (außer mir) ist der private Schlüssel bekannt und daher kann auch nur ich diese Signatur leisten. Der “entschlüsselte” Text wird einfach an die E-Mail angehangen.

Die Validierung der Signatur ist jedem möglich, indem er den “entschlüsselten” Text mit dem öffentlichen Schlüssel des E-Mail Absenders verschlüsselt. Dadurch erhält er den Hashcode und kann diesen abgleichen. Das ganze nochmal mit Beispiel:

Hash(Text) = f998fb1e1a73549287404a43a2506801

hatten wir eben ausgerechnet. Nun wird der Hashcode mit dem privaten Schlüssel entschlüsselt.

DECRYPT ( privatekey , “f998fb1e1a73549287404a43a2506801″ )
= dfmkomogerglmmerfohgnjutrihdmfkosemvgtjngrmakofrjlsgnhbhrgnamghktmhkke
(nur Beispielhaft)

Dieser wird an die E-Mail einfach angehangen

Hiermit nehme ich Ihr Angebot auf Abschluss eines Kaufvertrags vom 25.06.2008 bzgl. drei Gläser Weizenbier schriftlich an.
dfmkomogerglmmerfohgnjutrihdmfkosemvgtjngrmakofrjlsgnhbhrgnamghktmhkke

Die E-Mail wird versendet. Die andere Seite verwendet den öffentlichen (allen bekannt da veröffentlicht) des Absenders und verschlüsselt

ENCRYPT ( publickey , “dfmkomogerglmmerfohgnjutrihdmfkosemvgtjngrmakofrjlsgnhbhrgnamghktmhkke”)
= f998fb1e1a73549287404a43a2506801

Nun bildet der Empfänger einfach den Hashcode vom Text und gleicht die 2 Werte ab:

Hash(Text) =?= f998fb1e1a73549287404a43a2506801

Wenn beide Werte identisch sind, ist die Signatur gültig.

Angenommen ein böser Mensch würde nun den Inhalt ändern wollen, also folgende Änderung durchführen:

Hiermit nehme ich Ihr Angebot auf Abschluss eines Kaufvertrags vom 25.06.2008 bzgl. zehn Gläser Weizenbier schriftlich an.

würde sich folgender neuer Hashwert ergeben:

Hash(neuerText) = cc8bfa6863caafd65d3476c390ece04a 

und der Abgleich mit der Signatur (f998fb1e1a73549287404a43a2506801) schlägt fehl.

Die Funktionsweise sollte damit klar sein. Irgendwie muss jedoch auch beweisbar sein, das die Unterschrift auch wirklich von DIESER Person kommt und nicht von einer anderen… (Cliffhanger)

Tim IT-Sicherheit, Kryptographie

Wir haben es nun geschafft diese Vigenère – Verschlüsselung in drei additive (verschiebe) Chiffren mit jeweils einem Schlüssel zu verwandeln, indem wir den Text geschickt in |k| Teile (|k| = Länge des Schlüssels) aufspalten. Das hilft allerdings bisher nur bedingt, denn die Anzahl der Möglichkeiten hat sich dadurch nicht verändert. Obwohl wir nun die Länge des Schlüssels kennen.

Erst wenn es uns gelingt, den Aufwand von 255 Möglichkeiten (pro Schlüsselzeichen) auf wenige zu reduzieren, ist aus diesem großen Problem, ein sehr kleines geworden. Und dies ist mit Hilfe der “Häufigkeitsanalyse” möglich. Diese beruht darauf, dass das “E” und das Leerzeichen ” ” am Häufigsten in deutschen Texten vorkommt. Ein Beispiel:

Hat der alte Hexenmeister
Sich doch einmal wegbegeben!
Und nun sollen seine Geister
Auch nach meinem Willen leben.
Seine Wort und Werke
Merkt ich und den Brauch,
Und mit Geistesstärke
Tu ich Wunder auch.
Walle! walle
Manche Strecke,
Daß, zum Zwecke,
Wasser fließe
Und mit reichem, vollem Schwalle
Zu dem Bade sich ergieße.

Das “E” findet sich in diesem Text 50 mal und macht daher knapp 20% aus. An zweiter Stelle (hier) das “N” mit 7,6%. Dieses Verhältnis ändert sich nach der einfachen Verschiebechiffre nicht. D.h. das häufigste Zeichen im Chiffretext wird wohl im Klartext das “E” gewesen sein. Angenommen bei der Häufigkeitsanalyse des verschlüsselten Textes ergibt sich, dass das “A” am häufigsten vorkommt, berechnen wir die Differenz zwischen “E” und “A” und kennen den Wert des Schlüssels.

So verwandeln wir 255 verschiedene Möglichkeiten (pro Schlüsselzeichen) in 1 oder 2, max 3. Daraus ergibt sich im average-case 2^3 = 8 anstelle von 255^3 = 16581375. Analog für 8 Zeichen 256 anstelle von

17.878.103.347.812.890.625

Möglichkeiten.

Die meisten Kryptosysteme (besonders die asymmetrischen) bauen darauf, dass das große Problem auch ein großes bleibt und sich nicht (wie hier) in ein kleines verwandeln lässt. Exakt das ist es, was die Krypoanalyse ausmacht.

Was ist eigentlich wenn der Schlüssel genauso lange ist wie der Text?

Tim Kryptographie

Was der Rechner mit “roher Gewalt” bei einer entsprechenden Passwortlänge nicht mehr vollbringt, bewältigt der Mensch mit seinem gesunden Menschenverstand recht schnell.

Die beschriebene Verschlüsselung wird auch als Vigenère Chiffre bezeichnet. Brechen lässt sich diese über den Kaskiski test.

Wir konnten ja beobachten das der Text mittels einem sich wiederholenden Passwort (“MNMNMN…”) verschlüsselt wird. Dies ist auch der Fall, wenn das Passwort etwas länger ist (“TESTTESTTEST…”). Nun haben wir aber den Vorteil das die deutsche Sprache recht redundant ist und sich daher viele Wörter wiederholen. Nehmen wir nur mal die 3 Artikel, “der”, “die” und “das”. Je nach Position und mit etwas Glück, werden sie im Text mit dem selben Passwort verschlüsselt. Ein Beispiel:

P= DAS KANN MAN ABER NICHT SAGEN DAS IST SO NICHT RICHTIG
K= BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA
C= FMT WBPZ OMO MCGD PUDJF UMHGZ FMT UTV TQ OKOIV SKOIVUH
(!) In diesem Beispiel wurde das Leerzeichen nicht mit verschlüsselt.

“DAS” wird jeweils mit dem selben Passwort (“BLA”) verschlüsselt. Daher ergibt sich auch später im Chiffretext das gleiche Ergebnis. Es gilt also im Text (der möglichst lange sein sollte) gleiche Sequenzen zu finden. Hier an dieser Stelle also “FMT”. Das war Schritt 1.

Schritt 2 besteht darin, aus diesen gefundenen Sequenzen, die Passwortlänge ungefähr zu erraten. Hier in diesem Fall lässt sich also von 3 oder 4 Zeichen ausgehen. Je länger der Text, desto besser die Ergebnisse.

Im 3. Schritt muss zunächst noch einmal nachgedacht werden. Durch den Algorithmus wissen wir, dass das erste Zeichen des Klartextes, mit dem 1. Zeichen des Passworts verschlüsselt wurde. Da wir von einer Passwortlänge |k|=3 ausgehen, analog das zweite und dritte Zeichen:

___ + K1 = F       ___ + K2 = M        ___ + K3 = T
___ + K1 = _       ___ + K2 = W        ___ + K3 = B
___ + K1 = P       ___ + K2 = Z        ___ + K3 = _
___ + K1 = O       ___ + K2 = M        ___ + K3 = O
...

In der Mitte dieser Tabelle sehen wir z.B. das “M W Z M …” mit dem gleichen “Passwortbuchstaben” (K2) verschlüsselt wurde… (Cliffhanger)

 Ich danke für die Aufmerksamkeit bei meinem siebten konstruktiven Blogeintrag.

Tim Kryptographie

Ich denke das sich viele schon einmal gefragt haben, meist ausgelöst durch Filme, wie Kryptoanalytiker arbeiten bzw. wie Chiffren gebrochen werden. Bei recht einfachen Chiffren wie z.B. rot13 oder Cäsar, bei denen einfach die Buchstaben jeweils um einen Schlüssel im Alphabet verschoben werden, ist das relativ trivial. Vorweg ein Beispiel für die Cäsar Chiffre:

Klartext P = HALLO
Schlüssel K = (+)3
Verschlüsselung:
H -> K
A -> D
L -> O
L -> O
O -> R
Chiffretext C = KDOOR

Um dies nun zu “knacken” müsste man lediglich nacheinander die Schlüssel ausprobiern. Also k=1, k=2, k=3… Das Ganze geht natürlich mit dem Computer sehr schnell, wobei allerdings eine Plausibilitätskontrolle notwendig ist um einen sinnvollen Text festzustellen. Jedoch (heute) kein wirkliches Problem. Zur Not klappt dies auch noch “von Hand”. Diese Art von Verschlüsselung wird als “additive Chiffre” oder Verschiebechiffre bezeichnet.

Das Ganze geht jedoch auch schwieriger. Nehmen wir beispielhaft ein Alphabet

A = ABCDEFGHIJKLMNOPQRSTUVWXYZ

und weisen den Buchstaben jeweils nacheinander einen festen Wert zu:

A = 1
B = 2
C = 3
…
Y = 25
Z = 26
A = 27 (1)
B = 28 (2)

Das ganze ist zyklisch, hinter Z geht es mit A weiter. Der Klartext “HALLO” lässt sich dann auflösen zu: H=8 A=1 L=12 L=12 O=15 bzw. 8 1 12 12 15

Dies wird nun mit dem Schlüssel “MN” verschlüsselt, sofern der Text länger ist “MNMNMN…”:

H ( 8 )  + M ( 13 ) = U ( 21 )
A ( 1 )  + N ( 14 ) = O ( 15 )
L ( 12 ) + M ( 13 ) = Y ( 25 )
L ( 12 ) + N ( 14 ) = Z ( 26 )
O ( 15 ) + M ( 13 ) = B ( 28 = 2 )

Hier lässt sich auch gleich erkennen, das die zwei “L” unterschiedlich verschlüsselt werden. Wenn man sich nun ein 8, oder sogar 16 Bit Alphabet vorstellt und ein Passwort mit 8 Zeichen ist dieses Problem mit “Brute Force” praktisch nicht mehr zu lösen.

Das macht dies allerdings nicht zu einer guten Chiffre. Tatsächlich ist diese jedoch in sehr kurzer Zeit geknackt… (Cliffhanger) 

Ich danke für die Aufmerksamkeit bei meinem sechsten konstruktiven Blogeintrag.

Tim Kryptographie

Wie versprochen einen Beitrag zur hybriden Verschlüsselung.

Sie ist eigentlich sehr simpel und umso mehr genial. Sie verbindet die Vorteile der 2 anderen Systeme zu einem Neuen.

Erstmal warum das Ganze. Symmetrische Verfahren benötigen den Austausch eines geheimen Schlüssels zwischen Sender und Empfänger. Im Internet, im Normalfall, nicht möglich. Bei Asymmetrischen ist das nicht nötig, jedoch haben sie den Nachteil, das sie sehr langsam sind. Genauer gesagt ca. 1000 mal langsamer.

Die “Hybride Verschlüsselung” vereinigt die Vorteile und besitzt eigentlich keine Nachteile. Sie funktioniert nämlich so: eine Seite würfelt sich einen geheimen Schlüssel beliebiger Länge für z.B. ein AES256. Dieser Schlüssel wird (asymmetrisch) mit dem öffentlichen Schlüssel der Gegenseite verschlüsselt und übersendet. Dieser entschlüsselt den Chiffretext mit Hilfe seines privaten Schlüssels und erhält den (vom Sender gewürfelten) Schlüssel. Alles weitere (z.B. Dateien) werden mit Hilfe dieses Schlüssels symmetrisch verschlüsselt.

Also nochmal kurz: mit Hilfe eines asymmetrischen Verfahrens (z.B. RSA) wird ein Schlüssel ausgetauscht, welcher für eine symmetrische Verschlüsselung (z.B. AES) verwendet wird. Das wars schon.

Verwendet wird dieses Verfahren z.B. bei SSH (Secure Shell) oder bei SSL/TLS (Secure Sockets Layer / Transport Layer Security). 

Ich danke für die Aufmerksamkeit bei meinem fünftem konstruktiven Blogeintrag.

Tim Kryptographie

Heute möchte ich in wenigen Worten einige “Ungenauigkeiten” aus der Welt räumen. Was Verschlüsselungsverfahren angeht, hört man recht häufig verschiedene Werte: 56/64, 128, 256, 1024, 2048.

Zuerst einmal ist wichtig zwischen zwei verschiedenen Kryptosystemen zu unterscheiden. Auf der einen Seite die symmetrischen (DES, 3DES, Blowfish, AES, Twofish, Serpent, etc.) und auf der anderen Seite die asymmetrischen (RSA, DH).

Bei den symmetrischen, gibt diese Größe an, wie viele Bits des Schlüssels in die Verschlüsselung eingehen. Bei 64 Bit Schlüssellänge, gibt es 2^64 (18.446.744.073.709.551.616) verschiedene Schlüssel. Das klingt zwar nach sehr viel, ist es allerdings nicht. Als Sicher werden Systeme angesehen, die mind. 128 Bit verschlüsselt sind.

340.282.366.920.938.463.463.374.607.431.768.211.456 verschiedene Schlüssel

Die Anzahl der Möglichkeiten für ein 256 Bit System erspare ich mir an dieser Stelle.

Was bedeutet das? 128-256 sind bei symmetrischen Verschlüsselungsverfahren üblich und sicher, mehr wird meist nur durch Kaskadierung erreicht. Das bedeutet, das ein 512 Bit Schlüssel in 2×256 aufgespalten und jeweils in einem anderen System verwendet wird. Hier leidet allerdings die Performance stark.

Und was ist nun mit 1024 und 2048 Bit? Sieht man ja auch des Häufigeren. Dies bezieht sich auf die asymmetrischen Verfahren z.B. RSA. Wie ich in einem anderen Beitrag schon einmal erklärte habe, bezieht sich die Angabe auf die Länge des RSA Moduls. Die Primfaktorzerlegung für eine 1024 Bit Zahl ist nach dem heutigen Stand der Technik so aufwendig, das sie als praktisch unmöglich angesehen wird. Und da Banken immer eine Nummer sicherer gehen, verwenden sie ein 2048 Bit Modul. Warum sich das eigentlich auch der “normale” Mensch leisten kann erkläre ich ein anderes mal, Stichwort “Hybride Verschlüsselung”.

Fazit: Die Anzahl der Bits ist nur interessant mit der Nennung des Verfahrens. Bei AES ist 256 Bit sehr sicher, bei RSA jedoch kein wirkliches Problem. Dort wirds frühestens bei 512 interessant, wirklich jedoch erst bei 1024.

Ich danke für die Aufmerksamkeit bei meinem vierten konstruktiven Blogeintrag.

Tim Kryptographie