Re: HIDE: embedding msgs into snd & graphics

> I would have it take a GIF file and a
> binary file to be embedded, and produce an output GIF with the low order 
> bit of each byte changed to be the next bit of the embedded binary file.  

I've been thinking about writing this too, but, alas, I have been too busy.

If you write this program, I would encourage you to support encoding/decoding
in more than just GIF files.  My main reasoning behind this is something
like: if there is one piece of software that is commonly used to hide data
in noise bits, and it only supports one format, then things in that one format
are automatically suspect-- it's almost as bad as not hiding the data.

I'd encourage you to support JPEG and sunaudio formats (though the info
density one could store in each of these is probably a lot lower than what
you could pack into a GIF), as well as some less-used formats like tiff
and rast.  Hmm... and if you can figure out how to pack a useful amount
of data into an XPM, I'll be really impressed.

I don't know if you actually know GIF format (I don't) but I know that you'd
have to do some reasonably intelligent churning of the data.  For one, it's
just not going to be as easy as dropping a noise bit from each n-byte set;
GIF format is fairly compressed as I understand.  Also, if you're not
careful, you'll end up with a picture that chokes displays after encoding
that worked fine before encoding.  (Many machines have 8-plane displays,
which means a 256-color colormap.  If you mess with the noise bits on a
GIF that has 200 colors, you're going to come up with one that has 400
colors.  Many display programs (like xv) will compress the colormap when
they see this; the X server will also slide colors together when you
allocate things and the map is full.  BUT, such high-colormap-size gifs
would basically have "I AM A CONTAINER FOR ENCRYPTED DATA" tattooed on
the backs of their necks.

    -J

> I don't know if you actually know GIF format (I don't) but I know that you'd
> have to do some reasonably intelligent churning of the data.  For one, it's
> just not going to be as easy as dropping a noise bit from each n-byte set;
> GIF format is fairly compressed as I understand.

What you'd want to do is uncompress the byte stream, twiddle the low
bits, and LZW it back up.  Well, that's easy enough.  The problem is
that GIFs are colormapped, and the map need have no coherence
between entries 8 and 9.  Even optimally arranged (a non-trivial
task; looks like the salesman travels colorspace...), that low bit
is probably going to be significant enough to munge things visibly.
What you'd have to do is remap the file to 128 colors, duplicate
them in the colormap, and encode your message in the choice of
identical entries.  Unfortunately, most images look bad enough
mapped to 256 colors, and will degrade further in 128.  Though I
suppose nobody really wants to look at the image anyway...

Your compression is also going to die.  This may provide a quick way
to scan for this technique, and finding a redundant colormap is a
dead giveaway of either secrecy or stupidity.  You could fix that by
tweaking twin colors slightly, adding a bit of visible noise.

I think color images, as opposed to mapped, would be the way to go
for steganography.  More room, and nobody expects them to compress.

>     -J

	 PGP 2 key by finger or e-mail
   Eli   ebrandt@jarthur.claremont.edu