[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100205045439.GA15667@openwall.com>
Date: Fri, 5 Feb 2010 07:54:39 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Replacement for all.chr based on "Rock You" Passwords. URL inside.
On Thu, Feb 04, 2010 at 07:34:46PM -0700, Stephen John Smoogen wrote:
> On Thu, Feb 4, 2010 at 6:50 PM, Solar Designer <solar@...nwall.com> wrote:
> > You will likely need to release some updates, though - considering my
> > input above and/or changes to JtR itself. Speaking of the latter, I am
> > going to re-work the "incremental" mode, for the better indeed.
[...]
> Sorry about my slowness, but would this mean that all.chr and
> incremental would be useful for larger passwords versus having to hack
> and recompile (and make new .chr files) for large hashes. I had been
> looking at various MD5 hash files that were being dropped in various
> pastebin's last year and had to make various john's to try incremental
> against 10, 12, and 16 character passwords. each one of course had
> smaller number of characters that the .chr could use to test against.
Yes, I am planning to deal with the length limitation at the same time
with my other changes to this code.
> Also will the changes also allow for 7bit ASCII characters? The
> RockYou passwords have a large combination of UTF-8, ISO8900-x, ASCII
> and various other ones... when I built up previous .chr's they were of
> course ignored :). I am guessing that some supprot for multi-byte
> characters will be needed at some point as more of the world swings
> that way.
Yes, I am hoping to allow for 8-bit characters with the new incremental
mode without a recompile.
As to multi-byte characters, that's trickier. If I try to deal with all
shortcomings of the current implementation at once, I might never come
up with a new implementation ready for release. So I am going to
recommend the use of external filter() functions for translation to/from
multi-byte characters. That is, you translate multi-byte (a specific
subset) to 8-bit (or even to 7-bit) when you generate a .chr file, and
you translate 8-bit to multi-byte when cracking. I'd like to see someone
actually try that, then we can learn from the experience and see if
anything needs to be implemented in JtR itself (and what exactly).
I have no experience with multi-byte characters in passwords myself.
If there were any multi-byte characters in the passwords you used to
generate a .chr file from, then you're likely wrong in that they were
fully ignored. It could be worse than that. Some of the bytes of those
characters could instead have been processed as individual characters,
thereby distorting the statistics for single-byte characters.
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.
