multiple DES cipher same plain

[superhansi]

Hi,
is it possible to modify des (-m 14000) kernel to support multiple cyphertexts having the same plaintext? If yes, where would one start?
Thanks in advance

[atom]

Sure, just change the key?

[superhansi]

Sure, just change the key?

Maybe I've been too unclear, sorry. The approach is to find the different keys resulting in pt:ct pairs by walking the keyspace just once as pt shall be static.


e.g. hashes.txt:
1343C4EF18EEC1AE:0123456789123456 (->key: 0123456789123456)
15A4E8CC064F65D9:0123456789123456 (->key: 5523456789123456)

This would result in significant speed drop and i dunno why?

Thanks

[atom]

If you just want to know all possible CT of a fixed PT by going through all possible keys, then this is not a task suited for a password cracker. For a password cracker there always needs to be some sort of comparison.

[superhansi]

Yes i'm aware of this. The number of CTT pairs is limited however, lets say 15. If i now want to find the corresponding keys to these pairs the speed "drops" for every added pair although the comparison should just cover the other CT's and the task keeps the same, like the --keep-guessing.
To simplify: I wonder if there is a quick-fix to avoid the speed drop? You had the DES-KPA example where the challenge was equal, now take into consideration that you'd have 15 equal challenges instead of the 2 and have a speed drop by 35-55% depending on the number of CT and used GPU(s).

[Kryczek]

Hi,

I am not sure I understand the question either but I think you might be referring to the fact that the more hashes/ciphertexts you load, the slower Hashcat gets?

This is normal Because with 15 entries for example Hashcat has to not only compute each candidate from the keyspace, but each time it has to go through "Does this candidate match entry #1?", "Does this candidate match entry #2?", "Does this candidate match entry #3?", etc for as many that you load, so in this example you slow this part down by 15.

If you know in advance that hashes/ciphertexts come from the same cleartext (e.g. WPA handshakes from the same PSK) then it's better to load only one

[atom]

Note that it depends if you know the PT already. In this case you can encrypt the PT and then compare against a list of CT, which minimal speed drop. However if you need to decrypt the CT and then compare with PT (in most of the cases if you know only parts of the PT), then the speed drops by the number of salts. For the first technique, having only 15 possible keys is an easy job and you will get full speed. Just make sure they all have the same PT (salt).

[superhansi]

atom that what i thought and thats why i think there might be a problem in the compare for same PT (salt) and -m 14000
i know the complete PT and run against a list of CT's like so:

CT : PT
1343C4EF18EEC1AE:0123456789123456
15A4E8CC064F65D9:0123456789123456

however speed drops from lets say 200gh/s for single pair to 180 with these 2, with every added pair it goes down further. When using RTX the speed drop is not that much

can you please give me a hint/idea what to try changing?
Thanks

@Kryczek comparing 1 or 15 shouldnt impact speed that much imho

edit: adding some numbers..
with 1:
Speed.#*.........:  338.3 GH/s
Recovered........: 0/1 (0.00%) Digests

with 2:
Speed.#*.........:  302.2 GH/s
Recovered........: 0/2 (0.00%) Digests

with 4
Speed.#*.........:  252.4 GH/s
Recovered........: 0/4 (0.00%) Digests

i further assumed it should get close to the hashrate with less digits left (assume one left), thats not the case either - probably because the compare algo remains inc_comp_multi_bs?

I'm having a hard time finding the right place to change / adjust