As part of a competition I want to manipulate (or decrypt) a file. I know, that the file contains gzip compressed text and is encrypted with AES / ECB / PKCS5. I also have the plain text and the cipher text of that file. I don't know the secret key. What would be a strategy to manipulate this file, so that afterwards it could still be decrypted and decompressed with the same secret key and the plain text would be different from the original one. Is that possible at all?
2
-
2$\begingroup$ You essentially have a dictionary now. You know that certain blocks correspond to certain (compressed) bits. You can now duplicate these blocks, you can remove them and you can re-order them. Use that. $\endgroup$– SEJPMCommented Aug 10, 2017 at 18:48
-
1$\begingroup$ Please have a look at my comment to Maartens response $\endgroup$– henrikCommented Aug 11, 2017 at 19:21
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
4
A block cipher is a permutation of all possible plaintext blocks and ciphertext blocks. That is: each plaintext block has a corresponding ciphertext block and vice versa. Which one depends on the key and direction of operation (encryption or decryption).
Now ECB just results in a succession of the plaintext blocks converted to ciphertext blocks. There are two things to notice: if a ciphertext block is changed then decryption of that block will always result in a different plaintext block. However, because you don't know the key you don't know which one. So unless you can choose a ciphertext block for which you know (part of) the plaintext, the result will be indistinguishable from random.
If you do know (part of) the plaintext for a ciphertext block then you can use this knowledge to put this plaintext block anywhere in the ciphertext. So you can reshuffle, delete blocks, duplicate blocks and put in blocks for random plaintext as you wish. However, you should always keep to blocks, not individual bytes.
There is only one rule when doing this: the last block should be left alone otherwise the unpadding is likely to fail. You should only replace it with a ciphertext block with correct padding, if at all (you may have received a previous message encrypted using the same key with a known plaintext/padding block that you can reuse).
Note that you require authenticated encryption or encrypt-then-MAC (with MAC'ed or known IV) to avoid the problem of replacing plaintext. Just using CBC or CTR mode - for instance - doesn't protect the plaintext message in any meaningful way.
answered Aug 10, 2017 at 21:43
-
1$\begingroup$ Thanks for your response Maarten. I had already tried, what you mentioned: Shuffling, deleting and duplicating blocks. The reading program decrypted the file without error. But in this case the program goes on with the next step, which is the decompression of the gzip stream. And then it fails because the streams checksum crc32 doesn't match or the stream is corrupt in another way. Any suggestions on this? $\endgroup$– henrikCommented Aug 11, 2017 at 16:14
-
$\begingroup$ Since the file is compressed and then encrypted re-shuffling the blocks will reshuffle the compressed data and that may not decompress correctly so there would be a lot of trial and error to pick a block that will correctly-compress. Not that it couldn't be done but that there is no direct mapping from the compressed block to text. $\endgroup$– zaphCommented Nov 9, 2017 at 1:47
-
$\begingroup$ @henrik if you have power to modify the data, the samy way it is possible to uncompress , modify and compress back effectively creating a valid gzip $\endgroup$– gusto2Commented Nov 9, 2017 at 9:00
-
1$\begingroup$ Henrik, of course a reshuffled ECB encrypted plaintext will decrypt to something else. If you can create a valid zip stream is a separate question; it may be pretty tricky to do that. $\endgroup$– Maarten Bodewes ♦Commented Jun 7, 2018 at 14:07