What are advantages of chaos based image encryption methods over simply treating images as opaque bit strings?

Question

For an exercise at uni I am tasked with optimizing the execution speed a chaos based image encryption algorithm 1. While I have taken an introductory class to information security, I never came accross chaos based encryption before and have been unable to find any authoratative resource explaining its significance. Can someone explain its significance to me?

Further the paper 1 claims that image encryption is a special case of encryption due to its size and redundancy. However I can't grasp the difference between an image and repeated text of the same size.

Image encryption, in particular, is urgently needed but it is a challenging task—it is quite different from text encryption due to some intrinsic properties of images such as bulky data capacity and high redundancy, which are generally difficult to handle by using traditional techniques.

Similar questions have already been answered 2, 3 and 4. Can it be said with certainty that chaos based encryption is not useful at its current stage?

Answer 1

Chaos-based encryption is at worst snake oil, at best of dubious use. The answers you linked to go into this in some detail.

Modern encryption algorithms have a very high data rate and are efficient and secure with highly redundant plaintext. These chaos-based papers just throw some statistical analysis of the resulting ciphertext at you claiming equidistributed pixels/symbols, whatever. it takes more than equidistributed ciphertext to prove security.

When the speed advantage is minimal due to the speed of modern, well-understood, and widely tested encryption algorithms, then why go to chaotic generators [by definition of chaos there is no guarantee of performance in chaotic sequences]? There is no point.

Answer 2

What are advantages of chaos based image encryption methods over simply treating images as opaque bit strings?

The principal advantage of the term "image encryption" is that when it is used with a straight face, you can immediately discount the author, journal, and publisher as peddlers of bullshit—lacking in any familiarity whatsoever with the foundations of modern cryptography, and devoid of meaningful editorial standards.

For an exercise at uni I am tasked with optimizing the execution speed a chaos based image encryption algorithm 1.

This is unfortunate, but perhaps you can tremendously optimize the execution speed by crumpling up the paper, tossing it in the rubbish bin, and just using an existing implementation of standard modern cryptography like ChaCha or AES-CTR—or, better, ChaCha/Poly1305 or AES-GCM, to prevent forgery too.

Further the paper 1 claims that image encryption is a special case of encryption due to its size and redundancy. However I can't grasp the difference between an image and repeated text of the same size.

Your intuition is spot-on. Modern cryptography is secure even if the adversary can choose the most convenient patterns they want in the plaintexts. Specifically, the modern standard for confidentiality of a cipher is IND-CPA: indistinguishability under chosen-plaintext attack. This standard loosely requires the adversary to be unable to tell ciphertext of one plaintext from ciphertext of another plaintext of their choice—even if they can study the ciphertexts of as many such plaintexts as they want.

Of course, confidentiality, and IND-CPA, is only part of the story. Usually you also want to detect forgery too, so an adversary can't fool you into acting on a message your counterpart didn't actually send. The standard for that is UF-CMA, unforgeability under chosen-message attack, and combining them appropriately gives you authenticated encryption, etc. But the point is that all modern cryptography is secure even if the adversary chooses the most convenient patterns in messages for their attacks.

Answer 3

This is a compression problem, not a security problem. As other answers point out, it's not a different problem from redundant text, and modern crypto is secure even in that case.

If file size is a problem, and the input is an uncompressed image with raw RGB or YUV data, compress first with lossless WebP, Jpeg2000, HEIF (an HEVC aka h.265 I-frame), or even PNG (although that compresses each row separately so you could have similarity between rows.) https://en.wikipedia.org/wiki/Lossless_compression#Raster_graphics

Modern image codecs will find redundancy and compress it; their final output is typically a bitstream from a compressor like Huffman, gzip/Deflate, or something that solves the same problem, and will hopefully have found redundancy between similar blocks across the image. A simple image will get much smaller, closer to its Kolmogorov complexiy.

Of course, image compression is much slower than just throwing the input bits through AES, so it's a speed/size tradeoff, although for highly-redundant images with simple compression it can still save a lot without being too slow.

"Decrypting" then involves decompressing, which is fast. Any metadata from the original image needs to be sent, too, to reconstruct the original file if you want this to be fully transparent. That's possible; lossless archive compression software like RAR and maybe 7-zip already have filters to handle image files specially.

---

Compressing before encrypting has the same problem as usual, revealing information about compressibility. This can be a specific problem in text that's always the same except for one small secret, so I guess that might be something to be careful of for images, too, in the rare use-case where the image data is of a form or something and the way it's filled in is with a fixed font or by shading boxes.

Is it better to encrypt before compression or vice versa? mentions some of the problems for text, with things like TLS. And that lossy compression to a constant bitrate for video or audio would avoid leaking info via metadata (size).

Lossy compression can achieve quite good perceptual quality (for human vision or hearing) while shrinking files a lot, especially for video (redundancy between frames is usually high) but also individual still images. If you're building a whole system for transmitting multimedia stuff securely, you could make lossy compression part of it. If you're just encrypting data transparently, that implies lossless.