Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 20 Aug 2020 20:19:26 +0200
From: Solar Designer <>
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."


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

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.



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.