+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: multiple DES cipher same plain (/thread-8751.html)
multiple DES cipher same plain - superhansi - 11-01-2019
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
RE: multiple DES cipher same plain - atom - 11-01-2019
Sure, just change the key?
RE: multiple DES cipher same plain - superhansi - 11-01-2019
(11-01-2019, 04:16 PM)atom Wrote: 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
RE: multiple DES cipher same plain - atom - 11-01-2019
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.
RE: multiple DES cipher same plain - superhansi - 11-01-2019
Yes i'm aware of this. The number of CT
T 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).
RE: multiple DES cipher same plain - Kryczek - 11-04-2019
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
RE: multiple DES cipher same plain - atom - 11-05-2019
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).
RE: multiple DES cipher same plain - superhansi - 11-05-2019
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