AES Verständnis Frage

[lordg2009]

Hi

Wie der Threadtitel schon sagt, habe ich eine Frage zu AES, im speziellen zum Schritt AddRoundKey:

AES nutzt in der Standardimplementierung Blöcke von 128bit. Der Schlüssel eines Nutzers wird dabei in einer 4x4-Zellen -Tabelle abgebildet, wobei jede Zelle einen bit darstellt. Anschließend wird diese Tabelle über eine XOR-Verknüpfung mit dem zu verschlüsselnden Block verrechnet. Wenn der Schlüssel zu kurz ist, wird er erweitert.

Bedeutet das nun, dass ein Schlüssel, länger als 16 Zeichen, keinen zuätzlichen Sicherheitseffekt bringt? Was wird mit dem Schlüssel angestellt, wenn er zu lang ist? Verfallen die letzten Zeichen, oder werden sie einfach noch mal XOR verknüpft, und auf 16byte gekürzt, was ja 100%ig zu Kollisionen führt?

Vielen Dank

 

[Leuli]

Mach dir den Unterschied zwischen den Begriffen Schlüssel und Passwort klar. Ein guter AES Schlüssel (z.B. in der Verwendung bei SSL/TLS) ist idealerweise von einem guten Pseudozufallsgernator erstellt. Möchtest du einen AES-Schlüssel aus einem von einem Nutzer eingebenen Passwort ableiten (z.B. wenn du Dateien auf der Festplatte verschlüsseln willst) solltest du auf keinen Fall einfach nur das Passwort verwenden, das ist viel zu unsicher weil, erstens weil es wahrscheinlich nicht genau 128bit lang ist (was ja genau deine Überlegung war) und zweitens weil bestimmte Bitfolgen viel zu häufig vorkommen (z.B. häufige Buchstaben im Alphabet). Stattdessen solltest eine Schlüsselableitungsfunktion verwenden, z.B. PBKDF2, die über Hashfunktionen und Salts einen sichereren Schlüssel aus einem Passwort erzeugt. Dieses Verfahren wird z.B. bei Passwörtern für WLAN verwendet.

 

[lordg2009]

Habe selber Festplatten mit TrueCrypt verschlüsselt. Habe zum erstellen des Passwortes folgende Seite benutzt:
http://www.passwort-generator.com/
Das Passwort ist etwas länger als 16 Zeichen (Ich glaube 20Zeichen). Was passiert denn nun mit den übrigen 4 Zeichen?

Also Verschlüsselungsmethode dient jedoch AES-serpent-Blowfish

 

[Leuli]

Dein ganzes Passwort, egal wie lang, wird über die Schlüsselableitungsfunktion PBKDF2 in einen Schlüssel passender Länge (egal wie lang) umgewandelt. Wenn du wissen willst die das funktioniert, bzw. "was mit den übrigens 4 Zeichen passiert", les dich in Kryptografie ein und dann die Erklärung zu PBKDF2. Dein Passwort wird mit einem Salt versehen und mehrmals gehasht. Es hat dann nicht mehr viel Ähnlichkeit mit dem Schlüssel, der am Ende rauskommt

Übrigens: 16 Zeichen sind nicht unbedingt 128 bit.

 

[d4nY]

Es passiert nichts mit den übrigen 4 Zeichen. Leuli hat doch gesagt, dass dein Passwort NICHT zur Verschlüsselung verwendet wird (zumindest nicht direkt), sondern dein Passwort gehasht wird.
Und Hashfunktionen haben die Eigenschaft, dass unabhängig von der Länge der Eingabe, die Ausgabe IMMER exakt die selbe Länge hat.

​Das heißt, dein Passwort kann 5, 10 oder 100.000 Stellen haben, es kommt IMMER ein Hash mit 128bit Länge dabei raus

​E: Zu langsam

 

[lordg2009]

Ahh, OK.

Ich bin von 16byte ausgegangen, weil man ja auch Sonderzeichen nutzen kann und grob überschlagen 256 Möglichkeiten pro Zeichen ausreichen könnten und außerdem mehr Zeichen also ANSI erlaubt sind (oder?).

