[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01bd01cd4d6b$488aae60$d9a00b20$@net>
Date: Mon, 18 Jun 2012 10:59:02 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Reduced binary size
>From: magnum [mailto:john.magnum@...hmail.com]
>
>Obviously, get_source() will not be safe if we use a reduced (32 bits)
>binary. We might produce false positives, as we never really compare
>with the full original binary. These false positives will be "reset"
>(hashes will be regarded as remaining) on next run/resume of the hash,
>as the john.pot hash will not match the ciphertext. But it's still not
>acceptable. I see no way other than making these techniques mutually
>exclusive, unless someone has a clever solution (theoretically,
>get_source could re-read the original source from its file).
I am going to toss something out, not that I have thought this through, but
to get discussion going. Would there be a way we could store the offset to
the hash within the input file, and have get_source use that? I could see
something like that being done on non-salted types. We do have a pointer
'free'. This pointer originally was used for the source. It has been
repurposed to point to the actual salt. But for a non-salted format, could
we steal this, yet again, and jam a file offset into it?
I know that on 32 bit builds, we have limited ourselves to 2GB (32 bit
signed) file sizes for many thing. A 32 bit pointer is proper sized. I
would imagine, that on 64 bit builds, that original 'source' pointer is 64
bits, thus it should also hold a file offset (64 bit offset).
This would make this field (the source pointer), be one of 3 types of data.
However, if there is no get_source(), it will ALWAYS be the allocated
source. If there is a get_source() defined in code, then this element in the
current_pw structure would get a salt pointer for salted formats, or a file
offset for non-salted. Now, a non salted 'could' have all of the binary
bits there, if we have not taken other steps to remove them. Then it can
ignore the pointer.
One other 'way' to do this, is to pass in the index to get_source(). This
method 'may' allow us to rebuild, AFTER the crypt_all has been run. There
may be issues where this method is not ideal, and may not be 'good enough'
for many formats.
Again, just thinking out loud here.
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.
