On Thu, 9 Nov 2000, Jared Mauch wrote:
> --- snip ---
>
> Subject: 802.11b networks
>
--- snip ---
>
> This also brings into key play a few important aspects:
>
> The wireless encryption supported inside the USA tends to be 56 or
> 128 bit. A modern computer could be used to take a data stream in
> the air, and write it to disk, then try various keys to decode the data.
>
> It would not be dificult to try each of the 56 bit patterns on
> data that is stored, and would require little effort to break the key
> that would unlock the wireless network security. There are
> 72,057,594,037,927,936 combinations are available for 56 bit encryption.
> Assuming a moderate speed of 1M keys tried per second to decode data,
> and performing a validation of looking for valid IP packet headers,
> one can identify decoded data rather quickly. If you also
> only try valid printable ascii keys for the encryption, one can
> also increase the search time for a valid key to unlock the data.
>
Disclaimer: I'm not a crypto geek nor even particularly good at math.
A while ago I heard a similar assertion that the implementation
of this encryption wasn't too strong. I accepted it at face value
since it triggered in my mind that there might be some known-text
type of approach that could be brought to bear since I can imagine
that much of the regular traffic on ethernets have some known
fingerprints (eg. ARP requests/replies). However, taking the
example above I break down the calculation this way:
prompt-~114: bc -l
2^56/(1000000*60*60*24*365)
2284.93131779325012683916
(Denominator: 1Mkeys/sec*60sec/min*60min/hr*24hr/day*365day/year)
That is: well over 2,000 years to move through all possible 56-bit keys.
Is this right? I don't know anything about how quickly or craftily
brute-force attacks can actually move.
Tony
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:20 EDT