Natürlich folgt jetzt eine ähnliche Frage mit gleicher Problemstellung:

Wenn der hash 128bit lang ist, bedeutet das zwangläufig, dass jedes Passwort, länger als 128bit Kollisionen haben muss. Ich verstehe das so, das es zu meinem 1000-Zeichen langen Passwort mindestens 1 Passwort kleiner 128bit existiert, welches den gleichen hash erzeugt und mich zu dem Schluss bringt, dass ein Passwort länger als 128bit keinen zusätzlichen Sicherheitsaspekt bringt, oder?

Interessant wäre jetzt natürlich welche Zeichenkodierung wirklich genutzt wird.

 

[d4nY]

Die Kollisionswahrscheinlichkeit hängt von der Hashfunktion ab. Es gibt Mittel und Wege die Wahrscheinlichkeit zu verringern (zB bei Checksums werden Dateigröße, Datum, Name miteinbezogen) und ich gehen davon aus, dass kryptographische Hashfunktionen zu den sichersten (in Bezug auf Kollisionen) ihrer Art gehören.

Zudem wird dein Hash (bei guten Implementierungen) auch noch gesalzen, das heißt, mit einem zufälligen Wert verknüpft und dann wieder gehasht...und wieder und wieder und wieder
Dass es da mal zu Kollisionen kommt ist wohl sehr, sehr, sehr unwahrscheinlich

Die Länge deines Passwortes ist also für den reinen Algorithmus total uninteressant und bietet auch nicht mehr oder weniger Sicherheit. Du sollst lange Passwörter wählen, denn je länger dein Passwort ist, desto aufwendiger wird das durchprobieren

 

[Leuli]

Deine Frage macht keinen Sinn bzw. ich versteh die Frage nicht. Ich glaube prinzipiell hast du das mit den Hashfunktionen schon richtig verstanden. Es existieren verschiedene Eingaben, die den selben Hashwert erzeugen (=Kollisionen). Du kannst aber nicht mit Sicherheit sagen, dass es zu einem 1000 Zeichen langen Passwort (also deiner Eingabe) mindestens ein Passwort (also eine andere Eingabe) gibt, dass den gleichen Hash erzeugt. Zumindest nicht bei Hashfunktionen, die als sicher gelten (z.B. SHA-256). Und erst recht kannst du daraus nicht folgern, dass ein kürzeres Passwort über Länge X keine zusätzliche Sicherheit bringt.
Ich würde das eher so sehen: Ein (gutes) langes Passwort erhöht die Entropie deiner Eingabe und damit deine Sicherheit. Die Entropie kannst du hierbei als "Zufälligkeit" verstehen.
Generell: Häng dich nicht so an Bits auf und les dir mal den Wikipedia Artikel zu Hashfunktionen durch, vielleicht verstehst dus dann besser.

Und: ANSI ist keine Zeichencodierung. Und die Zeichencodierung spielt mMn auch keine Rolle bei der Erzeugung deinens Passworts.

 

[lordg2009]

Hey danke, ich schätze eure Antworten sehr, aber ich bleibe trotzdem mal stur, um mein Anliegen richtig darzulegen, da ich mich schon mit Hashfunktionen beschäftigt habe und auch weiß, was ein Salt ist.

Ein Rechenbeispiel:
Ein Schlüssel der Länge 128bit bietet 2^128 verschiedene Schlüssel.

Ein Hashalgorythmus, der bezüglich Kollisionen perfekt ist, könnte aus 2^128 Passwörtern 2^128 verschiedene hashes erzeugen.

Dies würde bedeuten, dass ich alle Schlüssel mit Passwörtern bis 128bit darstellen kann.

Das wiederum würde beudeuten, dass ein Passwort, länger als 128bit einen hash erzeugt, der auch mit einem Passwort bis 128bit erzeugt werden kann.

Daraus folgt: Ein Passwort länger 128bit bietet beim reinen Brute-Forcing keinen Sicherheitsmehrwert, da genau eine Kollision bis zu einer Länge von 128bit existiert. Bewusst rede ich hier von "genau eine" da ich von der hypothetisch Kollisionsperfekten Hashfunktion spreche, die jedes Passwort bis 128bit in einen einzigartigen hash umwandeln kann.

