Question about --skip and --limit

[malakudi]

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.

[royce]

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.

[malakudi]

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%?

[malakudi]

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?

[royce]

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.