Was sind die technischen Anforderungen für eine WPA-PSK-Passphrase?

8

Ich habe darüber nachgedacht, eine WPA-PSK-Passphrase zu generieren, und ich sehe in der OpenBSD-Manpage für wpa-psk(8):

The passphrase must be a sequence of between 8 and 63
ASCII-encoded characters.

Was genau sind hier die Kriterien für "ASCII-codiert"? Nur dass es sich um 8-Bit-Zeichen handeln muss, bei denen das High-Bit nicht gesetzt ist? Sind nicht druckbare Zeichen erlaubt?

Kommen Sie und denken Sie darüber nach ... Ist mein Ansatz, zufällig eine Passphrase zu generieren, sinnvoll? Wäre es besser, nur 64 zufällige Bytes zu generieren und diese als Schlüssel zu verwenden?

— asveikau
quelle

12

> Was genau sind hier die Kriterien für "ASCII-codiert"? Nur dass es sich um 8-Bit-Zeichen handeln muss, bei denen das High-Bit nicht gesetzt ist? Sind nicht druckbare Zeichen erlaubt?

Laut dem Wi-Fi Protected Access von Wikipedia besteht die WPA-PSK-Passphrase aus 8 bis 63 druckbaren ASCII-Zeichen und enthält diese Referenz als Fußnote:

Jedes Zeichen in der Passphrase muss eine Codierung im Bereich von 32 bis einschließlich 126 (dezimal) haben. (IEEE Std. 802.11i-2004, Anhang H.4.1)
Das Leerzeichen ist in diesem Bereich enthalten.

> Kommen Sie und denken Sie darüber nach ... Ist mein Ansatz, zufällig eine Passphrase zu generieren, sinnvoll? Wäre es besser, nur 64 zufällige Bytes zu generieren und diese als Schlüssel zu verwenden?

> Ich denke, ich werde immer noch nur 256 Bit mit einem sicheren RNG generieren ...

Können Sie mit Ihrem WLAN-Router und jedem Gerät, das Sie mit Ihrem WLAN verbinden möchten, den WPA-PSK-Schlüssel manuell als 64 Hex-Zeichen eingeben? Wenn nicht, müssen Sie möglicherweise eine ASCII-Passphrase verwenden, um sie auf allen Ihren Geräten eingeben zu können.

— Bavi_H
quelle

Aus RFC2898, zitiert von @studiohack - In diesem Dokument wird ein Kennwort als eine Oktettzeichenfolge beliebiger Länge betrachtet, deren Interpretation als Textzeichenfolge nicht angegeben ist. Im Interesse der Interoperabilität wird jedoch empfohlen, dass Anwendungen einige gängige Textcodierungsregeln befolgen. ASCII und UTF-8 [27] sind zwei Möglichkeiten. (ASCII ist eine Teilmenge von UTF-8.)

— Asveikau

Es scheint auch, dass OpenBSD, Linux, Windows und Mac OS X die Verwendung von Hex-Schlüsseln unterstützen. Das einzige Problem, auf das ich gestoßen bin, ist, dass die Maemo-Benutzeroberfläche es nicht mag - aber die XML-Datei, die die Konfiguration unterstützt, unterstützt es.

— Asveikau

OK, ich sehe den Teil von 802.11i-2004, der das sagt. Du hast recht.

— Asveikau

1

Von http://www.xs4all.nl/~rjoris/wpapsk.html - "WPA-Schlüsselberechnung - Von der Passphrase zum Hexadezimalschlüssel Details der Berechnung":

Bei der WPA-PSK-Verschlüsselung wird der Binärschlüssel gemäß der folgenden Formel aus der Passphrase abgeleitet:

Die Funktion PBKDF2 ist eine standardisierte Methode, um einen Schlüssel aus einer Passphrase abzuleiten. Es ist in RFC2898 mit einer klaren Erklärung zur Berechnung angegeben. Die Funktion benötigt eine zugrunde liegende Pseudozufallsfunktion. Im Fall von WPA ist die zugrunde liegende Funktion HMAC-SHA1. SHA1 ist eine Funktion, die aus einer beliebigen Menge von Eingabedaten einen 160-Bit-Hash berechnet. Dies wird in RFC3174 klar erläutert. HMAC ist eine standardisierte Methode, um eine kryptografische Hash-Funktion in eine Authentifizierungsfunktion für verschlüsselte Nachrichten umzuwandeln. Es ist in RFC2104 angegeben.

Zusammenfassend besteht der Schlüsselableitungsprozess darin, eine HMAC-SHA1-Funktion 4096 Mal zu iterieren und dies dann erneut zu tun, um mehr Schlüsselbits zu erzeugen. Der Rechenaufwand entspricht der Berechnung des SHA1-Hash über 1 MByte Daten. Vielleicht erklärt das, warum das Javascript auf dieser Seite so langsam ist.

Zu Ihrer Frage Does my approach of randomly generating a passphrase make any sense? Would it be better to just generate 64 random bytes and use that as a key?:: Beide wären sehr stark, solange Sie alle Arten von Symbolen, Zahlen und zufälligen Alphabetzeichen in Ihrer Passphrase für zufällige Bytes verwendet haben. So wie ich es sehe: Beide (generiert oder zufällig) wären unmöglich zu erraten / zu hacken ...

— Studiohack
quelle

1

Hm. Aufgrund meiner Lektüre des RFC scheint die PBKDF2-Funktion nicht davon abhängig zu sein, dass es sich um druckbare ASCII-Zeichen handelt, und sollte mit Binärdaten gut funktionieren. Ich denke, ich werde immer noch nur 256 Bit mit einem sicheren RNG generieren ... (Ich bin nicht so sicher, dass es unmöglich ist zu erraten. Es gibt kleine Chancen, dass dies etwas erzeugt, das zufällig mit einem Schwachen kollidiert Passphrase .: P)

— Asveikau