From: Alan <alan@ctrl-alt-del.com>
Date: Thu, 21 Aug 1997 08:10:58 +0800
To: Adam Back <aba@dcs.ex.ac.uk>
Subject: Re: coercion proof timestamping services
In-Reply-To: <199708202137.WAA00738@server.test.net>
Message-ID: <Pine.LNX.3.95.970820170052.7950B-100000@www.ctrl-alt-del.com>
MIME-Version: 1.0
Content-Type: text/plain



On Wed, 20 Aug 1997, Adam Back wrote:

> Just some thoughts about creating more robust time-stamping services.
> 
> Current time stamping services just generate a PGP key, and sign any
> messages you send them.  PGP signatures already include a time stamp.
> 
> Problem: if we find some interesting uses for time-stamps where it
> becomes important that no one can coerce the timestamping service into
> back-signing timestamps in the past, the current timestampers will be
> able to comply, or as they are automated services, simply confiscating
> the machine will likely give the attacker all information required to
> back date any number of time-stamps.
> 
> One solution to this is for the time-stamper to publish all
> time-stamps (they are quite small being detached signatures), and
> publish a siganature on all the time-stamps stored in one file each
> day.  Perhaps even publish the signature in a newspaper.  Anyone with
> that newspaper, or an archive of the master signature only, will be
> able to verify any claimed time-stamps -- the publically published
> hash (in the signature) must match the time-stamps archived for that
> day.

Or post to a news group.  (Some form of transport that can be automated
and widely distributed without having to create new protocols.)

> Another way is perhaps to have a sequence of keys for signing
> time-stamps on each day, and to discard the private key after that
> day.  Authenticate the use-for-one-day-only keys by signing with a
> long term key.  If people archive daily keys, the coercion of
> timestamping service will be detected if it attempts to publish a
> daily key for some date in the past, and the timestamping service
> can't sign with old keys as it has purposely discarded the private
> halves.

Also maintaining the temporary keys on some sort of volitile storage media
that does not leave traces for later when erased.  (RAM disk or the like.)
Keep the private key on the card and erase the old key as part of the
private key generation process.

The only weakness I see here (there may be others) is keeping the long
term key secure.  (Keeping the bad guys from generating their own bogus
keys for later timestamps and the like.)

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.