[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111123063149.GB30677@openwall.com>
Date: Wed, 23 Nov 2011 10:31:49 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: OpenMP for MD5-crypt
On Tue, Nov 22, 2011 at 07:54:03PM +0100, magnum wrote:
> 2011-11-22 00:52, Solar Designer wrote:
> > There's 1.7.8.9 now:
> >
> > http://www.openwall.com/pvt/john-1.7.8.9.tar.gz
>
> Both of them (as well as CVS-Jumbo now) pass Test Suite for all builds I
> can produce on Linux/intel. I wont test other archs right now.
Great. It turns out there was a bug with OpenMP builds on big-endian.
This should be fixed now in 1.7.8.10:
http://www.openwall.com/pvt/john-1.7.8.10.tar.gz
> I also played around a little with --make-charset and incremental. It
> seems to be forward and backward compatible with 1.7.8
Yes.
> as well as j5c4
No. It just appears to be compatible, but it is not. This is one
reason why I chose not to release j5c4 publicly.
> (when compiled with their respective parameters). Seems to work like a
> champ. I'm surprised inc.c was not touched at all.
That's on purpose - to keep the .chr files compatible with 1.7.8's.
Breaking compatibility to achieve a more optimal order of candidate
passwords tried, like we did in j5c4, is a next step. Of course, I'll
need to do it in a more correct manner than I did in j5c4, so the
compatibility breakage would be apparent rather than hidden.
> You're not going to ship it with 0x7f and length 8, are you?
I am. Otherwise I need to supply new .chr files right away, which I'd
rather do when I include other incremental mode enhancements. I don't
want to break compatibility an extra time.
Also, with different settings people won't be able to --restore sessions
that they started with 1.7.8 or earlier. They'd need to revert the
settings and recompile first. If I find time, I may solve this in code -
letting a single build of John load different kinds of .chr files.
> My vote
> would be 0x20..0xff and length 16 even though the supplied charset files
> would not have to utilise that fully. Would this have downsides?
This would currently have downsides mentioned above. Additionally, it
increases memory usage significantly with no way to reduce it back (e.g.
--save-memory won't help here).
> It would be a FAQ killer for sure.
Definitely.
Well, for now we'll be able to say that the CHARSET_* settings may be
modified almost arbitrarily, with no 64-bit integer overflows anymore.
Oh, and I got rid of the dependency on pow() and -lm in 1.7.8.10. :-)
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.
