Re: HIDE: embedding msgs into snd & graphics

[blojo@sting.Berkeley.EDU (Jon Blow)]

> 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