Tell me more ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.
up vote 1 down vote favorite

Why AES based encryption is not recommended for encrypting images with high redundancy in their content? for example, the encryption of an image which shows a bird in the blue sky. Most of the pixels are blue in that case.

share|improve this question
I closed the question, as it seems (from the comments on the answer) that there are some non-standard requirements on your "image-encryption", which you didn't clarify in the question. Feel free to edit the question, and then we can reopen it. (Flag for moderator attention, or comment here.) – Paŭlo Ebermann♦ Oct 22 '12 at 19:10

closed as not a real question by Paŭlo Ebermann♦ Oct 22 '12 at 19:08

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, see the FAQ.

1 Answer

up vote 2 down vote

What do you mean "AES is not recommended for highly-redundant images"?

Perhaps you're referring to "ECB mode is not recommended for highly-redundant images" (and yes, AES can be used for ECB mode).

Yes, AES in ECB mode is not recommended for highly-redundant images, because it doesn't disguise when two 128 bit plaintext blocks are exactly the same. Here is a famous example of a drawing of the Linux penguin encrypted using ECB mode:

ECB mode encryption

As you can see, you can make out significant details of the original image.

AES in other modes (CBC, CFB, Ctr, GCM) doesn't have this weakness, and so are strongly preferred.

share|improve this answer
There are other problems namely codec compliant or fast online enc/dec see this paper or even large number of operations that are required to encrypt an image. Are these addressed by any algorithm? – user39576 Oct 10 '12 at 20:47
What codec problems? What large number of operations? How large are your images? AES can encrypt ~ 200 MB/s-1 GB/s on a modern computer. – dchest Oct 11 '12 at 18:00
@dchest: I meant ECB is much lighter than CBC in terms of the number of operations it requires. By codec problem, there is problem when you encode an image using any of AES modes, and pass it though any type of compression such as JPEG, you can not get the same image as you compress and then encrypt it. In addition, you can not open the encrypted file using any codec enabled viewer. – user39576 Oct 12 '12 at 22:05
@user39576 I quoted numbers for CBC; a few XORs is not a lot of additional operations. As for "codec problems" -- what's the purpose of opening an encrypted image if your current software doesn't understand that it's encrypted anyway? To look at white noise? The paper says it's so that "standard decoders can still decode the encrypted data without crashing". What kind of software crashes on a malformed input? – dchest Oct 13 '12 at 0:35
@dchest: You need to do those few XORs for each chaining so overall when the size of the image increases then the number of operations is also increasing. If you encrypt an image, you are not able to open it using standard viewers unless you redraw the encrypted block back to an image. This second step should not be in place which brings overhead once you deal with thousands of images. If the encrypted image can be viewed using a standard viewer then may be formation of a pattern can be seen which ensures that image is perceivable after encryption using any method or not. – user39576 Oct 13 '12 at 4:09
show 1 more comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.