Jef said:
My solution is to store the file's bits in a specified pseudorandom permutation of the image's available bit positions. It's kind of like the frequency hopping of spread spectrum radio. This hides the length field very thoroughly. It also happens to hide anything else recognizable about the original file.
What you're doing can be written as steg(permute(pkey, <length, encrypt(ekey, text)>)) Note that the permutation is really a second layer of encryption, a bit transposition cipher. The obscurity-only approach of "#define PERMUTE_KEY 0xdeadbeef" would be pretty weak. If an opponent is to be unable to detect images with embedded steganography (stegnant images?) by looking for the length field, the permutation needs to be strong: large keyspace, strong PRNG, etc. Granted, it doesn't need to be as strong as the message cipher, because the plaintext is lousy (mostly encrypted), the payoff to the opponent on breaking it is less, and the target pool is much larger. But you do have the hassles of a second cipher -- at the very least, you need to distribute keys. Probably *private* keys, with their attendant distribution explosion. I think the Right Thing to Do is to require that the length indication or eof marker be inside the strong encryption (Stealth PGP or what have you). Now, we may not want to do that. First, we may have good reasons to preserve modularity by doing the length in the stegger. If the encryption is stealthy, we can get away with *only re-encrypting the length information*. Big win speedwise. If the encryption is not stealthy, it seems to me that we need a PGP headerstripper, not a permuter. The bulk of the file, after all, *is* stealthy. Tangentially, why choose bit permutation for your second-level encryption? There are plenty of schemes that will be a lot faster than doing all that bitmangling. Eli ebrandt@jarthur.claremont.edu