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.