cathugger / mkp224o

vanity address generator for tor onion v3 (ed25519) hidden services
Creative Commons Zero v1.0 Universal
1.27k stars 150 forks source link

[Feature request] To Pause and Resume #59

Closed oivas000 closed 2 years ago

oivas000 commented 3 years ago

To Pause and Resume the sessions (like hashcat)

xanoni commented 3 years ago
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
xanoni commented 3 years ago

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

oivas000 commented 3 years ago

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

xanoni commented 3 years ago

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

Guisardo commented 3 years ago

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.

xanoni commented 3 years ago

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.

oivas000 commented 3 years ago

I don't know anything.

xanoni commented 3 years ago

@cathugger ? ;-)

scribblemaniac commented 3 years ago

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.

xanoni commented 3 years ago

That's what I assumed. Great.

xanoni commented 3 years ago

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 ...

https://github.com/cathugger/mkp224o/blob/fc6285523f615e31f9d313a667e6ca8a9d781872/worker_fast.inc.h#L40

https://github.com/cathugger/mkp224o/blob/fc6285523f615e31f9d313a667e6ca8a9d781872/worker_slow.inc.h#L33

https://github.com/cathugger/mkp224o/blob/fc6285523f615e31f9d313a667e6ca8a9d781872/worker_batch.inc.h#L43

https://github.com/cathugger/mkp224o/blob/fc6285523f615e31f9d313a667e6ca8a9d781872/ed25519/ed25519.h#L167

scribblemaniac commented 3 years ago

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.

xanoni commented 3 years ago

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

cathugger commented 3 years ago

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.