What are the technical requirements for a WPA-PSK passphrase?

Question

I was thinking of generating a WPA-PSK passphrase, and I see in the OpenBSD manpage for wpa-psk(8):

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

What exactly is the criteria for "ASCII-encoded" here? Just that they must be 8-bit chars with the high bit unset? Are non-printable characters allowed?

Come to think of it... 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?

Solution 1

What exactly is the criteria for "ASCII-encoded" here? Just that they must be 8-bit chars with the high bit unset? Are non-printable characters allowed?

Wikipedia's Wi-Fi Protected Access says the WPA-PSK passphrase is 8 to 63 printable ASCII characters, and includes this reference as a footnote:

Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal), inclusive. (IEEE Std. 802.11i-2004, Annex H.4.1) The space character is included in this range.

Come to think of it... 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?

I think I'll still just generate 256 bits using a secure RNG...

Does your wireless router and every device you want to connect to your wireless network let you manually enter the WPA-PSK key as 64 hex characters? If not, then you may have to use an ASCII passphrase to be able to enter it in all of your devices.

Solution 2

From http://www.xs4all.nl/~rjoris/wpapsk.html - "WPA key calculation - From passphrase to hexadecimal key Details of the Calculation":

For WPA-PSK encryption, the binary key is derived from the passphrase according to the following formula:

The function PBKDF2 is a standardized method to derive a key from a passphrase. It is specified in RFC2898 with a clear explanation on how to compute it. The function needs an underlying pseudorandom function. In the case of WPA, the underlying function is HMAC-SHA1. SHA1 is a function that computes a 160-bit hash from an arbitrary amount of input data. It is clearly explained in RFC3174. HMAC is a standardized method to turn a cryptographic hash function into a keyed message authentication function. It is specified in RFC2104.

To summarize, the key derivation process involves iterating a HMAC-SHA1 function 4096 times, and then doing that again to produce more key bits. The amount of computation involved is equivalent to computing the SHA1 hash over 1 MByte of data. Perhaps that explains why the Javascript on this page is so slow.

As for your question: 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?: Either one would be very strong, as long as you used all kinds of symbols, numbers, and random alphabet characters in your random bytes passphrase. The way I look at it: both of them (generated or random) would be impossible to guess/hack...

Comments

[asveikau]

Hm. So it would seem based on my reading of the RFC that the PBKDF2 function doesn't depend on it being printable ASCII characters, and should do fine with binary data. I think I'll still just generate 256 bits using a secure RNG... (I'm not so confident it would be impossible to guess though. There are small odds that this will end up generating something that happens to collide with a weak passphrase. :P)

[asveikau]

From RFC2898 cited by @studiohack - Throughout this document, a password is considered to be an octet string of arbitrary length whose interpretation as a text string is unspecified. In the interest of interoperability, however, it is recommended that applications follow some common text encoding rules. ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of UTF-8.)

[asveikau]

Also, it seems that OpenBSD, Linux, Windows, and Mac OS X all support using hex keys. The only problem I have encountered is the Maemo UI not liking it -- but the XML file that backs the configuration supports it.

[asveikau]

OK, I see the part of 802.11i-2004 that says that. You're right.