Einzelnen Beitrag anzeigen

Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#8

Re: Mit DEC verschlüssel. Wie groß ist die Schlüssellänge?

  Alt 25. Mär 2007, 18:51
Nöö

Es geht dabei um die Entropie in unserer Sprache im Vergleich zu der benutzten Codierung im ASCII Symbolraum. Ein ASCII benötigt für 256 Zeichen exakt 8 Bits pro Zeichen um das zu kodieren. Mit diesen Symbolsatz arbeiten wir in Computern. Aber wir benutzen in unseren Passwörtern nur eine geringe Anzahl von diesen Symbolen, dh. wir codieren unser Passwort nicht so optimal das es nicht weiter komprimierbar wäre. Eine verlustfreie Komprimierung ist immer ein Prozess bei dem Redundanzen entfernt werden, oder anders ausgedrückt die Entropie erhöht werden soll. Englische und Deutsche Wörter/Sätze entalten nur eine Entropie von ca. 3.6 Bit auf 8 Bit. Wir können solche Texte durchschnittlich um 55% komprimieren, einfach durch bloße Umkodierung im benutzten Symbolraum.

Ein Cipher benutzt aber den vollen Symbolraum des Passwortes, nur das unser Passwort nur 0.45 aus diesem Symbolraum real benutzt. Um das zu kompensieren müssen wir also exakt 2.2 mal längere Passwörter benutzen als wir Zeichen in unserem Cipher benutzen können. Beispiel: AES 128 Bit = 16 Symbole * 2.2 = 35 Zeichen Passwörter wären angebracht um die gleiche Sicherheit wie 128Bit binäre Zufallspasswörter zu erreichen. Da aber AES keine "Schlüsselkomprimierungsfunktion" benutzt können wie keine 35Zeichen = 35*8= 280Bit langen binären Paswörter benutzen. Maximal sind es 256 Bit = 32 Zeichen lange Passwörter die vergleichbar wären mit einem echten 115 Bit binärem Zufallspasswort. Also nochmal

AES 256 Bit = 32 Zeichen, 32 Zeichen Passwort entspräche in der Entropie einem 32 * 3.6 = 115 Bit binärem Zufalls Schlüssel. Ergo: werden die Passwörter ohne Preprozessing = Komprimierung der Entropie, benutzt so werden wir AES 256 Bit benutzen müssen und erreichen aber nur eine reale Sicherheit von 115 Bit Sicherheit. Da die meisten Tools Passwörter direkt mit AES benutzen, ja sogar fast alle, ist es logisch das man immer mit AES 256 verschlüsseln muß bei 32 Bytes Passwörtern aber nur real weniger als eine AES 128 Bit Verschlüselung an Sicherheit hat.

Es ist also enorm wichtig das das reale Passwort vorher in einen Sessionkey umgewandelt wird. Idel dazu sind KDFs -> Key Derivation Functions die aus Hash Algorithmen beruhen. Man kann dann ein zb. 72 Zeichen langes Passwort in einen 256 Bit langen binären Wert "komprimieren" (hashen). 72 Zeichen a 3.6 Bit / 8 Bit = 256 Bit. Die KDF entfernt quasi per Kompression, und Hashfunktionen sind Kompressorfunktionen, die Redundanzen im Passwort relativ gesehen zum benutzen Symbolraum des ASCII Zeichensatzes. Damit man also AES 256 wirklich sicher benutzen kann mit maximaler Sicherheit von 256 Bits MUSS man unbedingt vorher das Passwort in einen binären Sessionkey umwandeln und das Passwort muß 72 Zeichen enthalten. Macht man dies nicht, leider fast schon Standard, so kann man nur 32 Zeichen lange Passwörter benutzen. Man muß dann wirklich alle möglichen 256 Zeichen auch benutzen, was wir aber eben nicht tuen. Ergo entsteht eine reale Sicherheit von nur 115 Bits mit einem AES 256 Cipher.

Was ich damit im Grunde aussagen will ist das die Angabe "AES 256" rein garnichts aussagt und genauso sicher/unsicher sein kann wie ein AES 128 der korrekt benutzt wird.
Es wird also sehr oft dem Unkundigen mit Zahlenangaben imponiert (Werbung) ohne das es Relevanz hat.

Offline Brute Force Angriffe per Dictionaries/Rainbowtabellen beruhen exakt auf diesem Fakt. Ein zb. 6 Zeichen langes Passwort wäre vergleichbat mit einem 22 Bit langem Binärwert. Unser durch Brute Force Angriff zu durchsuchender Schlüsselraum beträgt also 2^22 = 4,2 Millionen Schlüssel. Das ist fast schon lächerlich wenig und zeigt auch das unser Online Banking schon fast lächerlich unsichere Schlüssellängen benutzt. Normal sollte man 128 Bit binäre Schlüssel benutzen um Brute Force ausschließen zu können. Einzigst der Fakt das nach 3 ungültigen Loginversuchen der Online Banking Server den Account sperrt verhindert solche Angriffe, wenn sie online durchgeführt werden. Sollte aber der Server hijacket sein und man kann eine offline Attacke auf die DB durchführen ist diese Sicherheitsstufe schon grob fahrlässig.

Gruß Hagen
  Mit Zitat antworten Zitat