[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20081209195129.GA16878@openwall.com>
Date: Tue, 9 Dec 2008 22:51:29 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Patch: Handle huge (>=4GB) wordlist
Robert and all,
On Tue, Dec 09, 2008 at 03:16:50PM +0100, Robert Annessi wrote:
> Attached is a minor patch to make john handle huge wordlists.
I approved this posting with the attached patch because the issue keeps
coming up once in a while (quite often in private e-mails to me),
however I find this specific patch wrong, and I suggest that it not be
used. One problem with it is that "--restore" won't work right for
large wordlists (which would be unsupported without the patch). Another
problem is that the patch is highly non-portable.
A proper patch would be to make JtR use the data type off_t for file
offsets, and to compile JtR with proper settings for the given system's
C library to enable Large File Support (LFS). Such compiler flags, to
be added into CFLAGS, may be obtained with "getconf LFS_CFLAGS" - this
command may be run right out of the Makefile. For glibc, the proper
addition to CFLAGS would be -D_FILE_OFFSET_BITS=64 ("getconf LFS_CFLAGS"
also adds -D_LARGEFILE_SOURCE, but this should not matter for JtR).
Unfortunately, these changes would make JtR somewhat less portable
and/or more complicated. The off_t data type might not exist on some
ancient systems, where it is still possible to compile JtR. (OK, maybe
it's time to disregard those. The few people who would compile JtR
there can add a "typedef" on their own.) Adding the output of "getconf
LFS_CFLAGS" into CFLAGS in the convenient and clear way would introduce
a dependency on GNU make. Adding -D_FILE_OFFSET_BITS=64 explicitly
might not enable the new functionality on systems other than those based
on glibc.
Starting to use GNU autoconf and automake is a solution (and there are
other reasons to go for it as well), but it's one I don't like very much
and have been trying to avoid so far. Yet it is within consideration
for future versions of JtR.
Finally, LFS is potentially needed for 32-bit builds of JtR only.
64-bit builds (running on 64-bit platforms, of course) support huge
files just fine, with no changes needed.
That said, I might integrate LFS on 32-bit into JtR at some point.
Maybe I'll start with JtR Pro (the portability concerns don't apply for
it) and the jumbo patch (optional and known to make JtR less portable
for other reasons anyway).
Thanks,
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
