In the encryption world, there is a substantial amount of debate over what entails good encryption, and what doesn't. You'll hear a lot of IT professionals claim that "any AES suite is fine" or "avoid 3DES" but outside of the people that actually work in security there isn't a lot of discussion about padding or which AES modes are best. I wanted to design an experiment where I could give visual evidence for what is a good cipher mode and what isn't.
Enter this simple bitmap experiment. You take a simple image, encrypt it, and then reapply the headers to make it a valid bitmap image again and look at what the encrypted data looks like visually. When doing this, you are applying no mathematical attacks or simplifications and no cryptanalysis. You're just looking at the raw encryption with your eyes and seeing if you can see any of the original bitmap in the encrypted code.
At the end of the article, I will post the commands entered into Ubuntu to replicate my results. The bitmaps were resized to appropriate sizes for the page from their original resolutions (1000x1000 down to 400x400) and converted to JPG to reduce bandwidth usage on the page. The original 1000x1000 bmp will be linked at the end of the article.
The Original Image (resized and jpg, full sized bmp at the end of the article)
I wanted to put this one first to show how dramatically bad ECB mode encryption is for this type of data. You can clearly see the logo and even read the text. There are clear patterns that can be discerned. This has to do with how ECB mode functions. It encrypts data using the same initial values derived from the data, so it gets the same results from data that is the same (like two like-colored areas of the image).
The XTS mode of operation, formally called XEX-based tweaked-codebook mode with ciphertext stealing is a spinoff of the ECB mode of operation that further complicates the encryption by splitting the original key into two different keys and implementing those. You can see the shadow of the image still in the encrypted data, and with some analysis would be able to see the original logo and text clearly. XTS mode does not protect from data tampering at all and is often accompanied by hash checking systems for data integrity checks.
This rather clear image shows that the problem is not with AES in ECB mode, it is ECB itself. In CAMELLIA in ECB mode you see the same problems as with AES.
DES in Encrypt-Decrypt-Encrypt (EDE) mode is a defunct mode that is no longer used. The NIST and other regulatory bodies dropped DES around 2002 in favor of AES. It is easy to see why.
AES in CBC mode is the worldwide standard of operation on the web today. The mode has extensive entropy because it uses chunks of encrypted data from the previous block, and appends it to the block that is currently being encrypted. This dramatically increases the entropy and makes discerning the original image through just visual analysis impossible. AES in CBC mode does have the disadvantage of being unable to combat tampering on its own. That is why AES in CBC is often accompanied by some flavor of Hash to do data integrity checks. Today that is mostly the SHA-1 and SHA-2 family of hashes.
AES in Galois Counter Mode is the current bleeding edge of encryption the is being used on the web. The biggest advantage that GCM has over CBC is built-in message authentication. AES in Galois Counter Mode tends to be slower than CBC with the same key lengths, so some developers, especially those who operate mobile apps, are hesitant to implement GCM. The concern surrounds the slower processors in mobile devices not being able to handle the encryption/decryption operations in a reasonable amount of time making apps and services seem sluggish.
This problem is improving with the propagation of multi-core processors in smartphones and tablets, allowing the advantages of GCM to shine over CBC.
To try this encryption experiment yourself:
All images were created using Ubuntu 14.04 (the client version) and OpenSSL version 1.0.1f-ubuntu2.5.
To encrypt a file using OpenSSL you have to enter information in this format:
openssl enc -cipher -in filetoencrypt.bmp -out encryptedfilename.bmp
So an example for this experiment would be:
openssl enc -AES128CBC -in VikingBW.bmp -out VikingAES128CBC.bmp
It will then prompt you for a password, for this experiment, the password "shittypassword" (without the quotes) was used. Changing the password will change the way the encryption looks color-wise, but you will get largely the same visual results other than a different color skew.
Once your file is encrypted, it will no longer be readable by apps until you reapply the bitmap headers to the image. You do this with the following command.
dd if=originalimage.bmp of=encryptedfilename.bmp bs=1 count=54 conv=notrunc
So, following the same example file names as before, an example of this would be:
dd if=VikingBW.bmp of=VikingAES128CBC.bmp bs=1 count=54 conv=notrunc
This will apply the original header of the image to the encrypted image, so that it can be properly opened as an image file. You have to do this step because the header is encrypted with all of the other information. Once this step is completed, you can open the encrypted file as if it was a regular image, and look at the encrypted image to see your results.
Here is the full-sized bitmap image if you wish to play with our image to try to replicate our results (warning, some mobile devices cannot open bitmap images without the appropriate apps):
Learn why Viking VPN Service is the Fastest VPN Service Provider.