Processing stopped after 5 attacks

I was taking part in a CTF challenge where we were given n, e and c. I installed goRsaTool on a Kali Linux 2022.1 box.

Commands executed:
goRsaTool -createkey -n 403...233 -e 65537 > key.pub
(I snipped the digits of n and the ... wasn't in the command. Happy to provide the whole number if that will help though. )
goRsaTool -key key.pub -attack all -verbose

Output:
rsatool: rsatool.go:94: starting up...
2022/03/19 09:21:34 small q attempt beginning with timeout 3m0s
2022/03/19 09:24:34 wiener attack failed, trying the the next variant
2022/03/19 09:24:34 wieners2 attack failed, trying the final variant
2022/03/19 09:26:30 fermat factorization attempt beginning with timeout 5m0s
2022/03/19 09:31:30 londahl attempt beginning with timeout 5m0s
zsh: killed goRsaTool -key key.pub -attack all -verbose

I followed the instructions for installing:
sudo apt install git golang libflint-dev libecm-dev make
git clone https://github.com/sourcekris/goRsaTool
cd goRsaTool
make
sudo make install

When it first stopped I rebooted, ran apt update then apt upgrade (nothing upgraded) and tried again. It stopped again after the same first few attack attempts.

I wasn't using the box otherwise while it was running. I just let it go and checked in say 15 minutes later.

[sourcekris]

Yeah i acknowledge this is a real bug and something i prefer worked. I also know its something I haven't focused on in the tool to date but that should work.

It breaks on almost all keys that aren't simply solvable and has a variety of underlying causes like:

• Some modules do not have timeouts when they should.
• Some timeouts are too long.
• Some timeouts are not working.

I think refactoring holistically the way modules are invoked and placing the timeout in the control of the caller would be better than the current adhoc timeout implementation per module. Using goroutines at the upper abstraction layer would give us a side effect where we could support concurrent module execution for modules that could support such a execution context.

I'll probably forecast that for the next sprint on this project. Happy also to take PRs that refactor the way timeouts are done, concurrency, or anything else.

[sourcekris]

Much of the work to solve this was resolved in this commit I haven't gotten around to testing that only modules that are appropriate to automatically run are chosen to run in unattended mode yet.