Land of Confusion
Since NetworkManager 0.7 came out, there’s one issue that’s been causing confusion with lots of users: hashed network keys. That passphrase you type into the box when you connect to a WiFi network using any OS isn’t what actually gets used; instead it’s hashed to come up with the real key. There are a few different ways to enter an encryption key for a WiFi network, so bear with me:
- Hex: works with both WEP and WPA, and is the most compatible since it actually is exactly what gets sent to the driver as the encryption key. For WEP, this is either a 10 character (for 40-bit WEP) or a 26 character (for 104-bit WEP) string composed of hexadecimal characters. For WPA it’s a 64 character hexadecimal string. Typing in 64 hexadecimal characters gets old pretty fast, which leads us to…
- Passphrase: a string of arbitrary characters that is hashed into the actual key to be used. WEP passphrases have no real size restrictions, and are repeated into a 64-byte buffer before being hashed with MD5. At least the creators of WPA learned from experience, specifying that WPA passphrases are between 8 and 63 characters inclusive, which means you can actually autodetect whether it’s a passphrase or a hex key, unlike WEP passphrases. WPA passphrases are hashed using SHA-1 into the real encryption key.
- ASCII key: Thanks, Lucent. The original WaveLAN cards used passphrases of 5 or 13 ASCII characters, which some drivers and people still use for God knows what reason. To hash it, take the two-byte ASCII value of each character and stuff them into a buffer. Not secure at all.
- Apple passwords: in their infinite wisdom, Apple chose a completely different hashing mechanism for WEP. This means that to connect a non-Apple computer to an Airport WEP network, you need the “Compatible Network Password”, ie the hexadecimal WEP key. At least they stuck with the standard for WPA.
The huge pain with WEP is that you simply cannot autodetect what type of key the user has entered. Since WEP passphrases can also be composed of 10 or 26 hexadecimal characters, it’s impossible to differentiate between a WEP hex key, a WEP passphrase, or a WEP 104-bit ASCII key. Which means the user has to know what WEP key type they are using. FAIL. They also have to know whether the network uses 40-bit or 104-bit encryption, and whether it uses Shared Key authentication or Open System authentication. That’s 12 different possible WEP configurations.
WEP == MASSIVE USER FAIL
In any case, NetworkManager 0.7 required pre-hashed keys for reasons I don’t accurately remember, possibly related to bad trips from the NM 0.6 API that I mis-designed. So the applet hashed your passphrase right after you entered it and stored the hashed key in the keyring. Unfortunately, when the driver failed to connect and NetworkManager asked for your secrets again, all you saw was something you certainly don’t remember typing in. While this actually was your passphrase, and it would work when you hit OK, it certainly was confusing.
Change We Can Believe In
As of Saturday, you’ll always see what you typed in. The real fix is to simply connect the first time and never ask for your passphrase again, but that’s almost always due to driver and supplicant bugs that can and should be fixed; I’ve spent weeks of my life doing just that. Of course, that can only reliably happen in open-source drivers; at least when we find the bugs we can fix them. Which is why you really don’t want any of these.