How to set a flag in image bits to mark the end of an audio file

Question

Currently, I'm trying to hide audio files of wave formats inside images of bitmap format.

I transformed both of them into binary form and now I'm trying to set some kind of flag to mark the end of the audio file so that when I'm extracting the audio from the image I know where to stop.

Notes to consider 1: the image is 24bit.

2: the audio data is PCM 16 bit.

3: I'm using LSB so each 16 bit of audio needs at least 5 pixels and an element of the sixth pixel (5*3 = 15 + 1 =16).

Answer 1

You are correct that you can't rely on an end-of-file marker, because all byte values are probable in your bytestream. Therefore, you have to use a header. This has to be implemented in an unambiguous, so that the decoder knows where and how to look to extract its information. This simply translates to having the header at the beginning of your message and in this case, it'd be convenient, though not necessary, to have it as a fixed size.

If your message can be longer than 65536 bits, then your message size will obviously need more than 16 bits, for example, 32 bits. Now, you may argue that if you're embedding a very small message, a 32-bit message size header will have too many zeros at the beginning and it will be overkill. However, even if you're planning to embed 1 kB of data, an extra 32 bits will barely add any extra noise.

By Kerckhoff's principle , you should indeed assume that an attacker has full familiarity of your scheme and if you embed your message in a static way, it should be straightforward for them to extract it. Instead, you can use a password or key as the seed to a PRNG and then use that to shuffle the order of your pixels. For example, let's call the RGB components of the first pixel by the numbers 1-3 respectively and the components of the second pixel by 4-6. By generating the array [1, 2, 3, 4, 5, 6] and shuffling it, you may get the order [4, 3, 2, 6, 5, 1] . So, when you embed your secret (including the message size), the first bit is hidden in the red component of the second pixel, the second bit is hidden in the blue component of the first pixel, etc. Nobody can say this is "visible", because without the correct pixel order they can't meaningfully extract the message.

However, you have to remember that steganography is the art of concealing information in another medium, without someone even suspecting its presence . In comparison, cryptography is about publicly transferring your message, but encrypted in such a way that only the intended participant can know its contents. What this means for steganography is that one doesn't necessarily have to extract your message to defeat the purpose of it. You're busted just for the fact you're secretly trying to transmit information, regardless of whether its contents can be read. You are aware that LSB pixel modifications method are broken, so trying to make them ever so slightly more secure is pointless. Instead, just worry about playing with the method to get your hands dirty and learn a bit about steganography.