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