Re: Signing pictures -- how hard, how long?

I think signing photographs and movie images is a difficult
problem. Why? Because one flipped bit will completely screw
up the hash function. Errors on these tapes happen rarely,
but most video manufacturers aren't really going to bother
worrying about occasional bit errors because they're usually
invisible to the eye. Why waste all that extra effort on
error correction if it's not worth the trouble. So signed
photographs will also need to contain all of the error 
correction necessary and that will make them more expensive.
This isn't any real cost on a general purpose machine, but
it matters in some places.

I doubt if it's that simple:  I'm sure that digital movies will
use compression (mpeg, etc.).  One flipped bit could scramble the
whole frame.  Even with lossless compression, error correction would
be worth adding.

It's going to be much easier to compress to mpeg in hardware than to
design tape that can handle the required frame rate/resolution without
compression.

> 
> 
> I think signing photographs and movie images is a difficult
> problem. Why? Because one flipped bit will completely screw
> up the hash function. Errors on these tapes happen rarely,
> but most video manufacturers aren't really going to bother
> worrying about occasional bit errors because they're usually
> invisible to the eye. Why waste all that extra effort on
> error correction if it's not worth the trouble. So signed
> photographs will also need to contain all of the error 
> correction necessary and that will make them more expensive.
> This isn't any real cost on a general purpose machine, but
> it matters in some places.
> 

sdw
-- 
Stephen D. Williams  Local Internet Gateway Co.; SDW Systems 513 496-5223APager
LIG dev./sales       Internet: sdw@lig.net CIS 76244.210@compuserve.com
OO R&D Source Dist.  By Horse: 2464 Rosina Dr., Miamisburg, OH 45342-6430
GNU Support          ICBM: 39 34N 85 15W I love it when a plan comes together

Peter Wayner:
> I think signing photographs and movie images is a difficult
> problem. Why? Because one flipped bit will completely screw
> up the hash function.

Is a one-way hash function or digital signature possible with the
following property: signature verification doesn't just determine
the boolean altered vs. pristine, but also shows the picture
distance between the altered and original?  Forgery may often
require an editing distance much greater than the error rate
from media noise or lossy compression.

Nick Szabo				szabo@netcom.com

I think that compression is a non-problem.  It's an example of a change
which can be signed.  Here's what I imagine:

<SCENE> -> DigiCamera -> DigiEditor -> Compress -> Xmit -> Uncompress ->View

At each step of the way, it should be possible to sign the image.  I
disagree with the thought that we don't need signature in the camera.
Remember that a signature is not intended to *prevent* forgery as much as to
provide a trail of responsibility.  Thus a picture taken with my digicamera
should contain a signature generated from the camera's key and mine.  I'm
the artist responsible for initially capturing the scene and I'm responsible
for the claimed accuracy of the resulting picture.  Similarly I want to sign
every frame because I can't predict which frame(s) are going to be edited
out and which frame is going to be turned into a still picture that appears
on the front page of everyone's newspaper.

[The comment about GPS info in the camera is not far off.  Cameras that know
where they are will be about 1 generation behind the first digital cameras.]

If someone takes the "film" I've shot and edits it, I expect that edited
version to be re-signed by the person who does the edit (possibly generating
a new original signature or a signature based on my initial signature).
Just as today negatives are kept archived for years, the editor will keep a
disk archive of my original -- again, we preserve the chain of
responsibility.

Lossy compression takes two basic forms.  One is block-truncation-like,
where the whole picture is sent at each frame, but some (presumably
perceptually insignificant) bits are omitted.  The other is MPEG-like where
only certain key frames are sent as whole pictures; the intermediate frames
are sent as deltas to the most recent whole frame.  In either case, a coded
picture is, for signature purposes, like an uncoded picture.  It can be
signed, with a signature generated from the equipment and the operator keys.
For MPEG-like compression you might sign the deltas or you might sign the
resulting picture (previous image with new delta applied).

The problem with bit-rot is a more significant one.  In this case you might
want to compute your hash not over every bit of the image, but over the
"significant" ones.  That way if you lose low-order bits that no one cares
about your signature is still valid.