[lug] wireless points in Boulder (fwd)

Ferdinand Schmid fschmid at archenergy.com
Mon Apr 8 15:53:18 MDT 2002


"M. Warner Losh" wrote:
> 
> : Date: Fri, 05 Apr 2002 16:49:09 -0700
> : From: Ferdinand Schmid <fschmid at archenergy.com>
> : Reply-To: lug at lug.boulder.co.us
> : To: lug at lug.boulder.co.us
> : Subject: Re: [lug] wireless points in Boulder (fwd)
> 
> First off, you should really be complaining that WEP is billed as
> having security at all, rather than quibbling over how many bits it
> has :-).
> 
> : I disagree - if someone tells me they are doing 64bit encryption then I
> : don't want to see the first 24 bits wasted for a plain text IV.  Some
> : companies actually call this 40 bit encryption (D-link and other
> : vendors).
> 
> Those aren't a plain text.  They are bits of the key that are included
> in the packet.  There's at least a terminology difference.
> 
> The cipher text of each packet is computed using the 40bit secret key
> appended to the 24 bit IV.  The 24 bit IV is inserted into the
> "plaintext" part of the packet so that the receiver can take it, and
> the locally stored 40bit key to decrypt the ciphertext back into the
> plaintext.  Each packet has its own IV, so that part of the key
> changes each time.
> 
> So each packet is indeed encrypted with a 64bit key.  The trouble is
> that 24bits of that key are disclosed to the user.  If the encryption
> scheme was good, such leakage wouldn't matter at all.  However, the
> RC4 scheme used in WEP has a weakness in that, under certain
> circumstances, if you know some of the bits of the key, you can glean
> information about other bits of the key.  That's what makes the IV so
> bad: about 3000 of the 16M keys are bad like this.  When they are
> used, then you leak information about the other bits.  If WEP used a
> different algorithm that didn't have this leaking property, you'd
> still be no better off than before.  The problem would still be as
> hard as cracking a 64 bit key because knowledge of the 24bits of IV
> doesn't reduce the strength of the encryption.
> 
> Well, that's not entirely true (since you'd only have to look at 2^40
> possibilities rather than 2^64 possibilities in a bute force search),
> but since the numbers of bits are so small this makes little practical
> difference.  Brute force breakage happens on the order of days or
> weeks either way.  The problem with RC4 based encryption schemes is
> that with weak IV's you don't have to search a possible space 2^40,
> but one that's significantly smaller if you have enough traffic to
> guess.  Reports say that on the order of 1000 packets of bad IVs lets
> you limit your search to a few keys that are easy to try by brute
> force.
> 
> s/64/128/ as needed for the 128 bit version :-)
> 
> : Otherwise I could fill a 256 bit key with 128 bits of garbage and only
> : use the last 128 bit and call this 256 bit encryption.  The actual
> : encryption algorithm however only uses 128 bit so cracking it only
> : requires cracking 128 bits and not 256 bits.
> : This nomenclature would be (and is) very deceiving to end users.
> 
> Yes, but that's not what's happening.  See above.  The bits are
> actually used to do the de/encryption, and are therefore not garbage.

For brute force cracking 2^64 is a 20 million times greater number than
2^40.  So it takes the same hardware 20 million times as long to to
crack a 64 bit key compared to the 40 bit key.  I am fully aware that
the IV is used as part of the key and that its main weakness are the bad
(guessable) 1k keys (which new hardware is going to skip).  

My critizism was simply pointed at the marketing folks who like to blurr
the nomenclature to make their product shine.  The term WEP itself is
another terrible!  Non technical users actually believe this.  I just as
much disagree with assuming a factor of 2 for the compression (capacity)
on backup tapes...

> 
> Warner
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

-- 
Ferdinand Schmid
Architectural Energy Corporation
Celebrating 20 Years of Improving Building Energy Performance
http://www.archenergy.com



More information about the LUG mailing list