1994-12-23 - Re: Making sure a program gets to the receiver intact

Header Data

From: eric@remailer.net (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 3c52577568a2261981b37147c9b1c8a51546615fdf7ed4aa7ecfb8b39d4d26b9
Message ID: <199412231736.JAA20003@largo.remailer.net>
Reply To: <9412220711.AA21268@anon.penet.fi>
UTC Datetime: 1994-12-23 16:39:03 UTC
Raw Date: Fri, 23 Dec 94 08:39:03 PST

Raw message

From: eric@remailer.net (Eric Hughes)
Date: Fri, 23 Dec 94 08:39:03 PST
To: cypherpunks@toad.com
Subject: Re: Making sure a program gets to the receiver intact
In-Reply-To: <9412220711.AA21268@anon.penet.fi>
Message-ID: <199412231736.JAA20003@largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain


   From: an169306@anon.penet.fi

   How can I insure a program, once put on FTP sites stays untampered with?

The best solution is not digital signatures but rather digital
timestamping.  The question is not persistence of authorship but
rather persistence through time.  

Digital timestamping is not keyed.  The Haber-Stornetta algorithm uses
only one way functions.  The certificate the timestamping algorithm
spits out gives a way of verifying that the modification state
(yes/no) is the same as that of the timestamping root, shared by many
participants.  The assumption is that spoofing the root of the
timestamp system is hard, exactly because it is shared widely.

The initial system published the root in the NYT announcements
section.  Since then, Haber and Stornetta have started Surety
Technology, which is commercializing the patent.  Their new system
doesn't have a single point of failure at the root, it appears, but I
don't know details.

The problem of detecting modification is not the same problem as
assuring that version one was written by the same author as version
two.  The asker of the original question said nothing of versioning.
The question applies to first versions as well, where persistence of
identity is not at issue.

Digital signatures will work to affix a pattern of bits, but as with
digital signatures, if the key is modified, so might be the signature.
Yet digital signatures require private keys, which do persist through
time, and so there is an issue of forward security.  The private key,
if compromised, might be used to sign a statement that the signature
on the binary was a forgery!  With digital timestamping, no keying
information exists to be compromised, so the affixation of bit pattern
is permanent.

   The holes:

   1:  Someone hacking the keyservers, substituting a key for all the people
       who signed, and modifing the archive to show that.
   2:  Someone breaking into my apt, sticking a keyboard monitor on, getting
       my passphrase and key.

This is all a problem of economics.  What is it worth to compromise
the binary?  How much does it cost to perform the compromises?

In fact the real problem is deeper.  The binary, public key, and
signatures can simply be entirely replicated.  Now a person trying to
distinguish between one binary/key/sig triple from the other must rely
upon some social process to distinguish, which is not much different
than the original problem of distinguishing two binaries claiming to
be the same thing.

This is where digital timestamping shines.  The timestamp algorithm
yields time ordering of the various binaries.  Now the discrimination
problem between binaries can be resolved by choosing the _earlier_
one.  We assume that the spoofer has only access to the public version
in order to create an alteration.  Note that this solution doesn't
protect against an insider publishing a modified version before the
actual release.

This is not to say that binaries shouldn't be signed.  A common trojan
horse attack on binaries is to release "bug-fix" versions.  It is in
this situation that the persistence of identity of authorship is
important.

Eric





Thread