[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <325ed878f4ac707c81eadc8b6334f5b9@smtp.hushmail.com>
Date: Fri, 26 Apr 2013 04:42:43 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: revised incremental mode and charset files (was: Bleeding-jumbo branch updated from core)
On 26 Apr, 2013, at 4:19 , Rich Rumble <richrumble@...il.com> wrote:
> On Thu, Apr 25, 2013 at 9:06 PM, magnum <john.magnum@...hmail.com> wrote:
>> For length, 15 is barely enough. Again, unless there is some kind of bad drawback, why not make a significant increase and ship it with 24 or even more, useful or not. And again you do not have to supply charsets that really go that far.
>>
>> If there is a significant tradeoff (speed? size? precision?), limit length a little from what I just suggested but not charset_max. Just my opinion.
>
> I've recently tried 15-20 characters from chr based on rockyou. Anything pver 11-12 characters (other than digit only) I can't find success with All.chr, however that's just me. At those lengths wordlists are the place to be, unless you can just let them run on and on, or you can really distribute it out, I'd say 15 is about all you can hope for max, pure alpha would stretch it, and I most work on fast hashes. But perhaps like you said, have Incremental: conf's contain the limitations and have chr files capable of more ship with JtR. I'd keep them at or below 15 in conf for sure.
OK, 24 might be stretching it :-) But I just today got excellent 13-character hits (trained from Rockyou with maxlen 16) for a test-set of 75000 hashes of various origin, and that was in a very short test (albeit using --min-len=13).
Also, 15 octets of UTF-8 Greek or Russian is less than 8 characters. Sometimes you train a very small set of words for various reasons, so I think at least 16 or 18 would be usable IRL - and like I said, unless there are real drawbacks, why not go for a "huge" figure and be done with it.
> It is slower as well because john still iterates the more likely character sets, and having a length like that will have some new comers scratching their heads, I think.
The support is (hopefully) not slower, only the use of it, when wanted. Even if we'd supply an all.chr with huge lengths, you can use --max-len or the more permanent john.conf MaxLen to limit it.
> If there were some filters (in conf) to go along with those CPxxxx (etc...) additions, I'm all for it. I won't need then often, but it'd be nice to know I can easily try them or create them, or an easily configured option to be just 0x32-0x7f?
We could have -inc:all include 8-bit, and add an -inc:ascii along with a filter_ascii, that does 0x32-0x7f. I was just going to suggest that. Also, we could add a filter_alnum-case (or whatever it should be called) for what you suggested in the other thread. I'm not sure about spaces though - IMHO they don't belong in alpha nor digits. Perhaps they could be included in alnum-case though?
magnum
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.
