Brute Force on 3DES with Reduced Keyspace and Unknown IV I'm trying to brute force a 3DES problem given a reduced keyspace (ie I know the first half of the key) but with an unknown IV. The code decrypts to plaintext. My first thought was that I could set the IV to the first 8 bytes of the CT, decode the rest and then substitute back to find the IV. This doesn't seem to work though - my brute forcer cannot find plaintext. I thought maybe it was getting confused with padding bytes at the end of the block being non-printable, so I removed the last 16 bytes as well, but that doesn't produce any results either.

Is there a flaw with my logic or is it more likely to be in my code?



Additional information from the comments

The ciphertext was generated using 3DES CBC and a 128 bit 3DES ABA key. 

The key is 16 bytes, I know the first 10 (a ten letter word) and the next six are numbers (as in the ascii val of the digits 0-9). I'm basically brute forcing from WORDWORDWO000000 to WORDWORDWO999999.
My first thought was that I could set the IV to the first 8 bytes of the CT [and] decode the rest[.]


This is exactly how CBC works.

For all blocks but the first, encryption is defined by $C_n=E_K(C_{n-1}\oplus P_n)$ and, therefore, decryption is achieved by $P_n=C_{n-1}\oplus D_K(C_n)$.

Since there is no previous ciphertext for the first plaintext block ($P_0$), we just set $C_{-1}=IV$. So, yes, considering the first ciphertext block the IV will allow you to decrypt all remaining ciphertext blocks.


  [T]hen substitute back to find the IV.


That part is not that easy. The first block of plaintext is $P_0=IV\oplus D_K(C_0)$. If both IV and plaintext are actual text, there might be hope, although 8 bytes of text probably won't be sufficient for the standard tools (e.g., frequency analysis).

If the IV has been generated pseudo-randomly, it effectively acts as a one-time pad. This means that, unless you can deduce the first 8 bytes of plaintext from the remaining plaintext anyway, there's nothing you can do.