Adam Back writes: > The other kind of stego key is where the stego algorithm has a key to > guide the dispersal of data in the target data. (Eg select which n of > m possible bits in the LSBs of an image file to replace with the > message). This is very different. First, this is not an "other kind of stego key", since the previous case did not use a "stego key". It simply used the ordinary, well known public key of the recipient. The only private data needed is a convention known to all recipients about where to look for stego information, and even that is not necessary if he uniformly applies it to all his incoming data. With this "stego key" concept there must be pre-arrangement with the recipient and a shared secret key. This introduces all the traditional problems of secret key management. > The argument here is that the lower the encoding rate the more secure > it is, because the attacker has to both spot which bits have been > modified, and show an implausible statistical deviation from the > target data bits. > > Here using public information as the key (eg. key is hash of public > key) is weaker because that would inform the attacker which bits the > data was encoded in. It seems likely that any system using a stego key like this can be done just as well without a stego key, but with a public algorithm for inserting truly random bits. What is necessary is to find a statistical measure on the cover traffic which appears to be fully random so that the bits may be inserted without changing the statistics. Most of the purported advantages of the stego key come from the sparseness of the information insertion rather than the existence of a shared secret. > Stealth-2 has the remaining problem that it can't cope with multiple > recipients. > > This is not so easy to fix, because if there are multiple recipients, > you don't know how many recipients there are, and hence don't know, > where the bulk encrypted data starts. This is compounded by the fact > that you don't know what size their keys are. The only issue with multiple recipients is where the message itself begins, past the public key portion. All that is necessary is to include, in the public key encrypted data, a bit count for how many bits to skip. If this is done as a filter that can't manipulate the public key encrypted data, the bit-skip count can immediately follow the public key encrypted data, encrypted using the symmetric cipher and session key. > It might be nice to update stealth-2 for openPGP / pgp5. There you > have the additional task of coping with Elgamal key exchange. With > Elgamal you have g^k mod p, and m.y^k mod p which could be normalised > using Hal's algorithm relative to p. The other complication is that > you would have to try all private key on the keyring both Elgamal, or > RSA to decrypt. The same padding algorithm could be applied separately to the two ElGamal parts, a and b; or if you wanted to save some space, you could combine these two values as a*p+b and treat this as a uniformly distributed value < p^2, then pad that one value. As for trying all private keys, perhaps one key could be identified as being for stego purposes. Of course you are already filtering a large body of data to find only a few stego messages, and the additional work to filter with a few keys is probably not too bad.
