Pyrit running on a cluster of 16 GPUs…

Pyrit patched for MPI-support and running on a cluster with 16 GeForce 8800 GT has reached 89.300 PMKs/s according to this post. This is equivalent to around 1.460.000.000 rounds of SHA-1 or 749 Gbit of data processed every second.

Update: The author of the posting mentioned above sent a link to a video showing Pyrit on 14+1 nodes…



  1. Indeed! I posted a video on Youtube of the program running:

  2. Sorry, but at the end of video, the test reports speed of 54699 key/sec, and not 89300 key/sec.
    What is the real power of the cluster? 89k of 54k?

  3. This is caused by latencies introduced by the Pyrit->coWPAtty pipeline. This is not a real problem as it can be easily fixed. Thereby I consider the peak-performance of 89k as the effective performance.

    Changes not yet in svn move more code from Python to C and improve backend-performance by far. The performance-limit introduced by workunit-handling should be raised to somewhere around 1.000.000 PMKs/s…

  4. @ebfe: Why it is used cowpatty insead aircrack-ng? I had a look to both software and i saw that aircrack-ng is better than cowpatty (i am speaking about speed of key/sec)

  5. Aircrack-ng can’t handle streams of precomputed PMKs in any format; additionally it’s codebase is horribly, horribly broken and I am unwilling to dig into the mayhem of patching it.

    Please also remember that the purpose of Pyrit is research.

    Read: I don’t care…

  6. @ebfe I also had problems reading aircrack-ng source code, but I assigned this problem to my poor knowledge of C. Anyway, it sounds interesting the info “move more code from Python to C and improve backend-performance by far” of your previous post. I send you my greeting as I hope to see these “speed up” on velocity asap. By the way, you speack about 1M key/s: is it referred the the cluster of 16 videocards or it is referred to the single videocard? In any case, 1M key/s it is an impressive velocity!

  7. The speed of 1M keys/s is referring to the “Null-Core”. This is the raw backend performance with no computation done at all and everything put into “reading -> unpacking -> hashing -> piping -> hashing -> packing -> writing”.

    The backend-performance is very important because it is a source of lag during processing. Having the GPUs stall will immediately cost a lot of performance so Pyrit tries to drown all sources of lag through buffering / multi-threading. The new backend code allows packing/unpacking of workunits in different threads and also introduces lazy-loading.

  8. So the MPI code will eventually make it into Pyrit?

    • I’ve taken a look at the code and find it very invasive and hard to handle. The patch brings a lot of MPI-specific changes to places that should be unspecific to the underlying implementation. All of the MPI-code is actually put into the the commandline-interface, Pyrit’s ‘GUI’.

      A better and by far easier approach would be to derive a new subclass from the class ‘Core’ in the module ‘cpyrit’ and make that new class available by putting instantiation-parameters to ‘avail_cores’. All of Pyrit’s code (passthrough, benchmark and batchprocessing) will automatically and transparently use MPI then.

      Take a look at how the CPUCore-class is derived from the class ‘Core’, implement a new MPICore-class and modify the function ‘autoconfig’ in the class ‘CPyrit’ in You can probably reduce code-complexity by 70% :-)

Comments RSS TrackBack Identifier URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

  • RSS Unknown Feed

    • An error has occurred; the feed is probably down. Try again later.