[6492] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: The problem with Steganography

daemon@ATHENA.MIT.EDU (P.J. Ponder)
Wed Jan 26 10:25:40 2000

Date: Wed, 26 Jan 2000 08:23:35 -0500 (EST)
From: "P.J. Ponder" <ponder@freenet.tlh.fl.us>
Reply-To: "P.J. Ponder" <ponder@freenet.tlh.fl.us>
To: Rick Smith <rick_smith@securecomputing.com>
Cc: cryptography@c2.net
In-Reply-To: <3.0.3.32.20000125162340.00ba49a0@mailhost.sctc.com>
Message-ID: <Pine.OSF.3.96.1000126002120.25080B-100000@fn3.freenet.tlh.fl.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Tue, 25 Jan 2000, Rick Smith wrote:

<. . . .>
> 
> For example, many stego implementations involve embedding data in the low
> order bits of a graphical image. Those low order bits undoubtedly have some
> measurably non-random statistical properties. Once we replace those bits
> with data, the bits will have serously random statistical properties. So,
> we can detect stego'ed data if the implementation uses any well known
> strong encryption algorithm.

Why disturb the measurably non-random statistical properties of the low
order bits?  No one says you have to use your crypto output straight,
without 'bluing', so to speak.  What if we replace every nth lower order
bit, and make n relatively large?  Message carrying capacity is reduced,
but it becomes harder to see (guess) that a message is hidden there.

> 
> I wonder if stego users will have to choose between uncrackable encryption
> or undetectable data. 

Or extreme inefficiency?

> 
> Rick.
> smith@securecomputing.com
> 
> 
> 




home help back first fref pref prev next nref lref last post