[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140802092309.GB21649@openwall.com>
Date: Sat, 2 Aug 2014 13:23:09 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: PKZIP and GPU acceleration
Hi,
On Fri, Aug 01, 2014 at 10:36:04PM -0500, Dylan Staley wrote:
> I've been playing around with John, compiled from the bleeding-edge branch
> (without modifying the Makefile), and I've noticed that a lot of the
> formats that have CUDA or OpenCL support are listed as such under the
> format option. Now, I've read countless articles about using John on
> CUDA-enabled EC2 instances, but seeing as how PKZIP *doesn't* have a CUDA
> or OpenCL version listed in the format option, does it even matter?
For this format, GPUs don't matter. (We do have a GPU-enabled format
for the newer WinZip/AES archives, but not for the old PKZIP.)
> I wanted to try and figure this out myself, so I ran john --format=PKZIP
> --test on two EC2 instances:
>
> * g2.2xlarge: 26 ECUs, 8 vCPUs, 2.6 GHz, Intel Xeon E5-2670, 15 GiB memory,
> NVIDIA GRID K520 GPU
> * c3.8xlarge: 108 ECUs, 32 vCPUs, 2.8 GHz, Intel Xeon E5-2680v2, 60 GiB
> memory
>
> The results were as follows:
>
> g2.2xlarge
> $ ./john --format=PKZIP --test
> Will run 8 OpenMP threads
> Benchmarking: PKZIP [32/64]... (8xOMP) DONE
> Many salts: 50288K c/s real, 6301K c/s virtual
> Only one salt: 22616K c/s real, 2837K c/s virtual
>
> c3.8xlarge
> $ ./john --format=PKZIP --test
> Will run 32 OpenMP threads
> Benchmarking: PKZIP [32/64]... (32xOMP) DONE
> Many salts: 144437K c/s real, 4519K c/s virtual
> Only one salt: 33959K c/s real, 1061K c/s virtual
You need to use --fork=8 or --fork=32, respectively, to achieve much
better cumulative speeds on these machines. Our OpenMP scaling at
speeds this high isn't great.
> At this point, I was completely convinced that john is using the CPU for
> PKZIP, but I wanted to see just how much its performance could be increased
> in the real world. I used zip2john to get the hash for a zip file with a
> fairly simple password ("mi12345"). It took the g2 instance (the one with
> the GPU) 21 minutes to find the password, and the more powerful c3 instance
> 15 minutes to find the password.
You'll get much lower running times, and a bigger difference between the
two systems (should be 3x or so), with --fork.
> If I'm correct in assuming that John doesn't support using a GPU on PKZIP,
> what would be needed to enable this?
Code would need to be written, and for speeds this high some redesign
would also be needed (simply adding a GPU-enabled format would make
little sense as we'd bump into the communication bottleneck right away).
> Does anyone know of anything that is
> able to use the GPU with better performance than a CPU?
For the old PKZIP archives, no.
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.
