From: Maaartin on
On Apr 26, 12:32 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> Maaartin wrote:
> > gordonb.21...(a)burditt.org (Gordon Burditt) wrote:
> >> So how does the recipient know which random bits to look at?  I
> >> presume it is a function of (a) image dimensions and (b) some kind
> >> of pre-shared key (to a PRNG?) that determines which bits are used
> >> in what order.
>
> > I'd suggest (c) all image bits except for the LSB.
>
> I am confused. Why "excepting" LSB? (Most schemes exploit "particularly"
> the LSB, if I don't err.)

Because you *USE* the LSB for the data. Just think:
- You use all bits including LSB for determining where to put the
data.
- You put the data in the LSB.
- You want to read the data.
- You use all bits including LSB for determining where the data was
put.
- This value differs from the first step.
- You're toasted since you never ever find your data again.

In fact, in a more complicated schema you could use LSB, too, but
you'd to do it in more steps (similar to Feistel network), so that in
no step you change the part determining what you change.
From: bmearns on
On Apr 25, 8:14 pm, jmorton123 <jmorton...(a)rock.com> wrote:
> Steganography Software
>
> In two to four weeks I will complete steganography software that will
> embedd encrypted data into 24-bit bitmap images.
>
> It will determine the image data length of the bitmap.
> It will determine the length of the message to embed.
> It will XOR each bit of the message with the LSB of  randomly selected
> unique bitmap bytes until the entire message has been embedded into
> the bitmap.
>
> Of course you must not use this technique on vector graphic images.
> You should use this technique only on RAW digital camera images
> converted to bitmap images and these images should be of natural
> scenes with a great deal of color variability.
> You cannot tell the encrypted data image from the original image by
> just looking at it.
> You cannot tell the encrypted data image from an examination of the
> LSB byte information because on average only half of the bits will be
> flipped and you won't know which bytes to examine because they will
> be chosen at random.
> As SOP you should encrypt the message before you embed it into the
> bitmap image.
> I am determining what percentage maximum of the bitmap image should
> contain the embedded encrypted message for added security.
>
> JM

I respect your enthusiasm for steganography, I enjoy the field a great
deal myself. With out meaning to offend, it sounds like you're
probably an amateur in the field, is that correct? There already
exists a large number of applications for hiding information in image
files of all kinds, using much stronger algorithms than the one you
describe; algorithms that are more robust and more transparent. I
strongly encourage you to pursue your interest in the field, and
continue exploring different techniques. However, I'd humbly caution
you against releasing software for this purpose without having a
strong background in the field. If you want to release it as a "toy"
application for others to play with and become introduced to the
field, I see no problem with that. But I think it would be rather
reckless and irresponsible to release this as serious security
software without the proper background and expertise.

If I've underestimated your expertise, I apologize. The algorithm as
you've described it sounds largely trivial and naive, but if I've
missed subtleties that make it stronger than it sounds, that's my
fault. Modifying LSBs of natural images is of course a familiar
technique and there has been a significant amount of steganalysis of
the problem. For instance, a technique developed by Dumitrescu, Wu,
and Memon [1] can estimate the length of a message embedded into the
LSBs of a natural image, regardless of how exactly it is embedded.

I hope I haven't offended you, it sounds like you've got a great basic
understanding of steganography. I only hope you'll make sure you have
the proper knowledge and understanding before applying it in real
world situations.

Best regards,
-Brian


[1] Sorina Dumitrescu, Xiaolin Wu, and Nasir Memon, “On Steganalysis
of Random LSB Embedding in Continuous-Tone Images,” in IEEE
Internation Conference on Image Processing, June 2002, vol. 3, pp.
641–
644.
From: Mok-Kong Shen on
Maaartin wrote:
> Mok-Kong Shen wrote:
>> Maaartin wrote:
>>> gordonb.21...(a)burditt.org (Gordon Burditt) wrote:
>>>> So how does the recipient know which random bits to look at? I
>>>> presume it is a function of (a) image dimensions and (b) some kind
>>>> of pre-shared key (to a PRNG?) that determines which bits are used
>>>> in what order.
>>
>>> I'd suggest (c) all image bits except for the LSB.
>>
>> I am confused. Why "excepting" LSB? (Most schemes exploit "particularly"
>> the LSB, if I don't err.)
>
> Because you *USE* the LSB for the data. Just think:
> - You use all bits including LSB for determining where to put the
> data.
> - You put the data in the LSB.
> - You want to read the data.
> - You use all bits including LSB for determining where the data was
> put.
> - This value differs from the first step.
> - You're toasted since you never ever find your data again.
>
> In fact, in a more complicated schema you could use LSB, too, but
> you'd to do it in more steps (similar to Feistel network), so that in
> no step you change the part determining what you change.

I believe there is misunderstanding (either on my or on your part).
As I understand (but maybe I had misunderstood OP), one uses a PRNG to
determine which pixels (i.e. the loaction, where) are to be modified to
convey stego-bits. If the LSB of a pixel is identical to the stego-bit
currently to be embeded, then do nothing, else flip it.

(If the above is not what OP does and turns out also not to be what
others do, then I would like it to be commented on as a proposal of
mine.)

M. K. Shen

From: Maaartin on
On Apr 26, 7:00 pm, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> Maaartin wrote:
> > Mok-Kong Shen  wrote:
> >> Maaartin wrote:
> >>> gordonb.21...(a)burditt.org (Gordon Burditt) wrote:
> >>>> So how does the recipient know which random bits to look at?  I
> >>>> presume it is a function of (a) image dimensions and (b) some kind
> >>>> of pre-shared key (to a PRNG?) that determines which bits are used
> >>>> in what order.
>
> >>> I'd suggest (c) all image bits except for the LSB.

> I believe there is misunderstanding (either on my or on your part).
> As I understand (but maybe I had misunderstood OP), one uses a PRNG to
> determine which pixels (i.e. the loaction, where) are to be modified to
> convey stego-bits.

Yes, but the PRNG needs a seed. I propose to compute the seed as the
hash of the secret key and of all image bits except for the LSBs. Just
look at (a) and (b) by Gordon.

> If the LSB of a pixel is identical to the stego-bit
> currently to be embeded, then do nothing, else flip it.

IOW, replace the selected LSBs by the message bits. This is fine (see
(3) by Gordon).
From: Mok-Kong Shen on
Maaartin wrote:
> Mok-Kong Shen wrote:

>> I believe there is misunderstanding (either on my or on your part).
>> As I understand (but maybe I had misunderstood OP), one uses a PRNG to
>> determine which pixels (i.e. the loaction, where) are to be modified to
>> convey stego-bits.
>
> Yes, but the PRNG needs a seed. I propose to compute the seed as the
> hash of the secret key and of all image bits except for the LSBs. Just
> look at (a) and (b) by Gordon.

I personally like to consider the parameters of a PRNG and the seed
together as the secret key (which should be unique for each message,
crypto or stego). How that is arrived at might be dependent to some
extent on personal preferences, I suppose. I would think that some
time-varying informations (time, message no. etc.) could advantageously
be used somehow for obtaining the said uniqueness of the key.

>
>> If the LSB of a pixel is identical to the stego-bit
>> currently to be embeded, then do nothing, else flip it.
>
> IOW, replace the selected LSBs by the message bits. This is fine (see
> (3) by Gordon).

BTW, the PRNG determines the locations of a bunch of pixels where the
stego bits are to be embeded. Should one then process, say, these points
from left to right and then from top to bottom of the image or should
one better process them in the sequence generated by the PRNG? (I
suppose the latter is to be preferred.)

If r is the ratio of the stego bits to the number of pixels of the
image, then obviously stegoanalysis would be harder with decrease of
r. I surmise that in some papers claiming good results of stegoanalysis
r was selected much too large by those who did the stego.

M. K. Shen