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, ))
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
