[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <010601cc2aac$4340bf40$c9c23dc0$@net>
Date: Tue, 14 Jun 2011 11:01:03 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: add support for cracking RAR archive passwords [GSoC first cut]
You certainly do not want to exit.
Since the words come from some external dictionary file (usually), and
sometimes after there have been other rules that have increased it,
frequently there are passwords that are very long indeed. Trimming of the
passwords is the way to go. There are often 'dirty' dictionaries which can
be found, where there are some good words in, but lots of extra trash (some
of it long lines). Things like web site html scraped, and words from the
entire site ripped out, often have quite a bit of trash following along
(even lines that are 100's of bytes lone) but also have some good words
which can crack passwords for that specific site. The 'best' choice would
be to ignore these altogether, but that is not always possible. On some
formats, if they test one PW at a time, they could have code added which
takes these long words that would get truncated, and set a flag to be used
by crypt(), set_salt() and cmp_all(), that flags them to do no work at all,
and simply return that this word does not crack any salt. I would not add
any code like that, unless the format was very slow (as slow, or slower than
say phpass), and only for formats cracking one password at a time. In cases
like this, it would make sense to not trim the word, but simply have a flag
that quickly ripped through testing, always listing that this word did not
work. However, for many formats, more than one password is tested at once,
and if a single one was overlong, then there is no way to tell john to skip
this one.
There is a field within the format structure which should do this trimming
for you. However, having code in the setkey, to validate that a longer key
than should be is not attempted, is not that bad. It does slow down
cracking a bit for fast formats, but makes no difference at all for slower
formats, especially salted formats, since the set_key() is only called one
time and then set_salt() is called for each salt to be tested against this
password.
Jim.
>From: Łukasz Odzioba
>I found that in Dhiru's code:
>
>set_key(char *key,int index){
> int saved_key_length=strlen(key);
> if( strlen(key)>PLAINTEXTLENGTH)
> saved_key_length=PLAINTEXTLENGTH;
>...
>}
>Alexander, magnum is it ok with JtR's official rules?
>It's better to let JtR "crack" that key or maybe it should just do
>exit() with a proper information?
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.
