It looks like it's taking 20-30 seconds to generate one (250,000 turns of scrypt). You'd have to spin up 20,000+ instances to even get 1000 per second.
Hardly, for the earlier challenges I managed to hit ~50 a second with native code on a core i7. Missed out on winning any of the smaller challenges though though.
I don't think it's worth my time unless I managed to find enough hardware to do at least 100k attempts a second. Scrypt is executed on the CPU and the PBKDF runs on the GPU, then the GPU sits around and waits for the CPU to get it's job done before XORing the results. I considered making a pool, but there's no way of knowing if people are being truthful when submitting solutions.
It's a pity scrypt is designed to be hard to implement on hardware, or I'd have a crack at it with some FPGAs.
Comments
It looks like it's taking 20-30 seconds to generate one (250,000 turns of scrypt). You'd have to spin up 20,000+ instances to even get 1000 per second.
Hardly, for the earlier challenges I managed to hit ~50 a second with native code on a core i7. Missed out on winning any of the smaller challenges though though.
I don't think it's worth my time unless I managed to find enough hardware to do at least 100k attempts a second. Scrypt is executed on the CPU and the PBKDF runs on the GPU, then the GPU sits around and waits for the CPU to get it's job done before XORing the results. I considered making a pool, but there's no way of knowing if people are being truthful when submitting solutions.
It's a pity scrypt is designed to be hard to implement on hardware, or I'd have a crack at it with some FPGAs.
How'd you get the crypto_scrypt() call to go so fast?
one call to crypto_scrypt takes about a second on my machine. The pbkdf2 is the fast part. I'm using the crypto_scrypt from here: https://github.com/keybase/triplesec/tree/master/contrib/scr...
I just used pieces of John the Ripper and threw together something that worked.
BS alert...