Re: NetworkManagerInfo/nm-applet development question



Here's the actual code...it looks like there was
originally a cut and paste error in the mix as well
since there are two parts: first some extra characters
at the end of the passphrase and additionally the
first bytes of the WEP key are skipped in the
additional keys.

if (weptype == 128)
{
   strcpy(str,genstr);
   wep128_passphase(str,key);
   memcpy((unsigned char *)&key128[0], (unsigned char
*)&key[0], 13);

   strcat(str,"#$%");
   wep128_passphase(str,key);
   memcpy((unsigned char *)&key128[1], (unsigned char
*)&key[1], 13);

   strcat(str,"! #");
   wep128_passphase(str,key);
   memcpy((unsigned char *)&key128[2], (unsigned char
*)&key[2], 13);

   strcat(str,"%&^");
   wep128_passphase(str,key);
   memcpy((unsigned char *)&key128[3], (unsigned char
*)&key[3], 13);
}

Again, I don't want to fight a security battle; I'm
just looking at ease-of-use.


--- Dan Williams <dcbw redhat com> wrote:

> On Mon, 2005-08-08 at 09:45 -0700, Eric Wenger
> wrote:
> > Don't get me wrong...the key indexes are silly and
> > insecure (they simply obfuscate the passphrase
> which
> > doesn't make WEP any more secure).  The problem is
> > that NM cannot connect to a Linksys router unless
> you
> > are using the first key index.  I had mine set to
> key
> > index 3 and NM won't connect even if the
> ifcfg-eth1
> > and keys-eth1 are setup properly since NM
> generates
> > it's own WEP key from the passphrase.  It doesn't
> grab
> > the information (defaultkey, key1,key2, etc.) from
> > your keys-ethX files.
> 
> The keygen routines for these routes may "salt" the
> key with the index
> number before writing out the hex?  I'm not sure,
> but we may want to
> allow this in NM...
> 
> Dan
> 
> 

---------------------------------------------------------
Eric Wenger
eric_wenger yahoo com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]