Is there an algorithm or program that can take an image, be encrypted, still be opened by an image viewer, but is restored when decrypted?
Basically I want the ability to secure images but still have them seen as "image files".
$\begingroup$
$\endgroup$
4
-
1$\begingroup$ Welcome to Cryptography. Dou you want similar to Wikipedia ECB penguin? Here it is. $\endgroup$– kelalakaAug 11, 2019 at 6:46
-
$\begingroup$ Are you basically asking if crypto can make read-only images? Sorta like, people can still view the images, but the images are cryptographically protected from being edited? $\endgroup$– NatAug 11, 2019 at 17:21
-
1$\begingroup$ Or, are you asking for a crypto system that works on images, where the ciphertext is another image? And in this case, I suppose you're basically going for deniable encryption -- this is, if someone asks you to decrypt the image, you can claim that it's already decrypted because it's already an image? $\endgroup$– NatAug 11, 2019 at 17:22
-
$\begingroup$ I've closed this question as the title clearly indicates JPEG, and there seems to be a perfectly fitting answer for that. You could try and edit the question to remove that requirement - although I'm pretty sure that there have been questions about other image formats as well. $\endgroup$– Maarten Bodewes ♦Aug 16, 2019 at 9:37
Add a comment
|
3 Answers
$\begingroup$
$\endgroup$
3
This might come in handy : https://github.com/AtheMathmo/ImageEncryptor
It uses AES in CCB mode so with a key of long enough bitlength, you should have a fairly secure encryption.
-
$\begingroup$ This is great! Exactly the kind of process I was looking for. $\endgroup$– jrcichraAug 11, 2019 at 18:04
-
$\begingroup$ I think there is a problem with this library. The result has patterns that we don't expect. See the Wikipedia pengui. $\endgroup$– kelalakaAug 12, 2019 at 18:12
-
1$\begingroup$ This is a link only answer, doesn't describe how the image is processed, and when looking into it it shows lossless image encryption, not JPG encryption, which is the type required in the question's title. $\endgroup$– Maarten Bodewes ♦Aug 15, 2019 at 23:50
$\begingroup$
$\endgroup$
5
I wrote several papers on such a topic. I called it end-to-display encryption. But it is more commonly called "pixel-domain encryption" There are several easy ways to do this. My way included adding a header with RSA encrypted AES Keys.
In essence, you take the picture, extract the pixels, XOR with the bitstream created through AES in Countermode, increase the counter with every iteration, convert that to pixels, save as PNG (important, not jpeg or any other lossy compression, you lose bits with that, and decryption needs every bit to work properly). Thats it. And the same way back.
But sorry, no tool available. But its easy to implement.
I may extend on the thing with the JPEG in the question. Encrypting JPEG in the pixel domain will not work properly. The compression is lossy, so you lose information. There are compression methods on JPG, but they are much more complex, because they work mostly on the DCT factors, not on the pixels itself. These can also be viewed as pictures. That said, its another application field, as i wanted to decrypt pixel streams in the HDMI cable, that would not have worked as intended, or only with much more complex systems.
-
$\begingroup$ So do you do the typical IV gubbins in this scenario, or is IV always 0? $\endgroup$ Aug 13, 2019 at 12:47
-
1$\begingroup$ Sorry, i don't understand your question. What do you mean by IV gubbins? $\endgroup$– SangoAug 13, 2019 at 13:46
-
$\begingroup$ We use a random(ish) IV so that the cipher doesn't leak information, as in "It's the same data again". Given that you're already telling people that it's an image rather than some secret and unspecified generic file, that's kinda an information leak under some pretexts. So do you condone no IV in this situation..? $\endgroup$ Aug 13, 2019 at 14:52
-
$\begingroup$ Now i understand. Yes, there is an IV, this is transferred in plain text (pixels in the header) and is the nonce for the counter mode. So no tux in our implementation. As it was intended for changing images (RDP/VNC) this was absolutely necessary, and can change every frame, while the AES Key cant because of computation time needed. Yes, the picture is obviously encrypted, there is now hiding involved. There is a paper about doing that, BLINK. They use also steganography methods, to obscure that there is more than what meets the eye. $\endgroup$– SangoAug 13, 2019 at 15:02
-
$\begingroup$ "XOR with the result from AES" I presume you use some mode of operation that generates a key stream, such as counter mode encryption, but that may not be clear to everyone... Could you maybe flesh that out a bit more? $\endgroup$– Maarten Bodewes ♦Aug 15, 2019 at 23:53
$\begingroup$
$\endgroup$
You could combine encryption and steganography.
Steganography is the practice of concealing a message within another message. There is software available on many platforms that can embed a plaintext or encrypted message inside a jpeg image. Search for steganography.
You could encrypt your first image then embed that encrypted text (it may need to be Base64 depending on the software) into another decoy image.
The second image generally needs to be a bigger image (in terms of complexity, resolution etc.) than the first.
However you should be aware that steganography can be detected with special software but is usually imperceptible to the human eye.
