[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <48FAEB6A.9080606@banquise.net>
Date: Sun, 19 Oct 2008 10:10:18 +0200
From: Simon Marechal <simon@...quise.net>
To: john-users@...ts.openwall.com
Subject: Re: background crypt_all() calls
Solar Designer wrote:
> Simon,
>
> On Fri, Oct 17, 2008 at 08:07:17AM +0200, Simon Marechal wrote:
>> ... I'd rather have support for ''background'' crypt_all() calls
>> (obviously easy to do for crack() mode, but -test would need some
>> tweaking).
>
> What do you mean by this? Built-in support for parallel processing -
> like fork()'ed sub-processes for multi-CPU and multi-core support and
> perhaps also for GPU support? I think that for fast hashes this must be
> done at a higher level in the code. Doing inter-process communication
> per crypt_all() call would be too slow for those, although for slow
> hashes this is an option (and it has its advantages).
Well as you said, it would be mainly intended for GPUs and not-so-slow
hashes. The idea is to be able to set_key, and cmp_all while passwords
are still being cracked by a coprocessor. This is something trivial to
write when you are writing a PoC bruteforcer, but I have always found
myself to be too lazy to integrate this in john (yeah and unsure of the
reliability of my modifications!).
It might be effective for multiprocessor support as password generation
and hashing could be more likely to stay in cache, but I believe this
would not prove to be a real improvement.
--
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
