[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200815210613.GA20655@openwall.com>
Date: Sat, 15 Aug 2020 23:06:13 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Performance John in the cloud
Powen,
You asked specifically about ethereum-opencl, but as discussed today on
GitHub issue #3222 (with you?) that format doesn't currently support the
scrypt KDF. For newer Ethereum wallets that use scrypt, you need to use
the CPU format instead.
Testing it on a c5a.24xlarge instance (96 vCPUs, AMD EPYC 7R32), I get
the below speeds. For scrypt:
$ john -test -form=ethereum -cost=0,1
Will run 96 OpenMP threads
Benchmarking: ethereum, Ethereum Wallet [PBKDF2-SHA256/scrypt Keccak 256/256 AVX2 8x]... (96xOMP) DONE
Speed for cost 1 (iteration count) of 1024, cost 2 (kdf [0:PBKDF2-SHA256 1:scrypt 2:PBKDF2-SHA256 presale]) of 1
Warning: "Many salts" test limited: 142/256
Many salts: 54256 c/s real, 564 c/s virtual
Only one salt: 54144 c/s real, 564 c/s virtual
The "-cost=0,1" options requests the benchmark to use only the scrypt
test vectors. Your actual speed will depend on scrypt parameters in use
by your target wallet, and may differ from the above a lot.
For example, here's the speed of scrypt with different parameters:
Benchmarking: scrypt (16384, 8, 1) [Salsa20/8 128/128 AVX]... (96xOMP) DONE
Speed for cost 1 (N) of 16384, cost 2 (r) of 8, cost 3 (p) of 1
Raw: 2208 c/s real, 23.1 c/s virtual
c5a.24xlarge provides a high number of vCPUs, but it might or might not
be the best choice in terms of price/performance for scrypt. In fact,
the best choice might even vary by scrypt parameters in use, as they
affect usage not only of the CPU, but also of the memory subsystem. Yet
the above should give you a rough idea of what to expect, and you can
compare the above benchmarks against systems that you have locally.
c5a.24xlarge is currently priced at $1.56+/hour spot, $3.696 on-demand.
Our Bundle (beyond the free trial) costs $0.64/hour on this instance.
On Sat, Aug 15, 2020 at 10:21:51PM +0200, Solar Designer wrote:
> On NVIDIA Tesla V100 in p3.2xlarge:
>
> Benchmarking: ethereum-opencl, Ethereum Wallet [PBKDF2-SHA256 Keccak OpenCL]... DONE
> Speed for cost 1 (iteration count) of 262144 and 1024
> Raw: 22260 c/s real, 22140 c/s virtual
>
> However, please note that this benchmark is for a mix of two different
> iteration counts. Your actual Ethereum wallet would have just one, if
> you need to recover password to just one wallet at a time. If you only
> need to attack a wallet with 262144 iterations, the expected speed is
> about twice lower than the above (so 11k+). If you only need to attack
> a wallet with 1024 iterations, the expected speed is about 2.8M c/s.
Here's how much slower this becomes on c5a.24xlarge's CPU:
$ john -test -form=ethereum
Will run 96 OpenMP threads
Benchmarking: ethereum, Ethereum Wallet [PBKDF2-SHA256/scrypt Keccak 256/256 AVX2 8x]... (96xOMP) DONE
Speed for cost 1 (iteration count) of 262144 and 1024, cost 2 (kdf [0:PBKDF2-SHA256 1:scrypt 2:PBKDF2-SHA256 presale]) of 0
Warning: "Many salts" test limited: 10/256
Many salts: 3443 c/s real, 35.7 c/s virtual
Only one salt: 1721 c/s real, 17.9 c/s virtual
That's for PBKDF2-SHA256. So for older wallets that use PBKDF2-SHA256,
it's much more cost-effective to recover their passwords on GPU.
(The "Only one salt" is twice slower because it's limited to the larger
one of two iteration counts. We'll need to change the reporting here.)
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.
