From: mgream@acacia.itd.uts.edu.au (Matthew Gream)
Date: Mon, 28 Feb 94 23:15:34 PST
To: sergey@delbruck.pharm.sunysb.edu (Sergey Goldgaber)
Subject: Re: standard for stegonography?
In-Reply-To: <Pine.3.89.9402281940.B11533-0100000@delbruck.pharm.sunysb.edu>
Message-ID: <9403010717.AA20839@acacia.itd.uts.EDU.AU>
MIME-Version: 1.0
Content-Type: text/plain



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