Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Sep 2015 21:20:01 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Judy array

On Tue, Sep 15, 2015 at 07:32:06PM +0200, magnum wrote:
> Anyway: I was probably using a too good computer for my tests so far, 
> but one thing I saw clear: The one option "ReloadAtCrack = Y" is by far 
> the worst offender here. I have committed a change so it defaults to 
> being disabled. Even if read locks etc. can mitigate some of the 
> regression, that option is overkill: The remaining options are the 
> important ones.

Makes sense.

> Another thing is that -enc:raw (which you did not mention using at all) 
> will speed things up considerably.

Yes, I should try it.

> Maybe I should give up and 
> comment-out the default "DefaultInternalEncoding" line in john.conf. It 
> would have to come bundled with a bunch of documentation changes too though.

I am still confused by the encodings stuff.  I recall that during the
recent contest, we found that raw wasn't actually raw, and you later
fixed it somehow, but I still don't know how raw it is now.

> I also committed all your changes (except john.conf), with the prefetch 
> stuff wrapped in "#ifdef CRACKER_PREFETCH" (which is not defined).

OK, thanks!  I also had like 3 other versions of cracker.c prefetch
code, none of which helped at this specific test.

> Furthermore I committed a "best64" ruleset from Hashcat. The rules using 
> unsupported commands were commented out, and one "f" rule was added to 
> make it exactly 64.

Oh, but it already was exactly 64 using the ruleset Fred gave me, with
only JtR-incompatible rules commented out.  I've just diff'ed it against
what you committed, and I see that Fred's had this line added:

 ## high frequency overwrite at start
 o0d
 o0m o1a
+o0t o0b

This one is totally weird: overwrite the same character position twice?

Fred - where did you get this rule?

Where is the actual best64 ruleset, that won the best64 contest?  Maybe
we should use that one?  Or both (under different names).  It would
probably require us adding support for hashcat rules, though (which may
be a good thing).

> Finally I re-introduced a source() in MD4 and NT formats. I will do so 
> for the SHA formats too.
> 
> All the above just passed the build-bots' tests, so I'm committing to 
> bleeding right now.

Thanks.  Do those tests include running any cracking modes and seeing
how many those crack?  What modes?

There's significant risk of my cracker.c changes breaking something.

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.