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.

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.

Da stellen wa uns mal janz dumm und fragen uns, watt is eigentlich n Dampfmaschine Quantenkryptographie ?

Klingt ja eigentlich supercool. Es hat durchaus etwas Geheimnisvolles. So wie Quantenphysik (von der ja auch kaum einer Ahnung hat) und in Verbindung mit der Wissenschaft der Geheimnisse, der Kryptographie, für mich DAS Wort dieses Jahrhunderts.

Viele denken, das hat was mit Quantencomputern zu tun. Das sind die Geräte, auf die sich alle freuen  abgesehen von Behörden, Banken, Zertifizierungsdienste, … also fast alle. ABER: Sie werden nicht für die Quantenkryptographie benötigt denn selbige wird schon heute praktisch eingesetzt.

Die Idee ist eigentlich nur, dass über polarisierte Photonen (4) und der Messung mittels Basen (2), beiden Seiten ein eindeutiger Schlüssel zur Verfügung gestellt wird. Dieser wird dann mittels „One Time Pad“ Verfahren auf den Klartext binär aufaddiert.

Und das Ganze nochmal in langsam.

Zuerst einmal will ich etwas ganz wichtiges in der Kryptogaphie vorstellen: die Involution. Nein, nichts französisches, sondern ein besonderes Merkmal. Eine Funktion bekommt dieses Prädikat, wenn folgendes gilt:

f = f^-1 oder anders: inverse(f) = f  oder anders: f(f(x)) = x

In Prosa: bei doppelter Anwendung kommt das ursprüngliche wieder heraus. Ja so etwas gibts und ein wichtiges Beispiel ist das Exklusive Oder, kurz XOR.

0 xor 0 = 0
0 xor 1 = 1
1 xor 0 = 1
1 xor 1 = 0

Ein schönes Beispiel:

       10101101
xor    01011100
---------------
       11110001
xor    01011100
---------------
       10101101

Rot markiert ist der ursprüngliche Text, das Blaue ist z.B. ein Schlüssel, verbleibt das Grüne welches unseren verschlüsselten Text (Chiffretext) darstellt. Hier sehen wir gleich: wende ich den Schlüssel zwei mal an, erhalte ich das ursprüngliche, also den Klartext (rot). Das Ganze lässt sich auch leicht beweisen, ist jedoch an dieser Stelle nicht so wichtig. Hier zu merken (und das ist in der Kryptographie nunmal ausschlaggebend): mit einem XOR lässt sich sowohl Ver- als auch Entschlüsseln sofern der Schlüssel korrekt ist. Das ist also eine Involution.

Das One – Time – Pad Verfahren beruht darauf, das Klartext und Schlüssel gleich lang sind. Man besitzt also auf der einen Seite einen Text der Länge x Bytes und auf der anderen Seite einen Schlüssel >=x Bytes. Diese werden einfach mit dem XOR verrechnet wie oben dargestellt. Es ergibt sich einen Chiffretext c = p xor k. Hier kommt dann das Ausschlaggebende: nur mit exakt dem gleichen Schlüssel lässt sich c wieder entschlüsseln p = c xor k. Dadurch ist das Verfahren zwar beweisbar sicher, jedoch praxisfremd. Denn wenn es mir möglich ist einen Schlüssel k, mit der gleichen Länge von p, geheim zu halten, kann ich ja auch direkt p weitergeben. Bei normalen symmetrischen Verschlüsslungen besteht k nur aus 16 Zeichen und verschlüsselt seitenweise Texte. Hier jedoch soll zu jedem Buch, welches verschlüsselt werden soll, ein weiteres (genauso dickes) Buch mit der Aufschrift „Schlüssel“ existieren. Sowas möchte eigentlich niemand.

Doch! Die Quantenkryptographie. Diese stellt auf beiden Seiten beliebig lange (gleiche) Schlüssel zur Verfügung. In diesem Beitrag möchte ich mich nicht allzu sehr mit den technischen Details befassen, auch wenn diese Recht interessant sind. Kurz: auf der einen Seite werden polarisierte Photonen über einen Lichtwellenleiter „gesendet“ und auf der anderen Seite mittels einer Basis gemessen. Am Ende tauschen sich beide aus, welcher Filter an welcher Stelle korrekt war. Da es jedes Photon nicht nur 2 sondern 4 Zustände einnehmen kann, erhält ein Angreifer bei diesem Kommunikationsaustausch keine weiteren Informationen. Genau gesagt kann er immer nur eins wissen: es war entweder eine 1 oder eine 0.

