Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.