From: Maaartin on 26 Apr 2010 07:14 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 26 Apr 2010 09:25 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 26 Apr 2010 13:00 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 26 Apr 2010 16:49 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 26 Apr 2010 17:24 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
First
|
Prev
|
Pages: 1 2 Prev: An application of indirectness and variability Next: bad client public DH value |