Would it be possible to add additional files to a password protected zip 2.0 file

Question

I don't have the ability to determine/recover the master password for a production system that uses zip 2 archives. However, I need to be able to add new files to existing encrypted archives. There are various tools out there that can 'break' the zip 2.0 encryption with a known-plaintext attack, which allows recovery of the contents. However, I am not interested in recovering the contents.

Since these tools recover key's 0-2 (3x 4-byte key triplet) per the zip 2.0 appnote (scroll to nearly the very end), in theory would it then be possible for those tools (or a modified open source zip utility that can write encrypted zip 2.0 archives) to initialize the keyset with the known-to-decrypt key triplet, generate a 12-byte 'random', and then use these values to add additional files to the existing archive?

The goal, in layman's terms, is to add 06_14.dat, 07_14.dat, 08_14.dat, etc. to a backup file that the backend system can read.

Note that simply adding unencrypted files won't suffice - the system uses a hardware token for the encryption/decryption key (which is why I can't possibly recover it) AND it tries to decrypt each file individually using the logic: 1) lists archive; 2) sorts by the above names where the first 2 digits represent the month 01-12 and the second 2 digits represent the year for 1997-2014; 3) and then tries to extract the NEWEST file first - bail upon first decryption failure. If the current file that it wants to decrypt/decompress, matching the ##_##.dat signature, isn't encrypted then it bails too.

More specifics of the system shouldn't be necessary, but the reason this issue has occurred is because our front-end system that shared the symmetric key (and auto-appended the .dat files for us) has passed on to the otherworld where obsolete hardware goes once it malfunctions.

I'm open to possible solutions to the problem, but just a lively discussion on whether this is feasible/practical/etc. is more than enough - I'll build the solution if this line of reasoning appears possible.

Answer 1

Generally speaking, you are right: given the keys 0, 1 and 2, it is possible to produce the encrypted form of any other file for the same password, even if the said password is not known. If you follow this road, you will probably be interested in Info-ZIP, a clean opensource reimplementation of the PKZIP format.

Alternatively, you may want to recover the actual password, or an equivalent password (which yields the same keys 0, 1 and 2). For that, consider the attack described in this paper, especially section 3.6. This is the attack that is implemented by the tools that you talk about; from keys 0-2, the password, or at least a matching password, can be rebuilt with (much) less cost than exhaustive search. If you obtain such a password, then you will be able to use standard Zip tools to manipulate your archives, which may avoid a lot of trouble.