From: cman@communities.com (Douglas Barnes)
Date: Mon, 11 Sep 95 13:15:16 PDT
To: Hal <hfinney@shell.portal.com>
Subject: Re:  Digital Fingerprinting
Message-ID: <v02120d0cac7a3111ef30@[199.2.22.120]>
MIME-Version: 1.0
Content-Type: text/plain


Hal Finney writes:
>I'm not sure how to do it for software, but for novels it should be easy
>to fingerprint.  Every couple of pages the author writes a sentence twice
>in different forms.  This would not take a great deal of extra effort on
>the part of the author.  Software can then choose from the alternative
>variations in different patterns to produce a unique fingerprint for
>every copy.
>

One of the points that I'm exploring is "what kind of transformation
makes for an un-fuzzable fingerprint bit." This example seems to fall
into the same bin as the "two cameras" approach; the two sentences come
out of the author's head in the same way that the two cameras are pointed
at the same piece of reality.

>There would seem to be two approaches to removing the fingerprint.
>One would be re-writing every sentence in the novel.  The other would be
>to collect enough copies to identify all of the sentences which have
>variations.  Most of the mathematics of fingerprinting research is
>oriented around figuring out how many different points of variation there
>must be to be secure against a certain number of copies of the
>fingerprinted item being compared.

Right. All of these approaches, however, assume unforgeable bits, either
by obscurity of insertion, or by means that are analagous to the "two
cameras" approach. I'm trying to come up with a robust definition of
"two cameras-ness", any suggestions appreciated.
>
>Perhaps a similar approach could be applied to software, where in many
>cases a couple of statements could be trivially interchanged, or other
>kinds of simple transformations could be manually generated.  Those
>could be marked by the programmers without too much extra work.
>

The problem with changes like this is that if they're trivial enough
not to require retesting, etc., then once hackers know the accepted
range of modification, they can completely fuzz them up. Various
other schemes such as reordering object modules fall into this as
well. The problem with software is that it can be reverse-compiled,
then compiled again. Unless you're willing to define a series of branches
that really do different things (and are not so trivial to be
expressed as algorithmic variants), then bits can be fuzzed. If you
_do_ write these branches, you are in for a rough time when it comes
time to do quality assurance on your software.