[extropy-chat] Re: codes in scam letters

[Eugen Leitl]

On Wed, Sep 28, 2005 at 12:12:23PM +0930, Emlyn wrote:

> > My method does not necessarily detect changed headers or corrupted
> > images.  I am talking about any added bits in the picture that would
> > normally get smoothed out by the compression method but didn't.  I.E.,

This assumes there is a compression algorithm. A digital camera
dumping RAW images doesn't compress. GIFs and TIFFS don't use lossy
compression.

This also assumes that added bits will be removed by a compression
algorithm. Steganography is very close to the problem of creating
undetectable watermarks which will survive compression. It is easy
to detect presence of watermarks by comparing multiple instances
of a watermarked image. But there are no multiple instances in
the steganography case, nor access to the original. The better
the compression, the less payload is available for steganography
and watermarking. But these are the times of GByte images and
HDTV, containing unique real-world imagery.

> > they add the message after the image is compressed.  Adding it before
> > wouldn't work because the message might get optimized out.  This is the

If your coding is bad, your message might become unreadable, yes.
So you have to use an encoding that will fool the codec. This is easy,
because the codec looks at omissible detail and redundancy in a window
of subsequent frames. With watermarks/steganography we can look at
spread-spectrum encodings with spatiotemporal features spread across
the entire frame, or the entire movie.

> > key to my method.  I can detect optimization changes between what was
> > posted and what the original graphics program and compression should

The point is that you don't have access to the original graphics
program, because it's embodied in a device. Even if you could get
that particular device, you will not be able to feed it the real-world
scenery that resulted in a specific measurement, and causing
it to reprocess an expanded jpeg will not prove presence of 
features which survived the original encoding (because the coding
was designed to survive JPEG or MPEG-4 encoding in the first place).

> > have produced.  Bits that should have been optimized out but weren't
> > obviously were added in after the optimization.  This is what I am
> > detecting with this method.

You will detect the scenario you set out to detect. You will
fail to detect the payload which was added to the raw image
and survived the encoding. 

> This assumes that a compressed image I produced by program A will be
> bitwise identical to Compress(Uncompress(I)) using the same program.
> It isn't clear to me that with lossy compression, you can safely say I
> == Compress(Uncompress(I)). DTP professionals will agree I think.
> 
> I just tried this with a commercial program. I opened a bitmap image
> and saved it as a jpeg. I closed the program, then reopened the
> program. I opened the jpeg, did nothing to it, saved it as a new file,
> with exactly the same compression settings (which had stayed as
> defaults, so in effect I touched nothing).
> 
> Then I compared the two images. The windows program "comp" told me to
> go away because they were different sizes. It turns out that they were
> 24.8KB and 24.7KB respectively (I didn't look any closer than the file
> properties dialog).
> 
> So in this case, I != Compress(Uncompress(I)).

It is becoming considerably harder with nondeterministic compression,
which depends on ephemeral system state.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07100, 11.36820            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.extropy.org/pipermail/extropy-chat/attachments/20050928/c1c05adf/attachment.bin>