Interesting puzzle. "(at least)" isn't giving me any great ideas tho.
Well the next hint (if it's still unclaimed after 100 confirmations) should make it dramatically easier (as I am not going to let this drag out for too long).
Why not? You stated before you wouldn't empty the address until Jan 3rd. It takes time to figure out best ways to approach this and then implement. If you are attempting to evaluate the security model it seems counter-productive to cop out by reducing the difficulty too soon.
I'm only able to check about 264 pwds/sec on my laptop but I'm still seeing if there is a better method than I've found. I've modified a "found" program to brute force gpg. If I can improve this sufficiently then I may start an EC2 instance to go at it faster. I'd hate to spend too much effort and then just have you void it all by giving it away or closing the challenge. Seems unsportsman-like.
C code?
I thought I was the one coming from behind as right now I'm on a measly Core2Duo laptop, and only using one thread. I wanted to adapt the code for sha256 and then add multi-threading, and then finally get it running on a faster computer. The salting algorithm can be "trial by hand" as a 4-char cycle is still about 15 hours for me. If I can get it to < 1 hour then I'd add reading a salt template from a file.
I'll not give my own code mods but for starts: I'm
nasty and google is your friend.
You'll want to install the gpgme library, (sudo apt-get install libgpgme11-dev)
and even after that do some reading before you can compile due to large file support.
This way works but I'm by no means certain that there isn't some much faster method.
BTW: A word of warning, don't pump gpg with pwds without disabling the gpg-agent first. I got into a real pickle when the agent popped up with a "safe pwd window" for each password attempt. Ouch. But fast fingers with exiting the terminal actually worked. You can set the env variable to prevent that... eg.
GPG_AGENT_INFO='' myhackingprog
This is what happens when you're an amateur.
