Pyrit 0.3.0 was just tagged and is now the currently stable version. Enjoy.
Due to the numerous changes after 0.2.4, I’ve advanced Pyrit’s “major-minor” revision number to 0.3. Highlights from the changelog include:
- SSE2-support for the EAPOLCracker, making all attack-modes roughly 3x faster
- Much improved lazy-loading of files, giving another 20% to 30% performance to all attack-modes
- Support for using SQL-databases as a storage backend
- Support for sharing GPUs and databases over the network
You can get the new version right here.
5 Comments
Comments RSS TrackBack Identifier URI
Pyrit 
hi people! Please, join me to wellcome the just-borned pyrit 0.3.0. Wellcome baby!!!
How does using an SQL backend impact performance? If I wanted to build an SQL server to store a huge database for running pyrit against, will I run at much of a penalty vs. just local disks? I guess a better question to ask is once you have all your PMKs pre-computed and stored in a local database, what is the performance bottleneck during the remainder of the attack? Is it cpu-bound or are you constrained by how fast you can read from disk? I would test myself but I’ve got an exam in a couple days. :(
The SQL-backend’s overhead is neglect-able. Disk seek times are a problem but a normal harddisk should serve a dual-core CPU pretty well. A quad-core will probably need a RAID0
I want to take ebfe’s Question a little further. I’m running Dual 5770’s which allows me to clock in ~60k PMK’s? If I needed an external Postgres Server, What type of MB/s right speed would I need?
You can estimate the bandwidth very easily: Every key is 32 bytes long. There is some overhead in the file-format, the table-format, the network-packet etc. Lets consider every key to consume 45 bytes of storage/transfer. A speed of 60.000 PMKs per second then translates to about 2.5 megabyte per second.
The problem is usually not how much can go in (while computing the PMK) but how much you get out of it (while trying to find the correct one). A decent quad-core CPU is able to handle 1.5 million keys per second which translates to about 64 megabytes per second. Keep that in mind.