So I have this question. I downloaded a .BMP off google due to .BMPs being not compressed. Just a 1024x768 .BMP image which its size os of 2.25Mb. I put the image in a steganography application.. inserted hidden text within it, encrypted and everything. How come the resulting image (Steganographied Image) is still 2.25Mb in size? Isn't it supposed to get bigger?
$\begingroup$
$\endgroup$
8
-
1$\begingroup$ It depends on the algorithm. Please add the application's name into your question, $\endgroup$– kelalakaOct 25, 2018 at 14:57
-
18$\begingroup$ Interesting experiment: compress the original and modified image with a lossless compression program (bzip2, zip, gzip, xz..), with the same settings. You'll often find that the original compress to a smaller size than the resulting image. That's especially true for originals that compress well, and relatively large message (especially, encrypted) in the embedded content. $\endgroup$– fgrieu-onstrike ♦Oct 25, 2018 at 18:28
-
1$\begingroup$ @fgrieu I think that this would prove inconclusive against an experienced Alice, especially with minimal sequential or random encoding. I'm unaware of a probability distribution modelling the original /compressed size ratio, so you wouldn't even have a p value. I also suspect that different archivers exhibit different efficiencies for varying levels of entropy content further complicating obtaining a p value. What can be inferred from a ratio of 1.0001? $\endgroup$– Paul UszakOct 25, 2018 at 21:36
-
$\begingroup$ Applications currently downloaded: SteganographyX, QuickStego, Steghide, Xiao Steganography and SSuite $\endgroup$– Matthew GoodlipOct 25, 2018 at 21:53
-
2$\begingroup$ An uncompressed raster image's file size does not depend on the color of its pixels. (Mainly just the resolution and color depth.) Typical visual steganography algorithms make nearly imperceptible changes to the pixels of the source image. (This is a lossy operation. If you were to remove the steganography part from the file then you would get a less detailed version of the image and not the original.) Merely changing pixels of an uncompressed raster (without changing color depth (or palette size) would not affect file size. $\endgroup$– Future SecurityOct 25, 2018 at 23:28
|
Show 3 more comments
4 Answers
$\begingroup$
$\endgroup$
5
If you consider the mechanics of embedding the image in it's simplest form, then all you do is repurpose some of the existing bits. The following is a Wikipedia extract from an article on steganography:-
For example, a 24-bit bitmap uses 8 bits to represent each of the three color values (red, green, and blue) of each pixel. The blue alone has $2^8{}{}$ different levels of blue intensity. The difference between 11111111 and 11111110 in the value for blue intensity is likely to be undetectable by the human eye. Therefore, the least significant bit can be used more or less undetectably for something else other than color information. If that is repeated for the green and the red elements of each pixel as well, it is possible to encode one letter of ASCII text for every three pixels.
which kinda looks like this:-
except that your message is encrypted. So the image remains exactly the same size.
The issue facing you (and your software) is how many bits can you alter and remain unnoticed? One certainly. The above example uses two and the altered image looks similar. Could you use three then? Clearly seven bits would totally destroy the image and tip off the attackers. It's a balance between leveraging the unavoidable noise introduced by the image digitisation process, the artistic scene and how dangerously you like to live.
Generally the blue channel is the noisiest from a CMOS/CCD sensor point of view. You might be able to inject additional bits into that channel without significant human detection.
Note: There are more advanced embedding methods that can alter the discrete cosine transform coefficients inside a JPEG file. This allows JPEGs to hide messages that would otherwise be impossible in this lossy format. There's a pretty good summary of advanced methods within the introduction to Data hiding inside JPEG images with high resistance to steganalysis using a novel technique: DCT-M3.
answered Oct 25, 2018 at 15:03
-
$\begingroup$ Does all steganography use LSB methods? Like how can i tell that an image is using LSB rather then another method? $\endgroup$ Oct 25, 2018 at 15:36
-
2$\begingroup$ @MatthewGoodlip It's difficult to tell what method is used (with encryption) as the encrypted message is computationally indistinguishable from random noise that might be there naturally. Two BMPs can be differenced pixel by pixel to highlight changes if you have an original. But that won't work on a pair of JPEGs. $\endgroup$ Oct 25, 2018 at 15:55
-
$\begingroup$ @PaulUszak "It's difficult to tell what method is used (with encryption) as the encrypted message is computationally indistinguishable from random noise that might be there naturally" -- this is incorrect, camera sensors do not simply produce random noise covering the sensor. Darker areas will have more noise than lighter areas; different sensors will create noise in different areas; and there are a million other factors that I haven't considered. It is easy to fool humans, much harder to fool a computer. $\endgroup$– flaviutOct 26, 2018 at 5:48
-
$\begingroup$ @user60561 then adjust your steno to incorporate those properties. Also there is no problem when the original noise is "louder" than the noise you introduced with stenography. $\endgroup$ Oct 26, 2018 at 8:13
-
$\begingroup$ @user60561 Agreed. But how would Alice tell Bob the embedding pattern if it's not constant? Wouldn't you be sacrificing additional (dark) bits for an embedded header block detailing the subsequent embedding pattern? $\endgroup$ Oct 27, 2018 at 1:45
$\begingroup$
$\endgroup$
2
I think you need to understand that Steganography does not add data to the image, but instead replaces some of the original data in the image. In your case, the replaced data is the LSB (least significant bit) of specific color channels. The original values of the LSB's in those channels are lost, and the data you want to hide comes in to replace it. Therefore it does not introduce any extra size to the processed image (ignoring compression which can be affected, but not for BMP which is some raw data without compression).
-
$\begingroup$ You meant that steganography does not add to the total amount of data. But it can add ciphertext into empty places, and that is certainly adding data. $\endgroup$– PatriotJul 2, 2019 at 10:00
-
$\begingroup$ I disagree with you because steganography can actually add data, and it is still steganography. Perhaps it is not very good, but it can still remain hidden, especially if no one looks. $\endgroup$– PatriotJul 2, 2019 at 10:03
$\begingroup$
$\endgroup$
5
The entire goal of Steganography is that someone examining the image cannot determine whether there is an encoded message in there or not.
Now, your original .BMP image consisted of 1024x768 3 byte values (the red, green and blue values).
Because that's the format of the original image, the image with the encoded message had to be in the same format. If Steganography changed the format, that might be a tip off that the image included a message.
Instead, the image with the message had to also consist of 1024x768 3 byte values, and so it is also $1024 \times 768 \times 3 = 2.25 \text { Meg}$ long.
-
$\begingroup$ Aaaaa okay. Now if i have let's say.. 5 applications that do steganography.. some with encryption some just hide the text within the image. How can i compare them if all of the applications end with the same 2.25Mb size result? $\endgroup$ Oct 25, 2018 at 15:35
-
3$\begingroup$ @MatthewGoodlip: compare them on what criteria? $\endgroup$– ponchoOct 25, 2018 at 20:10
-
$\begingroup$ I need to end up with some sort of conclusion for example.. application 1 hid the text better than application 2, although application 3 used better encryption methods. I meant what should i compare each other with if size is not an option $\endgroup$ Oct 25, 2018 at 20:17
-
2$\begingroup$ You should only really have to compare the encryption used. It sounds like the encoding of the data into the image is not as important to you. Encoding is only security-through-obscurity. The encryption is what you care about and you can compare those on their own. $\endgroup$– Rz MkOct 25, 2018 at 23:33
-
$\begingroup$ @MatthewGoodlip: actually, you should compare them to how well they do steganography. As for encryption, it's easy enough to encrypt the message using a standard encryption tool, and then use your steganography tool to encode that $\endgroup$– ponchoOct 26, 2018 at 21:01
$\begingroup$
$\endgroup$
3
You can remove steganography from the question and still use the same answer.
The bitmap with those attributes will always be the same size.
1024 * 768 pixels * 24 bits per pixel / 8 bits per byte / 1024 bytes per kilobyte = 2304.0 kilobytes / 1024 = 2.25
Applications and algorithms decide how to encode the data. Some methods of encoding change or diminish the visual appearance so it can skim bits to use for other purposes.
For example, one might encode data in an image by changing each byte to even/odd in order to signify a binary digit (0 or 1). That stream of even/odd becomes a place for you to write your own data. The pixels change, but you don't notice.
EDIT: If you use a compressed bitmap, then the output files will become larger as you seem to expect. That's because the compression cannot escape the fact that new unique data was added.
-
1$\begingroup$ You can remove steganography from the question and still use the same answer. HOW? $\endgroup$– kelalakaOct 25, 2018 at 23:48
-
1$\begingroup$ The bitmap with those attributes will always be the same size. 1024 * 768 pixels * 24 bits per pixel / 8 bits per byte / 1024 bytes per kilobyte = 2304.0 kilobytes / 1024 = 2.25 $\endgroup$– Rz MkOct 25, 2018 at 23:55
-
1$\begingroup$ This is the only answer that actually answers the question. The rest are distracted by steganography. The fact is that an uncompressed image is already at its maximum (and only possible) size, precisely because it's uncompressed! $\endgroup$– PodOct 26, 2018 at 15:31