I think Kragen's definition of "Steganographically Strong" is a bit overstrong. He suggests that the cyphertext should not be recognizeable by its own program, with no checksums or program-specific delimiters, headers, etc. If checksums become widely used in other data formats (e.g. MIME or whatever), having them used in "innocent-looking-format" is ok. And having a checksum that only checks out if you have the correct key for decrypting the file is relatively ok, assuming you use strong encryption; it's really no more of a giveaway than having the correctly-decrypted plaintext have other recognizeable format, such as all-ascii or MIME or GIF. The request for a feature that corrupted files decrypt to total garbage and not just partial garbage can be implemented using some variant on doubly encrypting the file, e.g. descbc file | reverse-the-file | descbc. Most encryption systems can be used in modes that only trash the corrupted block, modes that trash the corrupted block and all following blocks, or modes that trash the corrupted block and some stuff after it, but eventually resync. The latter are useful for on-line continuous encryption systems like ethernet or T1 encryptors, where you don't want to send out guys with briefcases handcuffed to their arms any time there's a noise burst :-) One wimpy steganography approach I've thought of recently is to use uuencode. Each line starts with an indicator of how many characters are on the line, normally "M" for 64, followed by the characters; you could use variable-length lines with the length encoding your real (cyphertext) data at 6 bits/line. It'd be ugly, and probably noticeable, but you could always demonstrate that it outputs normal genuinely-innocent stuff by running it through uudecode. And it's only a factor of 10 less efficient than hiding it in a GIF! Bill Stewart