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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