[Feature request] To Pause and Resume

To Pause and Resume the sessions (like hashcat)

pause () {
	if killall -STOP "$1"
	then
		echo "[+] $1 successfully paused!"
	else
		echo "[-] $1 Failed to pause $1"
	fi
}

unpause () {
	if killall -CONT "$1"
	then
		echo "[+] $1 successfully continued!"
	else
		echo "[-] $1 Failed to continue $1"
	fi
}

Usage:

$ pause mkp224o
$ unpause mkp224o

(or you just press CTRL+Z ... or CTRL+S / CTRL+Q)

@xanoni is this a bash script? Did it can resume from stopped point?

well it's just normal pausing and resuming of processes ... I typically just start mkp224o in a screen session and then I press CTRL+Z to pause it and enter fg to resume it ...

Obviously this doesn't survive a system restart .... for that there would have to be functionality to persist state on disk

Surviving a restart will be very appreciated! It will surely affect the performance but I can imagine many scenarios where an automatic restart will break a work that could require several days to complete.
Maybe the run state can be persisted every {configurable} amount of time or something like that.

Does someone understand the algorithm and can tell whether persisting sessions actually adds value?

Maybe a restart is not much worse given we initialize with a new seed every time.

I don't know anything.

@cathugger ? ;-)

Pausing and resuming is mostly useless. Every time the program restarts, it will use a new seed.The only exception to this is if you use the -p/-P argument to set a fixed seed. In that case, restarting the program with the same passphrase will run through all the keys generated previously before generating new keys. I've made a PR that adds optional checkpointing support for passphrase-based generation here: #61. When you use this, it will skip over practically all the previously tested keys upon restarting the program.

Note: Generally you shouldn't use the passphrase option because of the limited entropy of passphrases. And to reiterate, if you don't use passphrases then you do not need to make checkpoints and the -c flag will do nothing.

That's what I assumed. Great.

After superficially scanning the code I also noticed that the seed is automatically getting initialized with random data, so you're right ... I didn't see this documented, so to be safe I wrote a bash script that initializes the program with a /dev/random seed ... unnecessarily, but better safe than sorry ...

mkp224o/worker_fast.inc.h

Line 40 in fc62855

randombytes(seed,sizeof(seed));

mkp224o/worker_slow.inc.h

Line 33 in fc62855

randombytes(seed,sizeof(seed));

mkp224o/worker_batch.inc.h

Line 43 in fc62855

randombytes(seed,sizeof(seed));

mkp224o/ed25519/ed25519.h

Line 167 in fc62855

randombytes(seed,32);

so to be safe I wrote a bash script that initializes the program with a /dev/random seed ... unnecessarily, but better safe than sorry ...

If you're suggesting that you're passing the data from /dev/random as a passphrase, that is not a good idea for multiple reasons. First, if you do not match or exceed the seed size, your initial seed will have less entropy. Second, when you do not specify a passphrase, the generator will be reseeded randomly occasionally. If you specify a passphrase, the generator will increment the seed instead. This is convenient because it makes the behavior deterministic, but it is worse from a security perspective, especially if you may want to use more than one of the generated results.

What I was trying to say is simply that I was originally not aware that the seed was auto-generated/refreshed, because to my knowledge that is not documented anywhere. I was conservative and fed it way too many bits so should have been fine ;-)

Are you saying though that if no password is specified, the seed will be refreshed "occasionally" WHILE the program is running? Is this roughly the same as terminating and restarting mkp224o (without specifying a passphrase)?

mkp224o do full refresh of per-thread state when given thread successfully finds a match. this is so that leaking of any single key generated by same mkp224o would have zero chances of impacting security of other keys generated on the same run. passphrase mode is designed to be deterministic and thus keys of the same run aren't protected the same way. i still try to use hash so leak of later keys wont impact security of earlier keys but there is no protection of the opposite so this mode of operation is strictly less secure in this way.