Date: Fri, 16 Jan 2009 15:49:28 +0100 From: Samuele Giovanni Tonon <samu@...uxasylum.net> To: john-users@...ts.openwall.com Subject: keyspace, mask password and dumb bruteforce hello all, this is not a question about jtr but rather a question about cracking passwords and how to do that in an efficent way. let's suppose we are developing a distributed password cracker and let's suppose this passwords will be >= 8 lenght. Let's postpone the problem related to code optimization about the actual cracking and let's focus on the main problem on a distributed environment: the ability to split the work to many "clients" while avoiding as much as possible "collisions" in which two different clients check the same password, while keeping some kind of smart "shortcuts". 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 even the wiki has a list of jtr distributed attempt; 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. 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. So far i'm not aware of any other ideas/algorithms, what do you all think ? Many thanks Samuele -- While various networks have become deeply rooted, and thoughts have been sent out as light and electrons in a singular direction, this era has yet to digitize/computerize to the degree necessary for individuals to become a singular complex entity. KOUKAKU KIDOUTAI Stand Alone Complex -- 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