1994-03-04 - Re: Standard for Stenography?

Header Data

From: Sergey Goldgaber <sergey@delbruck.pharm.sunysb.edu>
To: Hal <hfinney@shell.portal.com>
Message Hash: acee75838b0cda9396a5a272be7347e3b0db44aab675af000140ade28c9d287d
Message ID: <Pine.3.89.9403031857.D23725-0100000@delbruck.pharm.sunysb.edu>
Reply To: <199403031607.IAA08429@jobe.shell.portal.com>
UTC Datetime: 1994-03-04 00:02:44 UTC
Raw Date: Thu, 3 Mar 94 16:02:44 PST

Raw message

From: Sergey Goldgaber <sergey@delbruck.pharm.sunysb.edu>
Date: Thu, 3 Mar 94 16:02:44 PST
To: Hal <hfinney@shell.portal.com>
Subject: Re: Standard for Stenography?
In-Reply-To: <199403031607.IAA08429@jobe.shell.portal.com>
Message-ID: <Pine.3.89.9403031857.D23725-0100000@delbruck.pharm.sunysb.edu>
MIME-Version: 1.0
Content-Type: text/plain


On Thu, 3 Mar 1994, Hal wrote:
 
> I share Jef's disagreement with the spectacularly bad "neon sign"
> steganography header, but I don't think Sergey's approach was correct
> and I hope he does not feel the issue is closed yet.  

I never thought it was.  Thank you for joining in the discussion, BTW.

> Bill Stewart is IMO far more experienced and has far better 
> understanding of the issue than Sergey, who has been a list member for 
> only a few weeks and again IMO suggests a very naive 
> security-through-obscurity approach. 

I welcome any and all of Bill Stewart's comments on this issue.
I have, since the beginning, noticed a distinct dislike of 
"security-through-obscurity" among the senior members of this and other 
similar lists/newsgroups.  Many people preach this dislike.  Most 
don't seem to understand its foundations fully; neverthelless, they 
consider it a closed issue and usually don't bother to explain why.

I am glad that you are offering your insight on this, Hal.

> Bill Stewart, Norm Hardy, and other list members who have more experience
> and who have discussed these issues in the past will I think agree that the
> correct approach is to separate the function of the stegonography program
> to be a simple and clean insertion, and to have other components be
> responsible for assuring that what is inserted is statistically indistin-
> guishable from what is replaced.
> 

This is the most elegant solution,  I agree.

> This notion that a "secret offset" will prevent the stego from being
> discovered is highly naive IMO.  The correct approach is to make it so
> that the stego cannot be recognized even if the opponent knows where it is.

That would be ideal, I agree.

> Adding offsets is like attempting to "improve" regular RSA by putting a
> secret amount of noise padding at the front (not of a stego file, but of
> an openly encrypted file).  This is unnecessary if you trust your encryption,
> and if you don't trust it then this approach should not make you trust it.

I do not trust my encryption to be foolproof.  If I believed that adding
noise at the front of the file would help, I would do it.  I still wouldn't
trust it, but I would feel safer with every new security-through-obscurity
layer.

> Similarly, if your stego is so weak that knowing where it is in the file will
> allow the opponent to detect it, adding a random offset should not make you
> feel secure.  The correct approach is to have statistical identity between
> what you are inserting and what you are removing.  The stego program itself
> should then be as simple as possible.

This is my defense of security-through-obscurity:
  
Security-through-obscurity adds layers upon layers of potential effort 
needed by one's opponents to get at whatever it is that you are obscuring.
A good analogy would be the length of one's secret key.  A one bit key, you
would agree, is not very effective.  The bits in the key, the more effort
your opponent would have to expend in brute-force analysis.  Similarly, 
the more layers of obscurity one has, the more effort your opponent would 
have to expend in bypassing/guessing your methods.

I have often heard it said that one should always assume that one's 
opponent knows everything except one's secret key.  To me, this makes no 
sense!  If your opponent is good enough and determined enough to get by 
all the layers of obscurity you may have put up, than its just one more 
step to getting your secret key.

You have stated that my oppinion is naive.  Please enlighten me.

> Now I will add my own little moral lesson, in the spirit of Tim and Jef.
> Sometimes when these discussions are re-hashed, old-timers are too busy or
> bored to join in.  New list members express naive views that are not vigor-
> ously refuted.  This is OK, but then some other new member takes these views
> to represent list consensus.
> 

So the views of these naive new members should be "vigorously refuted" 
(ie. flamed) in the intrest of other naive new members?  Have you considered
changing that to "constructively criticised"?

> I think it is great that Jef is working on a steganography implementation,

That it is!

> but IMO the notion of "random offsets" is so fundamentally misguided that I
> hope he will reconsider.
> 

I dissagree.  In a perfect world, with perfect encryption and perfect
steganography "random offsets" may be superfluous.  As it stands now, we
need all the obscurity we can get.

> Hal Finney
> hfinney@shell.portal.com
> 


Sergey






Thread