[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Feb 2006 20:40:35 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: roadmap
On Wed, Feb 01, 2006 at 09:43:33PM +0100, Frank Dittrich wrote:
> What about --individual, or just --ind
> But I don't mind --single, either
I don't see much of a difference between --single and --individual.
> (Isn't the functionality a feature provides more important than
> the name?)
Indeed, but that's not a reason for using a non-descriptive name.
> Just picking up this thread for further suggestions:
>
> I think the "fast dummy" algorithm, which just uses hash=password,
> is useful for some john users.
I agree - but only for a very small percentage of the users.
> (Although, you might have to take special care of passwords
> containing colons.)
Yes, that's a minor difficulty.
> Then, I'd like to have a new external mode function, in addition to
> generate() and filter().
> I'd like to be able to get the password candidates, and generate
> an arbitrary number (0-N) of new password candidates based on
> the input.
FWIW, this is currently supported for the special case of N=1. ;-)
That is, filter() can ask for the candidate to be skipped or it can
_modify_ the candidate.
> I'd like to use generate(), filter(), a combination of both,
> or a new function to
> -either: generate a new password based on the password
> provided by john
> -or: indicate that I don't want to generate more passwords based
> on the last password provided by john's cracking mode
Yes, I once had this thought, too. I think the easiest way to implement
it currently would be by introducing a new global variable in addition
to "word". Let's call it "retry" for this discussion. filter() would
set "retry = 1" if it wants to be called again with the same candidate
password (as provided by the main cracking mode in use).
But there might be a cleaner way to do it. Maybe generate() and
filter() should be replaced with one function, next().
Also, maybe restore() should be dropped, but instead John itself should
be saving and restoring the entire virtual machine's memory. However,
this would require re-working the crash recovery file management first
since the file would potentially become much larger - and its in-place
rewrites would no longer be reliable enough.
> If you don't think this would be a useful feature, I could
> explain the benefits I expect.
It is obvious to me that this would be a useful feature, -- but I don't
mind you explaining particular usage scenarios you have in mind anyway.
Thanks,
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
