Trusted timestamps

There are a lot of additions being talked about for the remailers, and
timestamping is another which could be put in. With commercial PGP coming
out, people may soon be doing "real business" using PGP. In this case,
timestamps can be a problem. A simple example: you sign an electronic
contract with someone. Before signing, you set your date a month ahead.
The other person doesn't stop to notice it - many people have trouble
translating numeric dates to month names anyway - and accepts the contract.
Two weeks later, you revoke your key. He can't enforce the contract because
it was made two weeks after your key was revoked. There are plenty of
problems which can be caused by modified timestamps.

One means of protection would be to have future PGP's detect and warn of
postdated timestamps when a signed message is checked. Another would be to
use remailers to create trusted timestamps. The remailer would have a key
labeled < Remailer xx timestamp >. Timestamped messages would not
necessarily be anonymized.

There are several ways this could work. You could send a message to a
remailer and get back a detached signature certificate. Or the remailer
could sign the message and send it on its way. Ideally the remailer would
detect a PGP message, de-armor it, sign the .PGP file, re-armor it, and pass
it on. This way, PGP would automatically check all the signatures on the
received message. You could bounce a message through several remailers and
onto its destination, acquiring several timestamps along the way. Or bounce
it back to yourself to create a poor-man's copyright.

                           -- MikeIngle@delphi.com

Mike Ingle writes:

> There are a lot of additions being talked about for the remailers, and
> timestamping is another which could be put in. With commercial PGP coming
> out, people may soon be doing "real business" using PGP. In this case,
> timestamps can be a problem. A simple example: you sign an electronic

New ideas for "Mom and Pop Timestapping Services" are useful to
discuss, but be aware that several papers on exactly this kind of
digital timestamping have been presented at conferences, mostly by Stu
Haber and Scott Stornetta of Bellcore.

Their system involves a hash of some document which is then published
in an effectively unchangeable place: the pages of the "New York
Times," Sunday edition, form a pretty good "widely witnessed event,"
to use their terminology.

A digital contract timestamped (to the "granularity" of the publishing
schedule, clearly) could not easily be disavowed.

There are some other details. To reduce storage/publishing
requirements, a binary tree of other documents can all be hashed
together, so that only a single number need be published.

Anyone trying to alter a contract, or to claim the given contract was
not in fact timestamped when it was, would have to produce the same
hash value with a different input...this can be made intractable with
a good hash function.

The hash function hides the content of course, so privacy is
maintained.

Bellcore is offering a commercial service to do this. An Internet
service might be exciting (the distribution of NetNews to many
thousands of sites, for archiving on CD-ROMs, tapes, etc., is a lot
like the "widely witnessed event" of publishing in the "New York
Times").

Alternatives to Bellcore may run afoul of patents, though.

-Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | Public Key: PGP and MailSafe available.
Note: I put time and money into writing this posting. I hope you enjoy it.