RE: WEP attacks based on IV Collisions

pen-test_at_nym.hush.com
Date: 06/03/04

  • Next message: pen-test_at_nym.hush.com: "RE: WEP attacks based on IV Collisions" 
    Date: Thu,  3 Jun 2004 13:36:05 -0700
To: pen-test@securityfocus.com

    > 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.

  • Next message: pen-test_at_nym.hush.com: "RE: WEP attacks based on IV Collisions"

    Relevant Pages

    • Re: How good an encryption algorithm is this?
      ... >> know both a plaintext and a ciphertext for some message ... This is pretty much what happens with any encryption algorithm that uses ... XOR alone. ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: How good an encryption algorithm is this?
      ... >> know both a plaintext and a ciphertext for some message ... This is pretty much what happens with any encryption algorithm that uses ... XOR alone. ...
      (microsoft.public.vc.language)
    • Re: encryption using a block cipher // ? size limit of plaintext
      ... The attacker finds two ciphertext blocks C_and C_that are the same. ... The attacker knows CXOR C(the XOR of the two blocks in the ... two plaintext blocks whose ciphertext matches. ...
      (sci.crypt)
    • Re: Append IV to ciphertext?
      ... >> first blocks of the plaintexts are identical. ... >> But storing an IV for each plaintext is impractical for me. ... >> thought of doing was appending the IV to the ciphertext, ... >> xor as usual to get the plaintext. ...
      (sci.crypt)
    • Re: decrypting a XOR of two plaintexts
      ... >> If you have the plaintext and the associated ciphertext, you can XOR ... >> plaintext messages with the ciphertext to get the keystream. ...
      (sci.crypt)