[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140705144914.8OZ94.931349.imail@fed1rmwml205>
Date: Sat, 5 Jul 2014 14:49:14 -0400
From: <jfoug@....net>
To: john-users@...ts.openwall.com
Subject: zip-aes improvements coming, and legacy zip format going away
I have gotten zip-aes working properly, with no false detections. It was actually very trivial. The pbkdf2-sha1 actually is used to compute 3 things. It computes the key used for AES decryption. That is 8, 12 or 16 bytes depending on using aes-128/192/256 logic. The 2nd part is the key used for authentication, which is simply an hmac-sha1 over the compressed and encrypted bytestream. The 3rd part, is the only part the legacy zip-aes was using. It is a 2 byte 'quick' checksum.
The speed degradation on my cpu build (non OMP), was not bad at all. it went from about 2650 to 2590 or so. And this is absolute worse case it could ever be. In the test code, the hmac-sha1 is performed every time. In the real world, it will only be done 1 out of 65k, so there should be almost no speed difference at all, UNLESS the .zip payload is huge.
It is possible that we can improve this, for huge payloads, by decrypting and starting the LZSS decompression on a very small part of the file. LZSS has a lot of deferential data built into it. by decrypting and decompressing (not actual decompressing, only walking the lzss 'framing'), we can eliminate pretty much any false possitive, prior to running the authenticator hmac-sha1.
Now the down and dirty.
The existing $zip$ format does not have much of the data we need to do this. We need to store the compressed and encrypted data blob (picking the smallest file in the zip logic has been added to zip2john), or SOME way to get this zip data later (file and location in the file of the blob). Also we have to store the authentcator data, which is also stored immediately following the zip data blob. So I have created $zip2$ which will handle this (and there may be some extra fields added with a reserved status). I talked to magnum about the $zip$ format strings, and we both came to the conclusion that it is probably pretty safe to simply drop that hash signature totally. There was a pretty nasty bug recently fixed, which pretty much eliminated this format from actually even working at all. So if a user does have hash signatures in his .pot file(s), they are almost certainly false positives.
So soon, zip_fmt_plug.c will have a new signature, and work in an 'exact' manner, and zip2john will also be updated. The older hashes will no longer be used, and zip2john will have to be run again, to get proper hash to decode the file.
(just a heads up)
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.
