Bug 199786

passphrases for 128 bit keys are supported - do you mean 64 bit ascii keys?  We tried to implement this but there does not seem to be a standard hashing algorithm for 40/64 bit.  What worked on one router failed on another.

(In reply to comment #1)
> passphrases for 128 bit keys are supported - do you mean 64 bit ascii keys?  We
> tried to implement this but there does not seem to be a standard hashing
> algorithm for 40/64 bit.  What worked on one router failed on another.
Hi Will, thanks for your reply.
I am indeed talking about ASCII keys, but I'm not sure how much bit they are. 
I don't see why there would be a problem with the hashing algorithm; I suppose you use iwconfig underneath, and using the "key s:<asciikey>" parameter automatically converts ASCII to HEX. And of course it was working perfectly before in the KDE 3.5 version :)

NM uses wpa_supplicant internally, but that's an implementation detail.  It expects to be given the hashed hex key, derived from the ascii key or passphrase by the applet.  For 40/64 bit WEP there is no standard algorithm, so the algorithm used in KDE 3.5 knetworkmanager worked for some people and not for others depending on the AP used, so we took the decision to remove it.

PS you can see your key length with iwconfig once you are connected, it will be either 10 or 26 hex digits long.

I don't think iwconfig shows the length of the key, but here is the complete (obfuscated (x)) output:

$ iwconfig wlan0
wlan0     IEEE 802.11abg  ESSID:"accesspoint"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:DE:AD:BE:EF:11
          Bit Rate=54 Mb/s   Tx-Power=15 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Encryption key:xxxx-xxxx-xx   Security mode:open
          Power Management:off
          Link Quality=77/100  Signal level:-57 dBm  Noise level=-90 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Then there's also this:

$ sudo iwlist wlan0 keys
wlan0     2 key sizes : 40, 104bits
          4 keys available :
                [1]: xxxx-xxxx-xx (40 bits)
                [2]: off
                [3]: off
                [4]: off
          Current Transmit Key: [1]
          Security mode:open

I hope it's of any use to you, please let me know if you need more information.

xxxx-xxxx-xx - 10 x's 

Also the

[1]: xxxx-xxxx-xx (40 bits)

line tells me it's a 10-digit key - 40 bit WEP uses 10 hex digits, 104 bit uses 26.

Sorry I can't do more for you - it was luck that KDE 3 knetworkmanager used the same algorithm as your AP, but we had a lot of bug reports from people who it didn't work for.

See this site for why generating 40 bit WEP keys from passphrases cannot work reliably unless you control both the AP software and the client software. 

http://www.csgnetwork.com/wepgeneratorcalc.html

The generator at that site hashes the string "maryhadalittlelamb" to a different value that the Netgear AP I'm testing with.

Okay, no problem, WEP is deprecated anyway.

I have one last question though, how can the wireless manager in Windows XP or MacOS X know which algorithm to use? And it seems like iwconfig with the "key s:" option also knows this, or am I seeing this wrong?

Thanks for your time.

I don't know. 

Perhaps it works by coincidence with your APs. Perhaps I'm wrong, but I don't have time right now to investigate.   If you have a look at the iwconfig sources and see what it does, I could use that information later on to add a reliable set of hashing functions.

I appreciate the difficulties with 64bit WEP keys. 

However, I submit that it is preferable to permit a user to attempt connection using the algorithms that were formerly permitted, albeit with a warning message that usage is deprecated and may not work. Even if it doesn't work with half the connections it is not rational to deny any connections via this method.

In any event, I would suggest that when a user attempts to enter a 64bit WEP key, rather than just having their connection refused, a message should display explaining why their connection isn't working, and what they may do to about (get a HEX key, or use WPA for example). 

This would at least prevent some users worrying what was going wrong with their computer, and attempting all kinds of fixes (aggravated further since they may have no internet connection to research the problem, and if their WEP key and connection used to work fine with KDE or Windows).

Downstream: https://bugzilla.novell.com/show_bug.cgi?id=498284
https://bugs.edge.launchpad.net/ubuntu/+source/plasma-widget-network-manager/+bug/339313/comments/88

Kubuntu bug moved to https://bugs.launchpad.net/knetworkmanager/+bug/453260

SVN commit 1038524 by wstephens:

Allow WEP keys to be entered as ASCII (not passphrases).

I misunderstood the bug report initially, confusing the simple
conversion of an ascii string to pairs of hex digits with the passphrase
hashing approach.

BUG: 199786


 M  +16 -4     backends/NetworkManager/settings/802-11-wireless-securitydbus.cpp  
 M  +1 -1      libs/ui/security/wep.ui  
 M  +18 -20    libs/ui/security/wepwidget.cpp  
 M  +2 -0      libs/ui/security/wirelesssecuritysettingwidget.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1038524