2

Can adversary extract data from a deliberately corrupted archive?

If I archive a folder with 7zip, and I use a password (including header encryption) will garbling a few bytes at a particular offset of the encrypted archive make recovery by forensic software impossible without knowing in advance which bytes were deliberate altered?

If N bytes at offset O have been altered must an adversary trying to bruteforce the archive correctly reconstruct both the correct offset and original unaltered bytes before trying bruteforcing the archive password, or is there a shortcut to extract data from the encrypted archive in the case that some of the data have been (deliberately) corrupted?

Assuming for instance, that 5 bytes at offset N have been changed and the adversary only has incomplete knowledge of the original archive state, is it possible to "guess" all the original bytes data constituting the archive before proceeding with the bruteforcing of the password?

Can someone -- assuming that he can remember and later reverse the offset O and bytes N, use this method in addition to a good password to fool forensic software and maintain plausible deniability in the scenario that he is being compelled to disclose the password?

UPDATE

Sorry, what I intend to use is 7zip's builtin encryption AES-256 in conjunction with header encryption.

My question was concerned with (deliberately) altering the offset of an encrypted 7zip archive and if bruteforcing the password would even be feasable without reconstructing the altered N bytes at offset O.

  • 2
    As for plausible deniability, I'm not sure if it matters why the file isn't getting decrypted. Maybe you're giving them the wrong password, or maybe there's some other trick you're not disclosing. Either way you're likely to earn another whack with the wrench. – TTT Aug 5 '17 at 16:27
  • [in response to update] Ok, I can update my answer, but I feel that have already answered all of that. Can you clarify what you currently understand? Also, I'm also not familiar with "zip header encryption", and not finding anything useful on Google. Can you explain the concept and how it works? – Mike Ounsworth Aug 5 '17 at 17:38
3

There are a lot of assumptions baked into your question, so I don't think a general answer is possible, but I'll try to explore it a little.

I assume you have encrypted the archive using the standard "password-protected" mode that's built-in to zip tools. I'm not an expert on the zip file format, but it looks like there is no standard for which cipher to use; RC4 (stream cipher) and DES, 3DES, and AES (block ciphers) are all common choices. To answer this question, we'll need to explore how encryption ciphers work.

Stream Ciphers

RC4 is a stream cipher, which according to wikipedia, works like this:

A stream cipher makes use of a much smaller and more convenient key such as 128 bits. Based on this key, it generates a pseudorandom keystream which can be combined with the plaintext digits in a similar fashion to the one-time pad.

I have never studied RC4, but my understanding is that encryption is done one byte at a time by XOR'ing one byte of the keystream with one byte of the plaintext.

This means that, assuming you know the key, the 5 bytes you've mangled will decrypt mangled and be unrecoverable, but all bytes before it and all bytes after it will decrypt fine.

Block Ciphers

Block ciphers work totally differently from stream ciphers. It's a bit harder to explain, but we can look at the most common mode: cipher block chaining with this image from wikepedia:

CBC mode decryption

The important thing to note is that cipher text for a given block depends on the cipher text of that block and the block before it. So this largely behaves the same as stream ciphers in that the bytes you mangled (and one block after it) will decrypt mangled and be unrecoverable, but all bytes before it and all bytes after it will decrypt fine. (thanks @dave_thompson_085)


Brute-forcing the password

So generally speaking, unless you reverse the mangling, the bytes you mangled will be unrecoverable, but the bytes before and after will decrypt fine (whether the bytes after decompress fine is a different story, thanks @dave_thompson_085, but since compression is not designed for security, I'm sure a good forensic analyst could get information out of it).

In the context of an attacker brute-forcing the encryption key (ie the password), encrypting the zip header actually makes their job easier: all they need to do is try decrypting with random passwords until the first few bytes decrypt to a valid zip header (or the file header of the first file in the archive decrypts to a valid file header).


What problem are you trying to solve?

The XY Problem

Going back a step, it sounds like you want to enhance ZIP's password-based encryption and possibly add plausible deniability by inventing an obfuscation technique - or if you want to be able to reverse it, by inventing an encryption technique.

As @TTT colourfully put in a comment, I'm not sure you're going to be able to convincingly hack plausible deniability onto ZIP's encryption system.

As for enhancing it, why not just use AES and throw away (or don't throw away) the key? Or, why not skip using ZIP's terrible password-based encryption altogether, and just run the .zip file through GPG or openssl or some other better more modern tool that supports public-key encryption? (hint: native zip encryption was a badly-done hack when it was written, and now it's out-of-date hack. If you want proper security, then run your zip file through a proper tool rather than trying to salvage the hack).

  • 1
    CBC is not error-propagating; if you alter (any bytes in) one ciphertext block it changes that plaintext block to garbage and flips bits in the next plaintext block, and has no effect thereafter; this is precisely how attacks like POODLE and Lucky13 work. But WinZip-thus-7zip encryption is CTR which isn't propagating either. OTOH the compression usually used in zip, deflate, usually is propagating except when (explicitly) reset, which TTBOMK is never done for zip files (it sometimes is for online uses of deflate). – dave_thompson_085 Aug 6 '17 at 6:19
  • @dave_thompson_085 I feel silly now. I knew that about CBC too, I just didn't think it all the way through. Thanks. I don't know much about how compression works. Put up your own answer so I can learn something? – Mike Ounsworth Aug 6 '17 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.