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.