3Des - ECB brute forcing

[clearmoon]

Hi everyone,
I was wondering if there was a way, or could a feature be made, to take a 3des encrypted value and its clear text counterpart and brute force the encryption key used.

[atom]

It's not planned. Question is how such a solution would look like. Would it only allow candidates with exact length 24, or zero pad it? or pad it with length? How about extra padding for length % 8 = 0? The only real and good solution to this would be to make this variable enough so that the user could configure oclHashcat, but this would require a lot of kernels. Combined with the fact that BF that keyspace would take forever, even with GPU's, FPGA's or ASIC's, it's not really an option for me now.

[Sc00bz]

Well we know the ciphertext of 12345678, password, and adobe123. So that's enough needed. Also you wouldn't brute force this you would take all 2^56 keys and encrypt one of the plaintext blocks. Storing each value. Then start from the palintext's ciphertext and take all 2^112 key pairs and use one to decrypt the ciphertext then the other one to encrypt that value. Now just look up that inside of the 2^56 stored values. Basically ever 256 tries you will need to use another plaintext and ciphertext pair to verify if it is just a collision.

This would require 600 PB of ram and 2^111.0168 (((2^56)+(2^112+2^56)+(3/256*2^112)+(3/256/2^64*2^112))/2) DES operations on average. Or about 83 billion years if you can do a quadrillion DES operations/second... Good luck.

[zeroprobe]

What if you could brute force the keys of the word password which we already know the cipher for, up to 8-10 characters and put the encrypted output into a text file.

Then do a compare on the file to see if any of the generated brute forced passwords match up to the already known cipher of password? If found, whatever the position in the file you could work out which letter generated it. Then do another bruteforce with a specific letter and keep narrowing it down.

[vima]

This question wouldn't happen to be related to wanting to obtain the key used to encrypt the passwords in the Adobe password leak would it?

If so, based on what I've read, the notion that the passwords are encrypted with 3DES is an assumption based on the block size. The cipher used may not be 3DES, it may be some other 8 byte block sized cipher. Single DES for example. This post on the Sophos Naked Security blog talks about this. Unless you have better information than I do that might be something to keep in mind.

A while back on Reddit there was a thread with an OpenCL bitslice single DES cracker here. Since 3DES is basically just DES done three times, that code should be able to be modified to do what you want.

I had a very quick play at the time and IIRC on my 8 x AMD 7970 GPU system I was getting an estimated time of 128 days to brute force single DES. Its likely that proper tuning and optimisation could bring this time down, but it does mean that brute forcing 3DES would still take a rather long time. Just how much longer will depend on how the 3DES is done - there are various modes by which 3DES can be implemented, including EDE (Encrypt Decrypt Encrypt) mode where the same exact 56 bit key can be used three times. This is a backwards compatibility mode which is functionally equivalent to single DES, so it could be brute forced like single DES. I wouldn't put it past someone who uses ECB block chaining to make a dumb mistake like this, but of course its not something you can count on.

[epixoip]

Adobe confirmed like a month ago that it was in fact 3DES...

[vima]

Adobe confirmed like a month ago that it was in fact 3DES...

OK, you're right, I found an article on ZDnet from earlier this month here which has some Adobe rep confirming this. All of the other articles I had read on this didn't reference the Adobe confirmation.

[zeroprobe]

Was it the same key used though? Worth a shot.

[atom]

which key? the key is unknown.

[zeroprobe]

which key? the key is unknown.

Wouldn't it be bruteforceable if they used the same key for triple des.

Keying option 1: All three keys are independent.
Keying option 2: K1 and K2 are independent, and K3 = K1.
Keying option 3: All three keys are identical, i.e. K1 = K2 = K3.


Keying option 1 is the strongest, with 3 × 56 = 168 independent key bits.

Keying option 2 provides less security, with 2 × 56 = 112 key bits. This option is stronger than simply DES encrypting twice, e.g. with K1 and K2, because it protects against meet-in-the-middle attacks.

Keying option 3 is equivalent to DES, with only 56 key bits. This option provides backward compatibility with DES, because the first and second DES operations cancel out. It is no longer recommended by the National Institute of Standards and Technology (NIST),[4] and is not supported by ISO/IEC 18033-3.