Security through Obscurity

Hal hfinney at
Sat Mar 5 08:02:06 PST 1994

From: Sergey Goldgaber <sergey at>
> Well, if we adopt the method of comparing the cost of implementing a 
> given steganography method to the cost of breaking it as a valid measure of 
> its effectiveness; then, it would make sense to "maximize" the cost of 
> breaking it as a means of making the method more effective (ie. making 
> the method more obscure would make it more effective).

I don't think this is a valid measure of steganography's effectiveness.
I proposed my own measure, which I think is valid.  I think the fundamental
problem with your measure is that it counts a system which is easy to break
but very easy to implement as effective.  I would count such a system as

> > Instead, if you are going to adopt this goal, this means that the test of
> > your steganography is whether the opponent can extract the message.  It's
> > not that your goal is to "maximize his difficulty".  It's that your goal is
> > to stop him.  Again, NoStO emphasizes clear statements of your goals and
> > costs.
> The more difficult it is for one's opponent to extract the message, the 
> more effective the method is.  Thus, "maximizing his difficulty" is a 
> valid goal.  As I see it, this is a goal of most encryption systems.  To 
> make decryption as difficult as possible, if not impossible (ie. maximum 
> difficulty).

I don't think this is right either.  The problem is that "as difficult as
possible" does not allow for a measure of success.  Something which is
"as difficult as possible" may nevertheless be useless.  This whole notion
of maximizing difficulty as a goal is completely misguided.  The correct
goal is to achieve secrecy.  If you have not done that, then maximizing
difficulty is pointless.

Your goal in making a parachute is to create something that will land you
safely.  It isn't to "maximize slowness of fall".  Suppose I made a parachute
out of lead, designing it to maximize slowness among lead parachutes.  Will
you jump out of an airplane with it?  I'd think not.  The problem is that
this is the wrong goal.

> I do not think you have understood _my_ essay.  My proposal was for a 
> default, variable offset in certain steganography applications.  The 
> benefit of this is obvious:  having no offset or a non-variable offset 
> would make for generally poorer security; as, the effort required in 
> figuring out where one's file is located is nonexistant.  Effort 
> increases when a variable offset is implemented.

OK, let me ask this: what is the harm done if the opponent guesses the
right offset?  How bad are things?  Some of your security has been lost.
How much?

Suppose your stego method is not completely invisible and does give away
its existence to some extent.  Would you still use it if protected by your
offsets, or would you refrain until you had an undetectable stego?  How
much would you trade off the protection provided by your offsets against
the protection provided by undetectable stego?

Suppose I am a naive user of your program asking these questions.  When
I receive a stego'd file and put it on my disk, should I re-format it
to change the offset?  How much security does this gain me?  Is it worth

Should I have more than one public key, so that the opponent would have more
offsets to guess?  How much does this help?

How much should I worry if I think I may be targetted for surveillance,
which would increase the chance of them trying my keys as the offsets?
Should I avoid controversial issues, keep a low profile, so that I can
prevent this from happening?  How much should I trade off against the benefit
of making my offset less likely to be tried?

I think if you are seriously proposing that your offset scheme adds security,
you need to be able to answer questions like these.  If it really adds
security, you must be willing to pay a cost to achieve that security (recall
the NoStO principle: count your costs when you count your benefits!).
If you can answer questions like these then you are not violating StO, in
my opinion.


More information about the cypherpunks-legacy mailing list