[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <218BD03883544085B3C266C1DCD75346@ath64dual>
Date: Sun, 24 Jul 2011 04:50:15 -0500
From: "JFoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: patches page update
From: "Solar Designer" <solar@...nwall.com>
>
> Meanwhile, magnum has already submitted some patches against -jumbo-4. :-)
I have uploaded a patch, that fixes many things. This patch is on wiki. The
description of th patch pretty much tells what was added/fixed.
There were a couple of code pages added, and casing data added to rules.c.
This was done very late in the process, while I was moving my changes over
from my jumbo2 build env into the jumbo-4. I do not know either language
(kio8-r and cp1251 both cyrillic), so I may not have guessed right, on the
matching of UPCASE and lowcase characters. I gave it my best shot. If it
is not right, it should be very trivial to get that fixed.
This version also changes several command line switches.
--utf8 is gone, replaced by --encoding=utf8. There are also 3
other --encoding's possible. right now, the other 3 only affect the rules
processing. utf8 does not yet affect rules (it will slow down rules
processing A LOT). The utf8 affects some formats directly, mostly formats
which convert internally to Unicode.
A new command switch --pipe was added. This allows john to read from the
stdin, but it does so in the memory file manner, similar to how john reads
small(ish) word files today. However, the --pipe can easily read 100's of
gigabytes of data from the pipe, even if there is not that much memory.
The --pipe will read all it is allowed to (based upon --memory-file-size),
and will then process this 'block' of words. If it runs out of words before
filling, it of cource will start processing right away. Once it is done
with a block of data, it will get the next block, until the user exits, or
the pipe ends. The benefit of doing this, is that on systems which
the --memory-file-size provided a speedup, will also possibly see a speed
up. But the biggest benefit, is this allows --rules to be performed on
stdin data, which could not be done prior. NOTE, the biggest speedup of
the --mem-file-size was in the --rules processing, so this is a win-win
situation.
Added some new things to md5_gen, and fixed a few small bugs. Also fixed a
not-so-small bug, and now x86-64 bit builds now should work properly for all
formats. The change introduced in jumbo-4, which got things running, simply
did so by turning off SSE for the 'broken' formats. This is now properly
fixed, and these formats work correctly, and use SSE2i, thus are usually
much faster.
Jim.
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.
