Pure plain text messages are absolutely terrible candidates for subchannel encoding. A bit pattern that works out to the ASCII sequence "Secret meeting at 6 PM" is a dead giveaway (maybe literally!). Assuming you are aiming for stochastic-looking bit patterns, compression removes much redundancy. But watch out for compression headers: A subtext that begins with "PK" does not look like random data (for example, PKZip header bytes). The best choice is usually to compress plain text first (mostly just to save on a limited subchannel bandwidth), then to encrypt the compressed text second. Of course, you also have to watch out for encryption format headers (i.e., choose a format that is headerless). The use of a symmetric key requires a separate key negotiation out-of-channel; but use of public-key systems can avoid this requirement.

Without a doubt, the most important design issue in creating steganographic subchannels is: Don't use stock files! If you use files to which an attacker has access to the original copy, a simple binary comparison of the original with the new overt message will reveal that the file has been tampered with. This applies especially to image or sound files that exist in the public domain (or generally, in public, even if copyrighted). If you downloaded an image from the Web, so can an attacker. What you really need are entirely original files -- ones that you have a plausible reason for sending other than to hide subchannels. Home videos, for example, are bulky files with lots of unique subchannel bandwidth. Of course, if you leak these originals to an attacker, you have destroyed your system; the same applies if you encode different messages to different parties based on the same original. You should treat a steganographic overt message much like you would a one-time pad: Use once and destroy! However, multiple digitizations of the same analog original are possible; they will differ in much more than just the subchannel, so a binary comparison just shows them as wholly different files.