Das ist allerdings nur ein Protokoll. Viel wichtiger ist das, was in der Quantenphysik als das „No-Cloning-Theorem“ bezeichnet wird. Selbiges geht ein wenig zurück auf die 3. Aussage der Heisenbergschen Unschärferelation welche besagt, dass die Messung eines Quantenobjekts unmittelbar dessen Störung zur Folge hat und genau an dieser Stelle muss der Informatiker erstmal schlucken. Aus der Welt von Bits und Bytes sind wir gewohnt, alles unverändert (digital) kopieren zu können. Ich erhalte ein Bild und kann selbiges unverändert via E-Mail weitersenden. Laut der Quantentheorie ist dies jedoch mit Photonen nicht möglich. Sobald ich diese gemessen habe, wurden sie bereits verändert. Aufgrund des Protokollaufbaus ist dies bei der Quantenkryptographie nicht so schlimm, jedoch ein Angreifer, welcher sich in die Leitung „setzt“ und mithören will, würde dessen Signale so verändern, das zumindest eine Seite dies bemerkt. Dadurch haben wir also einen abhörsicheren Kanal auf welchem der Schlüssel wandern kann.

Das klingt gut und tatsächlich scheint es so, als hätten die Kryptographen den Kampf gegen die Kryptoanalytiker gewonnen. Jedoch gibt es an dieser Stelle ein großes Problem: der Quantenkanal (also z.B. der Lichtwellenleiter) darf zwischen Sender und Empfänger nicht unterbrochen werden. Außerdem ist es nicht möglich das Signal zu verstärken und die Reichweite ist stark begrenzt. Ein Internet, wie wir es kennen, lässt sich mittels Quantenkryptographie nicht sichern. Maximal könnte es ein System vertrauenswürdiger Instanzen („trusted network“) geben wobei hier die Frage ist, wem wir vertrauen können während wir unser Online Banking durchführen.

Fazit: Quantenkryptographie ist eine tolle Sache, sie ersetzt jedoch nicht die bisherigen Verfahren. Das System selbst verlangt sogar, als „Man in the middle“ Abwehr, asymmetrische Verfahren zur Authentifizierung. 

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

Nachdem die Wortschöpfung „Skriptkiddie“ mittlerweile schon in verschiedenen Lexika zu finden ist, möchte ich euch an dieser Stelle ein neues Volk vorstellen, welches unmittelbar davon abzustammen scheint: der Kryptokiddie.

Nachdem ich mich im Internet ein wenig über Kryptoimplementierungen informiert hatte, fand ich nach kurzer Zeit folgende PHP Implementierung des asymmetrischen Verschlüsselungsverfahren RSA:

http://scripts.ringsworld.com/development-tools/rsa1.3/rsa.php.html

Bevor ich nun erkläre warum der Code wirklich wertlos ist, einige Worte zu dem Verfahren selbst. Dies beruht darauf, das zwei große Primzahlen miteinander multipliziert werden. Diese ergeben das RSA Modul m. Mit Hilfe dieser Primzahlen (unter Verwendung der Eulerschen Phi Funktion) wird ein öffentlicher Schlüssel e und ein privater d ausgerechnet. Bei der Verschlüsselung wird einfach nur der Klartext p mit dem öffentlichen Schlüssel e exponenziert, also c = p^e mod m ausgerechnet. Zur Entschlüsselung passiert das selbe mit dem Chiffretext c und dem privaten Schlüssel d und ergibt sich zu p‘ = c^d mod m. Falls alles korrekt ist, entspricht p=p‘.

Wem das nun zu schnell ging: bei diesem Verfahren gibt es 2 Schlüssel, einen öffentlichen und einen privaten. Mit dem öffentlichen lässt sich lediglich ver- und mit dem privaten entschlüsseln. Will man nun jemandem eine Nachricht schicken, wird der Text mit dem öffentlichen Schlüssel (des Empfängers) verschlüsselt und da nur er den privaten besitzt, kann auch nur dieser den Text wieder entschlüsseln.

Mit dem Zeitalter der asymmetrischen Verschlüsselungsverfahren ist die Zeit des „Schlüssel im Aktenkoffer mit Handschellen übergeben“ vorbei und überflüssig geworden.

