Earlier, Sergey Goldgaber wrote:
In your message you made a proposal to the effect of implementing a stegonagraphy standard whereby a standard header is encrypted. I thought you were implying that the key should be constant for that stegonagraphy program. I simply noted that security would be limited if this were the case. Using a new key every time one encrypted would be an example of what I meant by a "non-standardized" key.
I did mean the former, yes a standard header, but obviously a user defined/supplied key -- the system would be worthless otherwise.
This still doesn't work, because it means not only a lot of wasted bandwidth,
Wasted bandwidth does not a poor method make!
No, but in the case of steganography it does make it an impractical requirement.
The method I outlined does indeed require a public-key. Using the method is, as you have pointed out, not necessary. You have not, however, shown why you believe the method doesn't work. You have simply outlined what you _don't_like_ about the method.
No, I outlined two reasons. Firstly, an offset method such as you mention wastes a lot of bandwidth. Say you take a conservative 16 bits as offset (which is already too easy to brute force), there you have up to 64kbit of potentially wasted bandwidth in a transmission medium that needs as much as it can get. See for example pixel 'stegging', you'd need exceeding large pictures just to overcome the offset noise let alone modulate data of any practical length in. The second reason, which yes can be construed as more a personal dislike, did regard the prerequistite for a PKCS. In retrospect, I'll retract that.
Ah! This is where we don't see eye to eye. I believe that the purpose of stegonagraphy is to hide data. Having "a quick means to determine whether data has been modulated into the medium, and if it has by what particular item of software" is a detriment to that effect.
I agree with the first and foremost as well, steganography is there to hide data. But by the same token, if the data is hidden, how do you know there is any there ? Isn't the idea that _you_ have a quick means to determine whether something has been hidden there, else it looks like harmless information ? With your method, you're leaving it up to whatever particular information has been stegged in to have some inherent integrity check. Ie. this would work if you stegged in PGP data or signed data. But what if you stegged in something else, how do you know it was stegged data ? All I was proposing was a method of providing a header encrypted so you _know_ that what follows is stegged information, that was my original intent.
If the information that informs one that something is hidden in the media is itself hidden, how can it be a means to determine if something is hidden? How would you determine if there is information that informs one that something is hidden in the media, hidden in the media? See the problem? Your whole purpose is cancelled out by your method.
No. You see it works like this. When you go to insert data ('stego it') into the medium, you prepend some header, but you encrypt the header under a cipher. This header contains a signature plus other information. Because it's been encrypted, it looks like junk, it shouldn't be (within limits of your stego medium) discernable from the original bits that where there. After that header follows the stegged data. When someone wants to remove stegged data from the media, they then pull out a certain number of leading bits using a pre defined steg method for that media. Those first few bits are decrypted to either reveal a structured header, in which case you can proceed to remove the rest of the data, or to reveal junk, in which case there is nothing there, at least nothing for you.
As long as you're proposing header encryption via IDEA, why not consider doing the same to the whole file? It would increase security. There are objections to be levied against any non-public-key system, however.
Yes, that would be a good idea too (excuse the pun .. :-).
So that this question may be asked: if you have secure channels, why do you need encryption?
I have seen this point, and yes, I guess it is a problem. You would need to at some stage in the past agree on a key to use. How about changing that from IDEA to RSA then ?
It would be even easier to get the same picture and run it through your stego software which would look at your public-key and extract the file automatically. This would be pretty secure, easy to use, and require no secure channels!
But then why offset in the first place? What is going to be at the offset that can't be at the front of the file ? If something structured is going to be at an offset, then it's easily susceptible to being brute force searched. Okay, how about giving up using some form of offset and just RSA encrypt a header with the intended recipients key. To check, you'd get your stego software to pull out the first 2048 bits and decrypt the first X bits corresponding to whatever your modulus length is with your private key, if the result is "*STEGO FOLLOWS*+other", then theres a file there, else you know nothing exists there (at least not for you ..). However, this is half hearted because after thinking about it, I've come to the conclusion that it's probably best if all the software does is push the bits in and leave it up to Stealth-PGP (or other software) to provide a means of creating the header and the proceeding data in a way so that no key-ID's or so on exist. Then you could just "desteg < art | stealth-pgp > out" and watch Stealth-PGP's exit code. The desteg software shouldn't attempt to put anything in to identify the presence of stegged data tho. Matthew. -- Matthew Gream. ph: (02)-821-2043. M.Gream@uts.edu.au. PGPMail and brown paperbags accepted. - Non Servatum - ''weirdo's make the world go around'' - A.Watts