I am running some -m 14000 -a 3 searches with multiple cyphertexts and same plaintext.
Recovered........: 0/3 (0.00%) Digests, 0/1 (0.00%) Salts
I've noticed that performance is slower when searching multiple cyphertexts and best performance is delivered when searching only one key. My question is:
As soon as I recover some of the keys, can I stop the search and continue from the last restore point (with --skip parameter), but now search only for one or two keys? So this comes down to, is the --skip value compatible when the number of cyphertexts changes? Reminding that plaintext is the same.
As the number of remaining hashes drops, performance per hash should increase.
In other words, once only one hash remains, performance should be the same as if the target was only a single hash in the first place.
This is true, but running with only one hash/salt triggers some optimizations that, at least for mode 14000, increase performance by 30%. And these are not enabled while running. So if I search for 3 hashes and 2 are recovered, stopping and running with only 1 makes sense. But is the keyspace compatible? If searching 3 hashes reached 50%, can I stop and continue with only one hash for the rest 50%?
For example:
Code:
./hashcat64.bin --restore
hashcat (v4.0.1) starting in restore mode...
* Device #1: WARNING! Kernel exec timeout is not disabled.
This may cause "CL_OUT_OF_RESOURCES" or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1060 6GB, 1517/6069 MB allocatable, 10MCU
Hashes: 5 digests; 5 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Applicable optimizers:
* Zero-Byte
* Precompute-Final-Permutation
* Not-Iterated
* Single-Salt
* Brute-Force
Password length minimum: 8
Password length maximum: 8
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger disabled.
INFO: Removed 4 hashes found in potfile.
[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit => s
Session..........: hashcat
Status...........: Running
Hash.Type........: DES (PT = $salt, key = $pass)
Hash.Target......: hashes.txt
Time.Started.....: Sun Dec 31 09:45:22 2017 (8 secs)
Time.Estimated...: Thu Jan 25 09:44:32 2018 (24 days, 23 hours)
Guess.Mask.......: ?1?1?1?1?1?1?1?1 [8]
Guess.Charset....: -1 charsets/DES_full.charset, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....: 7442.8 MH/s (89.44ms)
Recovered........: 4/5 (80.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 55981492255326208/72057594037927936 (77.69%)
Rejected.........: 0/55981492255326208 (0.00%)
Restore.Point....: 26694026239/34359738368 (77.69%)
Candidates.#1....: $HEX[73bcc4fe0eb567c7] -> $HEX[fece0bfb0e0473c7]
HWMon.Dev.#1.....: Temp: 56c Fan: 0% Util: 99% Core:1949MHz Mem:3802MHz Bus:16
As you can see, when starting it sees 5 hashes and doesn't enable optimization * Single-Hash
But after that it skips 4 hashes found in potfile (already recovered) and runs with only one hash, but without the Single-Hash optimization, getting 7442,8 MH/s. Now if I edit hashes.txt and only leave one hash and run --restore, I get:
Code:
./hashcat64.bin --restore
hashcat (v4.0.1) starting in restore mode...
* Device #1: WARNING! Kernel exec timeout is not disabled.
This may cause "CL_OUT_OF_RESOURCES" or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1060 6GB, 1517/6069 MB allocatable, 10MCU
Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Applicable optimizers:
* Zero-Byte
* Precompute-Final-Permutation
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
Password length minimum: 8
Password length maximum: 8
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger disabled.
[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit => s
Session..........: hashcat
Status...........: Running
Hash.Type........: DES (PT = $salt, key = $pass)
Hash.Target......: xxxxxxxxxxxxxxxx:xxxxxxxxxxxxxxxx
Time.Started.....: Sun Dec 31 09:49:16 2017 (2 mins, 17 secs)
Time.Estimated...: Fri Jan 19 11:51:58 2018 (19 days, 2 hours)
Guess.Mask.......: ?1?1?1?1?1?1?1?1 [8]
Guess.Charset....: -1 charsets/DES_full.charset, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....: 9748.4 MH/s (68.25ms)
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 55984136344567808/72057594037927936 (77.69%)
Rejected.........: 0/55984136344567808 (0.00%)
Restore.Point....: 26694681599/34359738368 (77.69%)
Candidates.#1....: $HEX[7361f8fe0e0473c7] -> $HEX[fe0ef8fb0e541ac7]
HWMon.Dev.#1.....: Temp: 65c Fan: 37% Util: 99% Core:1936MHz Mem:3802MHz Bus:16
Performance increases 31%. But is it a valid search?
Huh - fair point!
My understanding of how --restore works is that it's mostly a record of what command-line options were used, for the purpose of reinvoking hashcat. So I think that its application of additional single-hash optimizations at the point of restoring should be fine, and the cracking work being done in the restored session should be perfectly valid.