Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 19 Oct 2008 10:10:18 +0200
From: Simon Marechal <>
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 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.