Bei einer Kodierung, wo ein Zeichen 8bit braucht, wären das 16 Zeichen.

In der Realität gibt es einzelne Kollisionen und es wird einzelne hashes geben, die sich nicht mit einem Passwort bis 128bit Länge erzeugen lassen. Da diese Fälle aber bei einer guten hashfunktion die Minderheit die darstellen, gilt wieder oben genannte Annahme. So dass es wahrscheinlich ist, das beim Bruteforcen meines Schlüssels, der 1000 Zeichen lang ist, ein Passwort bis zu einer Länge von 128bit gefunden wird, dass den gleichen hash erzeugt.

Ergänzung (4. Dezember 2013)

Sry, ich meine natürlich ASCII. Die Kodierung spielt nicht direkt eine Rolle.
Aber:
Eine Kodierung mit 8bit würde im 128bit Passwort doppelt so viele Zeichen unterbringen, wie eine hypothetische Kodierung mit 16bit pro Zeichen, dafür aber eine sehr viel größere Auswahlmöglichkeit an verschiedenen Zeichen erlauben. Nutze ich nach Zufall all die zur Verfügun stehenden Zeichen gibt es keinen Unterschied. Benutze ich aber trotzdem nur Buchstaben und Zahlen, wäre mein Passwort sehr viel schneller zu knacken.

Ergänzung (4. Dezember 2013)

Das klang jetzt wie eine Aussage, aber es ist meine Vorstellung der Funktionsweise, die ich euch auf Korrektheit zu überprüfen bitte.

 

[zeanzean]

Ein Hashalgorythmus, der bezüglich Kollisionen perfekt ist, könnte aus 2^128 Passwörtern 2^128 verschiedene hashes erzeugen.
Das wiederum würde beudeuten, dass ein Passwort, länger als 128bit einen hash erzeugt, der auch mit einem Passwort bis 128bit erzeugt werden kann.
Daraus folgt: Ein Passwort länger 128bit bietet beim reinen Brute-Forcing keinen Sicherheitsmehrwert, da genau eine Kollision bis zu einer Länge von 128bit existiert. Bewusst rede ich hier von "genau eine" da ich von der hypothetisch Kollisionsperfekten Hashfunktion spreche, die jedes Passwort bis 128bit in einen einzigartigen hash umwandeln kann.
In der Realität gibt es einzelne Kollisionen und es wird einzelne hashes geben, die sich nicht mit einem Passwort bis 128bit Länge erzeugen lassen. Da diese Fälle aber bei einer guten hashfunktion die Minderheit die darstellen, gilt wieder oben genannte Annahme. So dass es wahrscheinlich ist, das beim Bruteforcen meines Schlüssels, der 1000 Zeichen lang ist, ein Passwort bis zu einer Länge von 128bit gefunden wird, dass den gleichen hash erzeugt.

Wenn man von deinem Modell ausgeht hast du Recht, in der Praxis werden (sollten) Hashes auch noch mit einem Salt versehen werden womit deinen benannten Kollisionen aus dem Weg gegangen wird, da selbst wenn z.B. abc und abcdefgh den gleichen Hash ergeben sollten, bei beiden ein anderer Salt benutzt wird und damit der Hash nicht mehr gleich ist.
Bruteforcing gegen ein Passwort wird sowieso IMMER effektiv bleiben, weswegen "sichere" Seiten sich dagegen schützen müssen.
Den Algorithmus an sich abzusichern ist viel interessanter, da dieser z.B. keinen Timeout nach 5 versuchten Schlüsseln hat, und den Schlüsselraum von AES zu bruteforcen ist mit momentaner Rechenleistung ziemlich utopisch.

 

[lordg2009]

Danke für die Antwort. Zu wissen, dass man nicht falsch gedacht hat, tut ja auch gut. Über deinen Einwand der Sicherung habe ich mir auch schon Gedanken gemacht. Habe auf meinem Heimserver vpr längerer Zeit fail2ban installiert. Das realisiert den von dir beschrieben Timeout für zB Apache, ProFTP, SSH und noch einige weitere Anwendungen.