So this is an age-old example of why encrypting images with ECB is a terrible idea, since the underlying pattern of the image remains the same. Referenced from: If you encrypt an image (AES), is it still an image and can you view it?
In this question, the answerer shows that is is easy to reconstruct an image (in the ppm format) with:
# First convert the Tux to PPM with Gimp
# Then take the header apart
head -n 4 Tux.ppm > header.txt
tail -n +5 Tux.ppm > body.bin
# Then encrypt with ECB (experiment with some different keys)
openssl enc -aes-128-ecb -nosalt -pass pass:"ANNA" -in body.bin -out body.ecb.bin
# And finally put the result together and convert to some better format with Gimp
cat header.txt body.ecb.bin > Tux.ecb.ppm
The variation in this particular question is that, 1. I do not know what the header is, and 2. The header is not separated from the image.
To elaborate, let's say that I have a file called Tux.ppm
which I encrypt as follows:
admin@ubuntu32:~/Documents$ openssl enc -aes-128-ecb -nosalt -in Tux.ppm -out image.bin
enter aes-128-ecb encryption password:
Verifying - enter aes-128-ecb encryption password:
Though it is not relevant to the question, for the sake of completeness, the encryption password used was foo
.
Now, if I know what the header initially looked like, reconstructing the image is simple. Say, if I know that the header for Tux.ppm
was:
P6
265 314
255
Then, if I simply create a new file, call it header.txt
, add the above content to it, and execute:
cat header.txt image.bin > sampleTux.ppm
Then sampleTux.ppm
is still entirely recognizable:
Nevertheless, the illustrate a certain point, if I mess the header up just a little bit (e.g. modify the width to 275
and the height to 324
), the image screws up beyond recognition.
Say that I've now been given a file called image2.bin
. I know that this image was initially a PPM image which was encrypted like above (i.e. it was encrypted with its header). I know that it is a P6 type image which uses the 255 color-encoding format. What I don't know is the width and the height of the initial image, so I cannot construct a new header for it.
How can I create such an "ECB Pengiun" for image2.bin
? How can I get information about its initial width and height without guessing it (if that is at all possible)? As illustrated above, that width and height has to be quite exact, otherwise the image completely distorted.
EDIT: In the interest of making better guesses. Assuming that the image not compressed and was created from a standard A-series (A4, A5, etc.) paper, I know that is has a ratio of length-in-millimeters = sqrt(2) * height-in-millimeters
. Furthermore, it has a possible DPI of 72, 150, 300 or 600... which still leaves a lot of possibilities.
Maybe I could narrow down the possibilities further if I knew the amount of pixels in the initial file? Could I just get this information from the size of image2.bin
or would I have to do something infeasible such as reverse-engineer the process which AES encrypted the file in the first place?