From: Sergey Goldgaber <sergey@delbruck.pharm.sunysb.edu>
Date: Fri, 4 Mar 94 01:48:29 PST
To: Hal <hfinney@shell.portal.com>
Subject: Re: Security through Obscurity
In-Reply-To: <199403040657.WAA02068@jobe.shell.portal.com>
Message-ID: <Pine.3.89.9403040306.C25451-0100000@delbruck.pharm.sunysb.edu>
MIME-Version: 1.0
Content-Type: text/plain


On Thu, 3 Mar 1994, Hal wrote:

> Security through Obscurity
> 

Thank you for a very enlightening post, Hal.  

Just a couple of comments:

> To sum up, obscurity is not bad.  What is bad is to confuse obscurity
> with security.

If I have understood you correctly, there is nothing wrong with equating
obscurity with a practical, albeit temporary, increase in security.
Equating obscurity with ultimate security is a mistake.  As is equating a
"strong" algorithm with ultimate security.
 
> In encryption, the opponent's desire is to find out the original message.
> What is the opponent's desire in steganography?  I feel it is to be able
> to prove or determine with some degree of certaintly that there is a
> hidden message.  We use steganography in a context where sending such a
> message openly is for some reason undesirable.  Hence our goal is to
> prevent the opponent from knowing that a message exists.

I would like to propose that there is a goal, in addition to those you have 
revealed, for the opponent as well as the legitimate user of steganography.  
The opponent would, ideally, wish to not only determine that there is a 
message within the data; in addition, he would prefer to be able to extract 
that message for analysis.  Therefore, I believe that it would be to the 
advantage of the stego-user to not only hide the existence of his message, 
but to do so in such a way that the cost of successfully extracting that 
message, by his opponent, is maximized.

> A test, then, for the success of a steganographic technique is this:
> given some sampling of data items, half of which have embedded hidden
> messages, can the opponent guess which ones have such messages with
> better than 50% accuracy?  If not, the steganography is fully successful.
> If he can do slightly better than 50%, it may still be useful depending
> on the situation.  If he can guess with 100% accuracy, the steganography
> has failed and is totally worthless.

If one accepts the additional goal proposed above, the value of an extra 
test is obvious.  This test may consist of an attempt at message 
extraction, as per your guidelines.
 
> Now, it is true that this is assuming that there is no "key" information
> used in the steganography.  The NoStO principle would lead us to
> investigate keyed steganography, where the receiver has specific secret
> information which the opponent would not have.  But if we are going to
> do this, we have to accept the costs.  That key must be kept just as
> secret as the keys in an encryption system.  We can't just let it be
> something obscure like a checksum based on a public key, information which
> the opponent will have as well.  It has to be *secret*.  That is what
> NoStO tells us.  If we want the benefit of a key, we have to pay the cost.

I have to take exception with the assertions made in this paragraph.  
Using the principles of public-key systems, the steganography key itself 
does not have to be kept secret.  The sender, reciever, and indeed the 
opponent would all have access to this key without compromising the 
security of the system.  The challenge, for the opponent, lies in figuring
out which public-key the sender has used.  I have no statistics on 
exactly how difficult this challenge would prove; but, considering the 
number of public-keys currently availiable and projecting several years 
into the future, the challenge may be a very significant one.

The benefits of using offsets, in general, are clear (assuming one accepts 
the additional (and essential, I believe) function of steganagraphy 
programs, outlined above).

The method I proposed for calculating the default offset from the 
checksum-value of the reciever's public-key was intended to provide a 
practical increase in security over defaulting to no offset (or a 
constant offset). For maximum security, a completely non-standard offset 
is called for.
 
> Hal Finney
> hfinney@shell.portal.com

Thanks for your input yet again, Hal.


Sergey