Das ganze funktioniert jedoch nur praktisch sicher, wenn das o.g. RSA Modul (also das Produkt der 2 Primzahlen) groß genug gewählt wurde. Groß bedeutet bei dem heutigen Stand der Technik: 1024 – 2048 Bit. Im Privatgebrauch sind 1024 völlig ausreichend, Banken und Zertifizierungsstellen verwenden 2048. In unserem Implementierungsbeispiel werden jenoch nur zwei 13 Bit Primzahlen multipliziert was sich zu einem 26 Bit RSA Modul ergibt.

Die Faktorisierung (also das zurückrechnen von einem Modul zu 2 Primzahlen) benötigt ca. 1 Sekunde. Also nach einer ganzen Sekunde sind die zwei Primzahlen und der private Schlüssel ausgerechnet. Es macht mir wirklich Angst, das es vielleicht Leute gibt die diesen Quelltext einsetzen.

Was lernen wir daraus:

• wenn bei einer RSA Implementierung ein Array mit Zahlen zu sehen ist: skeptisch sein
• wenn die Zahlen auch noch vom Typ Integer sind: Alarm!
• wenn lediglich aus diesen Zahlen das Modul gebastelt wird: HÄNDE WEG!!!

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

Weisst du was MD5 ist? MD5 ist toll! MD5 ist sogar so toll, das es jeder benutzt. Warum auch nicht, in PHP ist es einfach nur simpel

$hash = md5(„Hallo“);

und das war`s schon. Für alle die denken dies wäre vielleicht ein Modell einer Automarke des Fernen Ostens: MD5 (Message-Digest Algorithm 5) ist eine kryptografisch nicht ganz sichere, praktisch jedoch immer noch ausreichende Hashfunktion. Diese ist dazu da, eine Zeichenkette beliebiger länge durch „wenige“ Bits ( 128 ) zusammenzufassen. Es ist also eine Art Fingerabdruck. Ein Merkmal von Hashfunktionen ist, das selbige nicht zurückgerechnet werden kann. Sei also M und M‘ jeweils unterschiedliche Strings, soll es nicht möglich sein folgendes zu finden:

Hash(M) = Hash(M‘)

man spricht auch von Kollisionsfreiheit.

Soviel zu den Grundlagen. In der Praxis werden Hashfunktionen hauptsächlich für MACs (Message Authentication Codes) verwendet. Das ist aber nicht alles, denn in den meisten Fällen werden damit Passwörter in einer Datenbank gespeichert. Die Idee ist, das falls die Datenbank mal „gehackt“ wird (z.B. SQL-Injection), der Bösewicht keine Informationen über das verwendete Passwort bekommt. Häufig ist es so, das Anwender das gleiche Passwort mehrfach verwenden, also auch für den E-Mail Account. Und damit ergeben sich ungeahnt viele Möglichkeiten.

Die Idee ist super, also ein unleserliches Passwort auf der einen Seite und trotzdem volle Funktionalität. Wo ist also jetzt der Haken? Das ist recht einfach, denn für die meisten kleinen Passwörter wurde das MD5 schon „durchgerechnet“. D.h. in einer großen Datenbanken stehen jeweils Klartext und Hashwert. Das trägt den schönen Namen „Rainbow Table“ und ist recht bekannt. Dadurch ergibt sich ja aber immer noch kein Sicherheitsproblem, denken Sie nun. Denn immerhin muss der Angreifer erstmal an diesen Hashwert kommen. Das stimmt jedoch nur halb, denn Google hilft!

Wenn ich „abc123“, als schlechtes aber häufig verwendetes Passwort hashen lasse, erhalte ich „e99a18c428cb38d5f260853678922e03“. Dies gebe ich einfach mal in Google ein. Nicht sehr viel später finde ich (bedingt durch die Einzigartigkeit) verschiedene Sicherheitslücken in Webanwendungen.

An dieser Stelle nehme ich natürlich abstand Beispiele zu nennen. Ungelogen hat es jedoch nicht lange gedauert bis ich eine Art Interface gefunden hatte, auf welcher mehrere Benutzer und dessen Passwort (in MD5) aufgelistet waren.

Wie geht es besser? Es sollte, bei dem Einsatz von MD5, immer eine Art Padding oder geheimen Schlüssel verwendet werden. Beispiel:

$hash = md5($passwort . „DiesIstEinGeheimerSchluessel“);

Dieser kann dann in die Datenbank geschrieben werden. Falls nun mal was passiert, sollte der Angreifer wenigstens in keiner Rainbowtable fündig werden. Moderne Hashverfahren bieten diese Funktionalität (das angeben eines Schlüssels) automatisch, aber auch mit MD5 lässt sich unter diesen Voraussetzungen arbeiten.

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