I'm a bit confused at how wireless client utilities generate WEP keys from user-supplied strings. I've seen two methods. The first method converts a user-supplied string to a 56- or 104-bit integer from the string's ANSI character values. For example, the string [b]ABCDEFG[/b] would be converted to hex [b]41424344454647[/b].
But what if the user-supplied string contains fewer than seven characters for a 56-bit key, or fewer than 13 characters for a 104-bit key? Does the client utility right-pad the string with NULLs? Are there standand rules for this type of WEP key generation?
The second WEP key generation method involves converting a string (typically called a [i]passphrase[/i]) to four different WEP keys. What is the algorithm for this conversion? The same passphrase always results in the same keys, so it can't be anything too complex.
I started wondering about this after reading a short discussion on using a dictionary attack to decypher WEP keys. Keys derived from strings that are easily cracked by standard password cracking programs (such as L0phtCrack) should also be easy to crack. Stings derived from strong password generation rules would be more difficult--if not impossible--to crack using a convetional dictionary attack.
Any good rules for selecting the passphrases used to generate WEP keys? Just use the same rules for creating strong, conventional passwords?
Wep keys are either 64 bit or 128 bit. The Initialization Vector is 24 bits. So wep key lengths are actually 40 bits and 104 bits. You can enter the wep keys in alphanumeric Hex or ASCII format depending on what the manufacture will allow. The number of characters entered depends on whether you enter the wep key in ASCII or Hex. If entered in Hex you must enter 10 characters for 64 bit and 26 characters for 128 bit ASCII must be 5 characters for 64 bit and 10 for 128 bit.
WEP is based on the RC4 algorithm, which is a symmetric key stream cipher.
A stream cipher encrypts data by generating a key stream from the key and performing the XOR function on the key stream with the plain-text data. The key stream can be any size necessary to match the size of the plain-text frame to encrypt .
Stream Cipher Operation
key > cipher > key stream > xor < plain text = cipher test
oops!! ASCII 128 bit should be 13 characters and not 10. Sorry for the confusion.
Yes, you are correct that the WEP key is 40-bits and not 56-bits (I was thinking of DES).
And I do realize that a single string character is equivalent to two hex digits. However, RC4 and Initialization Vectors don't seem to be part of the answer to my questions. I am only concerned with how the WEP keys are generated by the wireless client utility and not how they are actually used.
There is an old 40-bit WEP key generation vulnerability (the "21 bit bug") that was exploited by Tim Newsham's WEP Tools. For the way to fix it, check out dwepkeygen from the BSD airtools. Since there isn't any specific documentation coming with it, you'll have to resort to reading the dwepkeygen.c source. Of course, the methodology applied by dwepkeygen is applicable to generating 108 bit keys and, probably, TKIP keys as well.
The later is quite an important topic now, since it can open an avenue of attacks against TKIP in SOHO mode (PSK). Check out
if you haven't read it before.
I read through dwepkeygen.c and it's just a program to generate a "safe" 40-bit WEP keys based on a seed (i.e. random number) supplied by the user. I'm looking for code that generates a WEP key based on a passphrase.
But I must say, the web site it's on (http://www.dachb0den.com) is *VERY* interesting.