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 22.214.171.124 now: > > > > http://www.openwall.com/pvt/john-126.96.36.199.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 188.8.131.52: http://www.openwall.com/pvt/john-184.108.40.206.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 220.127.116.11. :-) 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.