Date: Wed, 31 May 2006 22:53:07 +0200 From: "Otheus (aka Timothy J. Shelling)" <otheus@...il.com> To: john-users@...ts.openwall.com Subject: Re: Parallalizing John the Ripper It occured to me, just before I looked at the "Pippin" MPI project, that in both Ryan's implementation and in mine, once a particular hash is cracked by a particular task, the other tasks are *still* comparing against the cracked passwords. They are also generating hashes from salts that may be no longer needed. It looks like Pippin aimed to solve this, but they used a jackhammer to remove this splinter. They re-wrote several *files* in C++. But from their power-point presentation (which has several errors, by the way), they solve this by distributing the passwords so that salts are clumped together on one task. That wouldn't scale well in a number of scenarios, and from what you (Solar) has mentioned in the past, distributing the salts would undermine many oh John's optimizations. So perhaps Solar or someone can point me the way. After a task cracks a password, it should broadcast the cracked hash (or perhaps index) to all other tasks. Question: Where/how should the other tasks handle this event? I'm somewhat lost on this, but my current guess is that for each cracked ciphertext received via MPI, the task must find the right salt list and pw entry can call crk_process_guess(). If there's a cleaner way, I'd love to know. Question: Where/how should the cracking task broadcast this event? It seems pretty clear that this should be in crk_process_guess(). Of course, if my guess above is true, the crk_process_guess must be called for every cracked password received from the other tasks, then this would be split into two functions right after the log() call. Alternatively, I could add a boolean parameter to the function which would be use to skip re-broadcasting and re-logging the cracked password.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