[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP2554FFE4630866167631BBFFD290@phx.gbl>
Date: Fri, 11 Jan 2013 10:26:41 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New plugin load order magic
On 01/11/2013 09:27 AM, magnum wrote:
> On 11 Jan, 2013, at 8:58 , Solar Designer <solar@...nwall.com> wrote:
>> On Fri, Jan 11, 2013 at 08:26:40AM +0100, magnum wrote:
>>> I was just considering reverting my patch for now.
>>
>> Yes, I think you should.
>
> I reverted it now but we need to fix this somehow. For the horribly slow iterated formats that are getting common now, we just can't default to CPU formats on a GPU build.
There might be a solution if we extend the format interface in the future.
A format could then specify a fallback format which is used for --show.
This would, however, create dependencies between formats. Then, users
cannot just remove the CPU implementation of a plugin format.
And if those "horribly slow iterated formats" have GPU implementations
with extremely high MAX_KEYS_PER_CRYPT values, it is not always a good
idea to default to GPU implementations.
Imagine a user who is not aware of the impact of MAX_KEYS_PER_CRYPT:
He could well be launching more than 20 different attacks (small word
lists, few rules) with a *total* number of password candidates still
smaller than MAX_KEYS_PER_CRYPT.
(May be we even need another fallback format for --single mode.)
Frank
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.
