Date: Thu, 20 Aug 2020 20:19:26 +0200 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Performance John in the cloud On Thu, Aug 20, 2020 at 01:34:17PM -0400, Powen Cheng wrote: > I did some more reading and saw that the CPU method is the only way to > crack an ethereum wallet with scrypt parameters n:262144, r:8, p:1 as Correction: currently the only reasonable way. > currently there isn't any GPU on the market with enough RAM for the job I > guess. That blog post you reference is a good one, but it doesn't mention TMTO. scrypt's design is deliberately Time-Memory Trade-Off friendly, which means that any scrypt hash can be computed in less memory by paying for the lack of memory with even more computation. Of course, for high scrypt N*r like in your case above, this becomes unacceptably slow. hashcat has the "--scrypt-tmto" option to control this. > This brings me to my next question. Is there a way to convert scrypt > n:262144 to n:1024? No. This is actually in the FAQ section of the blog post you reference: "If I can only CPU crack, can I reduce/override my scrypt settings to 1024*8*1 so I can GPU crack it? No. Changing N will change the iteration count, which will change the hash. Hashcat will speed up greatly if you reduce the numbers to make you think you're #winning, but it won't crack the hash even if you've got the plain in your dictionary." > https://stealthsploit.com/2018/01/04/ethereum-wallet-cracking-pt-2-gpu-vs-cpu/ I was aware of hashcat's support for scrypt on GPU, but I had totally missed its support for Ethereum wallets with scrypt. When writing my previous reply to you, I searched hashcat's help output for scrypt and didn't find that - now I see it has SCRYPT in all caps there, while I was searching for scrypt in all lowercase. Oops. 15700 | Ethereum Wallet, SCRYPT | Password Managers Good to learn that this exists. > First let's use the example from the wallet I used in my previous post > <https://stealthsploit.com/2017/06/12/ethereum-wallet-cracking/>. BTW, this shows 2246 H/s at scrypt 1024*8*1 on mobile GTX 1060, whereas the fast CPU benchmark I had posted shows 54k c/s at those parameters. Of course, a larger GPU would perform better than the mobile one, and I think hashcat's scrypt implementation has much room for optimization, but it looks like with the current implementations CPUs are competitive even at these lower parameters. Thanks, Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.