Reading encrypted bytes from an image in java

a 夏天 提交于 2019-12-03 21:55:46
Reti43

So here's what happens. Assume an original image of size WxH. Since you have 3 bytes per pixel, your image, orgnlimagebytes, has S = 3*W*H bytes.

Now you encrypt this image with AES, which results in a fixed block size of 16 bytes. If S is not divisible by 16, it will be padded to be so. If it is divisible by 16, another block of 16 bytes will be added. The point here is that the encrypted byte array, encryptedbytes, has a bigger size than orgnlimagebytes. Call this S'.

Now you use the method toImage to create a BufferedImage out of this byte array. You create a buffer of encryptedbytes, turn that to a raster and blah, blah, blah. You do end up with an image of size WxH. What happens, however, is that the BufferedImage object has a reference to the buffer which has S' elements. You only use the first S elements to construct the pixels of the image, but you can still access the rest of the elements from the buffer. So when you turn the BufferedImage to a byte array again, encryptedbytes2, you get all S' number of elements back.

The image only has WxH RGB pixels, so if you try to save that to an image file, that's all you're going to save. You won't save any of the additional bytes from the buffer reference. So when you save and load the image and convert that to a byte array, expectedbytes3, you get the expected number of bytes, which should be S.


This explains the unexpected inconsistency of the encrypted byte array before and after saving to a file. However, aside of the method of encryption, why do you even encrypt the cover image? It would make sense if you encrypted the message before hiding it in the image for extra security in case someone managed to both detect and extract the message. Encrypting the pixel values of the cover image means drastically changing them, which introduces apparent changes.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!