Encipher security concern

[ledlincoln]

I was experimenting with -encipher/-decipher, namely with using a binary file as the passphrase. I first enciphered an image (.png) using a 20 byte text file, then deciphered it with the same key, and it worked as expected. I changed a couple of characters in the text file, and an attempt to decipher resulted in only random dots, as expected.

When I tried using a binary file, as the documentation says is supported, the result was not as I expected. I enciphered the .png image using a small (35KB) .jpg file, and was able to decipher it fine with the same file. I then hexedit-changed a rather large block of bytes in image data of the .jpg key file, and used the new file as the key, and was able to decipher the image using the drastically modified key! I would expect that a single bit change in the key would make it unusable. Are only a limited number of bytes of the key put to use when encrypting/decrypting? FWIW, the .png image that I encrypted was around 219kB.

[magick]

What release of ImageMagick are you using? We replicated your steps. We changed a single character in the binary file and the resulting message was garbled as expected. For binary keys, you must use ImageMagick 6.4.8 or greater. For our test, we used 6.8.4-8. If you continue to have problems, post a URL to your source image, original binary key, modified binary key, and the commands you use. We need to reproduce the problem before we can comment.

[anthony]

Could it be that the file based passphrase gets terminated on the first null character?
One common definition of a binary file is that they can contain 'null' characters, that many programs do not handle right.

In that case a change after that first null will not effect outcome, but a change before it does.

That may be the cause of the inconsistent behaviour that was reported (and would be a bug).

[magick]

ImageMagick accepts null characters in the binary key as of version 6.4.8.

[ledlincoln]

Okay, the version numbmer is 6.7.3-1, running in Windows 7. I have posted all the relevant images, keys, and commands at
http://lincolndietrichs.org/magick/

[magick]

Perhaps a bug in your release of ImageMagick. We tried your images & commands with ImageMagick 6.8.4-9, the latest release, and the binary passphrase, key2.jpg, returned giggerish as expected. The original image was returned when deciphered with key1.jpg as expected.

[anthony]

The first command in the given directory file "commands.txt"

Code: Select all

convert orig.png key1.jpg secret.png

would generate files secret-0.png and secret-1.png as such is probably wrong, and does not appear to be needed.

Also you do not specify how key1.jpg and key2.jpg was modified.

[ledlincoln]

The first command in the given directory file "commands.txt"

Code: Select all

convert orig.png key1.jpg secret.png

would generate files secret-0.png and secret-1.png as such is probably wrong, and does not appear to be needed.

Also you do not specify how key1.jpg and key2.jpg was modified.

Correct, the first command was erroneous. The second and third were actually what generated the example images. As for how the key was modified, I used hexedit to change a large block of the image. You can see that by actually opening the image. That should be irrelevant, however, since changing even a single byte of the key should make it unusable.

This is solved in new ImageMagick version, which I will now post separately.

[ledlincoln]

I have confirmed that the bug appears to be resolved in version 6.8.4-10. Thank you all for your help.