I'm dealing with a proprietary file format that contains a large file and some header data. Only a portion of the large file is encrypted within the 'packed' file. Specifically, the first 2,097,152 bytes or the first $200000 addresses in hex.

I have the program that encrypts the data and I can input any data I want. As much as I would just install a debugger and reverse engineer the program, my assembly is not that good and the proprietary software accesses numerous DLLs which confuse things even more.

What I would like to do is launch a CPA attack on the encryption algorithm.

I have encrypted various plaintexts. The method I used was to fill a file with 4,194,304 bytes of null chars (0x0) and then change various addresses to 0x1.

Initial analysis:

You can see that the encoding happens in 16 byte chunks. When comparing ciphers, if the first 16 bytes of the plaintext are equal, the first 16 bytes of the ciphertext are equal. If any byte of the plaintext is changed after a 16 byte block, the rest of the ciphertext is completely different from the original ciphertext.

I know that file length is not considered when encrypting the data, i.e. 1000 bytes of 0x0 will have the same first 1000 bytes of ciphertext as 2000 bytes of 0x0.

It looks like 31 or 32 bytes are added to the ciphertext somewhere, at the end? When the plaintext is 128 bytes, the ciphertext is 159 or 160 bytes.

Questions:
- Do you know of an encryption algorithm that produces ciphertexts in this "16 byte chunk" manner?
- Can any of these ciphertexts be decrypted to their corresponding plaintexts?
- Do you need any additional ciphertexts based on a particular plaintext?

The ciphertexts (only the first 96 bytes):
(Matching portions of ciphertext to first ciphertext (where the plaintext is all bytes are 0x0) are in bold.)