[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090911013809.GA8357@openwall.com>
Date: Fri, 11 Sep 2009 05:38:09 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: asking what might happen in future releases
On Fri, Sep 11, 2009 at 01:45:28AM +0200, rembrandt wrote:
> The Markov-model sounds promising for me to use multiple cores for a
> single task.
Oh, splitting the workload across multiple CPU cores (or whatever) is
not any harder with other comparable cracking modes, such as with the
"incremental" mode. It's just that the current implementation of the
Markov mode makes the necessary controls available via the command-line.
> Maybe recent statistical analyses would support any effort?
> Amount of a charackter for a specific language or so?
>
> Today such informations could get gathered and proceeded more easily.
> I can imagine that different languages have different charackters and
> thus "more likely" combinations.
> So if I know the passwordfile is from poland I might could specify
> -lang=pl and gain a simply modified logic then the default one
You and others in the community can feel free to generate .chr files
specific to certain languages, countries, types of passwords (e.g.,
website forums vs. Unix accounts), or whatever. pyllyukko's recent
contribution of a Finnish .chr file is a good example. There can be
more of those.
It may well turn out that the bundled .chr files will outperform many of
these more focused ones on proper out-of-sample tests, though.
> (which is likely based on US-EN, or?)
The bundled .chr files are not intentionally focused on any specific
country or language, but there's definitely some bias.
> And if you might have some time in the future:
> What are your ideas, plans? Can the cummunity help or not...
> Maybe it would be time for a lil statement about what you've in mind.
I did make "statements" in here on some occasions. I am still toying
with the idea of starting a "community edition" of JtR, and I might do
it eventually. This would let people like Simon and Jim directly work
on a branch of JtR.
Going from a one-man project to a community project is not trivial.
I see how Nmap has successfully made this move, but I think it was a bit
easier for Fyodor since he could stay more focused on Nmap development
than I did on JtR development lately (for some years now). Maybe I
should have treated JtR as my "primary project", like Fyodor seems to
treat Nmap, simply because of the popular demand/needs. However, I do
have other interests, commitments, and needs as well.
That said, with some talented and capable people contributing to JtR in
multiple ways lately, allocating some of my time towards making a
community project possible makes more sense to me now.
Thanks,
Alexander
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.
