From: pen-test@nym.hush.com
Date: Thu Jun 03 2004 - 16:36:05 EDT
> Just convert both the plaintext and ciphertext to binary, and
> figure out what you need to XOR the plaintext with to get the
> ciphertext, one bit at a time to recover the key sequence of n
> bytes, right?
Actually, you'd XOR the plaintext and ciphertext. Here's an example
illustrating why:
01100101 = Plaintext
XOR 10111011 = Secret Key
------------
11011110 = Result (Ciphertext)
11011110 = Ciphertext
XOR 01100101 = Plaintext
------------
10111011 = Result (Secret Key)
This will give you the secret key for that packet, but not the WEP key.
The IV and WEP key are used in RC4's PRNG, so that there is a unique
secret key per packet.
> But before I can even think about the key, I need to figure
> out how to identify these encrypted DHCP? Anyone know?
There are several ways, such as looking for certain length frames or
forcibly disassociating a client, causing it to reassociate and dhcpdiscover,
repeatedly.
> let's say 11 bytes of the key stream (from 8 bytes from LLC
> and SNAP plus 3 bytes from IP header)
You actually know more than this, depending on specific protocols and
their options. You could also conduct an active attack such as sending
an e-mail with a link to a video, which I've stated in an earlier post.
> 1) Generate an 8 byte (n-3) message that generates a predictable
> response (8 byte ICMP packet? What shall we use here?)
> ...
You could do all that to gather more data, and eventually you'd be left
with many unique secret keys, corresponding IVs and plaintext, and a
known algorithm. From there other crypto attacks would be used to derive
the WEP key.
Alternatively, as someone else had previously stated, you could inject
packets to pass exploit code to a vulnerable service. From there the
possibilities are too numerous.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:55 EDT