Image Encryption With
Graphics Software
© 2010 Tim Fort
Introduction
Ever since childhood, I have had an amateur interest in cryptography. My favorite cipher from the Pen-and-Paper Era of Cryptography was the one-time pad because it was the only one that was proven to be theoretically unbreakable by information-theory guru Claude Shannon. Now that we're in the Cyber Era, the sophistication of ciphers for text and data streams has moved far beyond anything Lord Playfair and Vigenère could dream of to encompass things like quantum cryptography and public-key systems. Because mainstream cryptography has moved far beyond the pig-pen code and the scytale, I've been increasingly drawn to the odd corners of the cryptographic world. One of my fringe cryptographic interests was in finding a way to encrypt images graphically in a way that could be done with any reasonably good graphics software by anybody who isn't a professional cryptographer.
The tried-and-true method of adding encryption to a picture is through steganography, which is the art of creating hidden images. In the digital world, this is done by methods like least-significant bits in bitmap images or flashing subliminal messages in a video stream. Steganography is very useful for putting digital watermarks in an image; however, it isn't very secure from a cryptanalytical perspective. Once an eavesdropper suspects that there's a hidden message in an image, it's usually broken very easily.
If security of the image is paramount, then the usual method is to take the image file and encrypt that like any other data file. This has several drawbacks: first, if you're not well-educated in cryptography and computer programming, you have to run out and buy somebody else's encryption software. Then there's the very likely possibility that the software company or some government agency has a 'backdoor' method of reading files encrypted by the software. Finally, any cryptographic system that isn't based on a random, one-time key is theoretically breakable.
A graphics-based system for encrypting images has several advantages. For starters, you're not dependent upon a specific piece of encryption software, but can use just about any reasonably sophisticated graphics program. You directly control the making of cryptographic keys and the encryption process rather than have it happen 'under the hood'. This gives you reasonable assurance that no software company or government agency has a backdoor way of hacking into your encrpyted images. Since my method is based on the graphics equivalent of a one-time key, it has the advantage of being unbreakable--at least in theory. And, finally, making your own encrypted images with graphics software is gosh-darned fun for those of us who are terminally geeky.
So, how does one go about encrypting an image anyways? My intuitive guess was that a key image the exact size of the plain image would be added as a layer in Photoshop, then some sort of filter would add the two images together into a final encrypted image. It seemed obvious that the key image would have to be made out of noise (resembling 'snow' on old analog TVs) as that seemed like the closest graphical analog to a one-time key. I also experimented with the different filters in my graphics program and finally decided that the Difference filter was the most useful because it was fully reversible. I did a test encryption by adding noise to a normal image to get the following:
As you can see, the results are less than perfect and it's quite easy to make out the original image in the noise. I'm still not 100% sure why it didn't work as planned, but this failure spurred me on to find a better solution. I first read up on Moni Naor and Adi Shamir's clever method of visual cryptography using plastic transparencies. I modified this method to work with my graphics software and later expanded it to work with RGB images instead of just black and white. I then removed a superfluous step or two--and pretty much ended up where I started, but with a slight twist. That slight twist was to reduce the number of colors in the key and plain images to a specific eight-color palette before adding the two images together. This was the theoretical breakthrough that made my method practical.
How It Works
For starters, you need to create a palette file corresponding to the '3-bit RGB palette' unless your graphics software already has one. This is not very hard and only has to be done once. The 3-bit RGB palette is basically all eight permutations of the red, green, and blue signals being fully on or fully off (i.e. 23=8). Those eight colors are black (#000000), white (#FFFFFF), red (#FF0000), green (#00FF00), blue (#0000FF), yellow (#FFFF00), cyan (#00FFFF), and magenta (#FF00FF).
With my graphics program, PaintShopPro, I started by creating a tiny image file, 1x8 pixels, and colored each pixel one of the eight colors. Then I reduced the number of colors in the image to eight indexed colors before saving the palette file as 8color.pal. Depending on what graphics software you use, your mileage may vary slightly.
The next step is the creation of the key image which should be the same size in pixels as the image you wish to encrypt. Any decent graphics software has the capability of generating graphic noise--which resembles snow on old-timey televisions--and the key image should be filled with 100% random noise. The more uniformly random the key image is, the better. After filling the key image with noise, you then need to reduce the number of colors in the image to your eight-color palette. With PaintShopPro, it's just a matter of loading in the palette file 8color.pal and then selecting the 'nearest color' or 'ordered diffusion' option for the color reduction--either one works fine. If everything works out, you should end up with a key image that looks like this:
Since there's only eight indexed colors in the key image, it saves nicely as a GIF file. This example is only 206 kB which is comparable for a JPEG of similar size.
Next, you need to prepare the plain image that you want to encrypt. For illustrative purposes, I created this test image which combines a photographic image of a flower with line art created with the eight-color palette. The original image file was a bitmap, but I saved this as a JPEG to save on bandwidth.
I'm guessing that most decent graphics software gives you two basic choices for reducing the number of colors to those on the eight-color palette. One of them is 'nearest color matching', but I wouldn't recommend that because it tends to posterize the image with a severe loss in picture quality as can be seen in the example below.
Instead, go with the 'ordered diffusion' or 'color dithering' option, depending on your software. You may be given several choices in the type of color dithering; simply choose whichever one you think gives the best results. Color dithering helps to preserve the colors of the original image at a cost in image resolution. When the test image is reduced to the eight-color palette with the 'ordered diffusion dithering' option selected, it appears like this:
The image may appear to be excessively light and snowy, but the image degradation isn't as severe as it first appears as I will demonstrate later. As you can see from the simple graphics on the left side of the test image, any line art done in the eight basic colors doesn't suffer any degradation at all.
Now comes the part where the plain and key images are combined. With my graphics software, and probably with yours, it may be necessary to increase the color depth of the plain and key images to full- or 16-million color before adding them together. Once that's done, simply copy the key image, then paste it onto the plain image as a new layer. Then use the Difference filter to 'add' one layer to the other. With PaintShopPro, the Difference filter can be found under 'Layer Properties'. Merge the layers together and the final image should be the encrypted picture.
Since this encrypted image should only have eight colors to it, the color depth can be reduced back to the eight-color palette and the file can be saved as a GIF file with eight indexed colors. The encrypted image should look also like pure noise, so it's easy to get the encrypted and key images confused. If everything works right, the encrypted image should look like this:
To decode, simply reverse the process and 'add' the key image to the encrypted image using layers and the Difference filter. With this process, there's no difference if you add the key image to the encrypted image or vice versa. When decoded, you should get back the eight-color reduction image of your original picture.
If you save the key and encrypted images from my example to your computer, you can test the process with your own graphics software.
As I stated earlier, the loss in picture quality by reducing the plain image to eight colors isn't as severe as it first looks. I selected the photographic part of the test image and blurred it slightly with PaintShopPro to get this final image.
As you can plainly see, the loss in resolution is relatively slight. If you're concerned about preserving as much picture resolution as possible, simply enlarge the original image before reducing the colors to the eight-color palette. Once the picture has been decoded on the other end, it can be blurred slightly and then reduced to the original image size to produce a very good approximation of the original image.
Practical Considerations
Since this method of image encryption uses the graphical equivalent of a one-time key, it should theoretically be unbreakable. To work properly, however, each key image must be used once and only once. If a key image is used to encrypt two different plain images, then the security of the two encrypted images is lost. An eavesdropper simply 'adds' one of the encrypted images to the other with the Difference filter to yield a composite image. The composite image is made out of the two plain images added together and it's usually quite easy for the eavesdropper to make out the details of each image as in the example below.
Blur the composite image slightly, invert the colors, and it's not too hard to see both the lakeside landscape and the owl-shaped wall clock superimposed on each other.
To repeat: for absolute security, use each key image only once. If the correspondents want to exchange encrypted images in both directions, having separate sets of key images for both sending and receiving might be a good idea to prevent a key image from accidentally being used twice.
Then there's the issue of exchanging keys. Nearly all encryption systems require the correspondents to share a key either in person or through a secure channel like a diplomatic pouch. In many cases, just a password needs to be exchanged, but with one-time keys, the actual keys themselves have to be physically swapped. Luckily, we live in an era of laptop computers and flash memory, so this isn't a difficult thing to do. The key image used in my example is only 206 kB in size, so I could easily put over 4,000 key images on my tiny, outdated MP3 player.
As for the size of the key images, I'd go with a larger size like 1600x1200 pixels. If the plain image is smaller than that and you don't want to enlarge it, the key image can be trimmed to size using the Canvas Size command in your graphics program. Just work out a consistent convention like keeping the top and left borders equal to zero when trimming the key image, and everything should work smoothly.
A final consideration regarding security of this process is the randomness of the noise in your graphics program. I don't know enough about graphics software to know if the noise generation routine is truly random or is based on some sort of deterministic algorithm that merely cranks out a pseudorandom stream of numbers. Personally, I'm satisfied with the randomness of the noise-generation routine in PaintShopPro. If, for any reason, you don't trust the randomness of the noise in the key image, you can use all sorts of Photoshop tricks like flip, mirror, rotate, and cut 'n' paste to further randomize things. If you're really proficient with graphics programs, you might figure out ways of generating noise from images yanked at random off the Internet.
A Final Word
One of the most overblown clichés of cryptography is the person who claims that his cryptographic system is utterly secure and foolproof. I hereby state that my system isn't foolproof and you probably shouldn't depend upon it being unbreakable, especially if you're using it for espionage or other illegal activities. I offer it mostly for the amusement of the Terminally Geeky who need some sort of justification to waste, er, spend countless hours playing around with graphics programs. Enjoy!