Date: Wed, 21 Jan 2009 17:37:52 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: keyspace, mask password and dumb bruteforce On Fri, Jan 16, 2009 at 03:49:28PM +0100, Samuele Giovanni Tonon wrote: > A "collision free" algorithm is to simply scan through the keyspace by > going incremental (i.e. 0000 0000, 0000 0001, 0000 0002 and so on...) > and splitting our work in to "chunks" for each client. > These chunks must be big enough to make the client work for some time > (some hours/some minutes) and then give back a feedback to the server. > > Then there's Jtr and his incremental mode which, for what i've > understand, will go to search the same keyspace as above but going to > test some "most likely to be" passwords first; This way, unfortunately, > is not higly distributed tough Actually, it is not very hard to split the workload across multiple nodes in a collision free way and without consuming much bandwidth while still using JtR's incremental mode. Please see: http://www.openwall.com/lists/john-users/2005/11/21/2 (especially the last paragraph). > even the wiki has a list of jtr distributed attempt; This doesn't mean much. People were implementing whatever they could think of and whatever they wanted to. > this way also means that those distributed attempts > are most likely like this: there's a server which is producing the whole > keyspace and sends it to the clients who will simply go as "wordlist > cruncher". A con against this is that the server <-> client > communication will be huge since each chunk (even if compressed) could > take a lot to transfer over the network and at the end could compromise > the whole purpose of being distributed. While this is an obvious approach, and it is actually quite good for extremely slow hashes and/or for large numbers of different salts loaded for cracking at once, that's not how those JtR hacks work. > As a quick solution to this problem i thought that maybe a solution is > to use "mask passwords list", which is not an innovative idea but could > work; with a mask password the user has the ability to restrict the > keyspace and it is still easy to split up chunks across the clients. > Basically it's making a bruteforce less dumb by using human brain other > than using heuristics and each client can easily self-produce the > keyspace to crunch, therefore saving network bandwith. If I understood you correctly, you're essentially suggesting to split the keyspace manually. Yes, this is what I recommend most of the time - especially when the number of CPU cores to distribute the workload across is relatively small. You might want to take a look at these older postings: http://www.openwall.com/lists/john-users/2008/04/08/4 http://www.openwall.com/lists/john-users/2005/08/24/4 Alexander -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