Re: standard for stegonography?

[Sergey Goldgaber <sergey@delbruck.pharm.sunysb.edu>]

On Tue, 1 Mar 1994, Matthew Gream wrote:

> Earlier, Sergey Goldgaber wrote:
>
> > You were originally referring to PGP in particular, were you not?
> 
> Nope.
> 

In that case, I retract my statements.  Sorry, I was under the impression 
that you were.

> What do you mean by non-standardised ?
> 

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.

> > "Pseudo-Stego" can be relatively secure as long as a large number of 
> > different hiding schemes/standards are used by the public.  
> 
> This is limited by the availability of software and the inherent qualities
> [of the] medium being used to carry the hidden information. 

Of course.  Most everything computer related is limited by those same 
factors.

> In any case, if the modulation method(s) is/are public, it by itself can't 
> be used to provide any means of security.
> 

I disagree.  If a great number of methods are available, using one will 
provide some measure of security, regardless whether or not it is public.
Only in the case where the _exact_ (public) method and _exact_ (public) key 
one has used is known to one's opponents that there is some loss of 
security.  Knowing a hundred different methods and tens of thousands of 
different keys doesn't get one's opponents anywhere.
 
> As for offset, do you mean that the public-key checksum value determines
> how much prepended 'garbage' to skip over before the real stego data 
> becomes available ? 

Yes.  And, the great variety of different offsets made available through 
the use of public-key checksum-values provide the increase in security.  
Of course, for the greatest security no standard whatsoever should be used.

> This still doesn't work, because it means not only a lot of wasted 
> bandwidth,

Wasted bandwidth does not a poor method make!

> but makes it a requirement to have a public-key
> in the first place -- any unnecessary tie in. 

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.

> All you want is a quick
> means to determine whether data has been modulated into the medium, and 
> if it has by what particular item of software. 

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.

We were speaking of standards, however.  Thus my proposal to offset data 
by the checksum-value of the reciever's public-key.  If one must use a 
standard of any kind this one would, I believe, provides enough variation 
for moderate security.  Please note that this standard, and the one 
you've presented are not mutually exclusive.

I simply believe that a standard stego-function which hides the data in a 
constant location makes for a poor stego-function.  That's where my 
proposal comes in.

> This needs to be hidden

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.

Fortunately, there is no need for this convention.  One would have 
determined that there is at least a possibility of data having been hidden 
in the medium before one attempted to use a de-steg function anyway.

> by some means (eg (cheaply) : s/ware_id + sigma(i=0-n) passwd[i] + csum)
> and, as you say, the information itself needs to be unstructured.
> 

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. 
Namely:

That it would require either:

  1 - A standard password (SEE ABOVE).

or

  2 - Dissemation of the password through secure channels.

So that this question may be asked: if you have secure channels, why do you 
need encryption?

> Therefore, you can pull pictures off alt.binaries.pictures.contemporary,
> run it though something w/ a password "russian_mole" and see whether your
> software says "I see this looks like it has a file created by program
> #s/ware_id, let me extract it". 

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!


Sergey