Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 2 Aug 2014 13:23:09 +0400
From: Solar Designer <>
Subject: Re: PKZIP and GPU acceleration


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


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.