March 23, 2018 at 05:20Strong encryption of data in PNG
Good morning Habru. I read an article about hash steganography through social networks yesterday , and it occurred to me to make something more optimal in terms of the amount of output. It turned out to be something more or less efficient and even optimized (unlike proof-of-concept romabibi ), therefore, as promised , I am writing an article.
Well, say hello again:
and welcome to cat.
I decided to implement the idea asbluntly as possible , so I will describe the encryption algorithm briefly:
The line (in the form of bytes) is written in a square in the upper left corner of the image, merging with white noise. The result is something like some kind of texture - for example, a stone from the game Minecraft. Judge for yourselves:
Of course, it is easy to understand that this is a cipher, however, without an algorithm, it is not so easy to decrypt it (after all, you need an AES key, and not everyone will use a format with prefixes and double compression).
Well, we got a picture. What to do with her now? Send to recipient, of course. True, he must know the key and the algorithm (or script) of decryption in advance. And everything would even be good, if not for one “but”. And this “but” is compression.
Obviously, keep the original social images. networks are not profitable. VK, for example, even converts PNG to JPG, using not the smallest compression ratio. And, since we use specific byte values (0-255), their loss will not lead to anything good. The solution is to send the received images as documents (files).
I rolled up the deployed script into 101 lines with exceptions and displaying progress and runtime in stderr. You can always find it in the repository here . Most likely, I will gradually refine it, although lately I have divorced enough projects (including those that are harastrusty).
True, I think this article (which grew out of the commentary) has exhausted itself. I will be glad to hear the suggestions of other algorithms, and helpfully code them for you by adding to the same script.
Thanks again to romabibi for the idea; adios.
Well, say hello again:
and welcome to cat. I decided to implement the idea as
- Fitting the key to a multiple of 16 (for AES encryption)
- Compress source data using zlib
- Fit to a multiple of 16 lengths and encrypt compressed data
- Recompress encrypted data
- Calculate MD5 hash from encryption key for comparison during decryption
- Finding the minimum amount of '\ 0' that does not occur in a row in the text to be used as a data separator and white (literally) noise
- Preparing a grayscale image and filling it with random data
- Recording a line (data_length + MD5_key_length + MD5_key + data) over noise
The line (in the form of bytes) is written in a square in the upper left corner of the image, merging with white noise. The result is something like some kind of texture - for example, a stone from the game Minecraft. Judge for yourselves:
Of course, it is easy to understand that this is a cipher, however, without an algorithm, it is not so easy to decrypt it (after all, you need an AES key, and not everyone will use a format with prefixes and double compression).
Well, we got a picture. What to do with her now? Send to recipient, of course. True, he must know the key and the algorithm (or script) of decryption in advance. And everything would even be good, if not for one “but”. And this “but” is compression.
Obviously, keep the original social images. networks are not profitable. VK, for example, even converts PNG to JPG, using not the smallest compression ratio. And, since we use specific byte values (0-255), their loss will not lead to anything good. The solution is to send the received images as documents (files).
I rolled up the deployed script into 101 lines with exceptions and displaying progress and runtime in stderr. You can always find it in the repository here . Most likely, I will gradually refine it, although lately I have divorced enough projects (including those that are harastrusty).
True, I think this article (which grew out of the commentary) has exhausted itself. I will be glad to hear the suggestions of other algorithms, and helpfully code them for you by adding to the same script.
Thanks again to romabibi for the idea; adios.