[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200524130059.GB7145@openwall.com>
Date: Sun, 24 May 2020 15:00:59 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Number of passwords tested per second
On Sat, May 23, 2020 at 08:11:49PM +0200, MA40 wrote:
> When I do "Pause attack", in "Console log" this text appears:
>
> Wait...
>
> 0g 13:01:34:00 3/3 0g/s 6.853p/s 95.72c/s 95.72C/s ticnoy..ticne1
Great.
> Then, they are 6,853 p/s. Isn't that a little bit small amount?
Of course, this is very low speed - fewer than 7 passwords tested per
second on average. However, a speed like this is to be expected when
you're (apparently) running an attack on 14 Bitcoin wallet "hashes" on a
few CPU cores.
Here's a benchmark on i7-4770K (4 cores, 8 hardware threads):
$ ./john --test --format=bitcoin
Will run 8 OpenMP threads
Benchmarking: Bitcoin, Bitcoin Core [SHA512 AES 256/256 AVX2 4x]... (8xOMP) DONE
Speed for cost 1 (iteration count) of 177864
Raw: 194 c/s real, 24.3 c/s virtual
That's for one "hash", and should be compared against the 95.72 c/s
figure of yours. So maybe you have 2 rather than 4 CPU cores, or maybe
you don't have AVX2, or maybe your "hashes" are slower on average.
Regardless, it's a comparable speed.
Bitcoin wallets use a purposefully slow KDF (key derivation function),
which is why attacks are so slow. I recommend that you optimize which
attacks you run and in which order - that's more important than speeds.
Typically, when recovering lost passwords to Bitcoin wallets, you'd
focus the attacks based on whatever information the owner can recall.
Speeds may vary between your different wallets' "hashes" - it's that
"iteration count" thing. You might want to identify which ones of your
wallet "hashes" show lower iteration counts and thus higher speeds, and
if the difference is substantial then attack those separately to let
your attacks on them proceed further than on the rest.
Speeds would be a lot higher with hashcat on GPU, but still not very
high. Unfortunately, we don't yet support Bitcoin wallet "hashes" on
GPU in John the Ripper, but you should be able to load the "hashes"
produced with our bitcoin2john.py into hashcat to attack them on GPU.
The best speeds you can currently obtain with John the Ripper are
something like this, on Xeon Phi 7210:
$ OMP_NUM_THREADS=254 GOMP_CPU_AFFINITY=0-255 ./john --test --format=bitcoin
Will run 254 OpenMP threads
Benchmarking: Bitcoin, Bitcoin Core [SHA512 AES 512/512 AVX512F 8x]... (254xOMP) DONE
Speed for cost 1 (iteration count) of 177864
Raw: 2266 c/s real, 8.9 c/s virtual
That's only ~11.7 times higher than the CPU benchmarked above, and you
wouldn't have an exotic device like this in a Windows VPS. So to
substantially increase the speeds, you'd go with hashcat on GPU, but
even more importantly without focusing the attacks your chances of
success are very low as the speeds wouldn't be high no matter which
tool or hardware (that you'd reasonably afford).
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.
