Skip to content

Latest commit

 

History

History
188 lines (146 loc) · 8.56 KB

Timestamping.md

File metadata and controls

188 lines (146 loc) · 8.56 KB

Timestamping: Why and how

Being able to provide evidence that you had some piece of information at a given time is important in many aspects of personal and corporate life. It can be used to

  • show that you had some idea already at a given time,
  • that you already had a piece of code, or
  • that you had a document at a given time.

Timestamping does not assure authorship of the idea, code, or document. It only provides evidence to the existence at a given point in time. Depending on the context, authorship might be implied, at least weakly.

Isn't that what Blockchain is for?

Timestamping was used way before Blockchain was even conceived of:

are ways of providing public and/or agreed-upon evidence that something has happened or was known at or before a particular time.

Assuming that there is little interest in wide-spread foul-play or given enough independent verifiers, timestamps can be provided much more easily (and more energy-efficient) than with Blockchain.

Why not Blockchain Timestamping?

Existing Blockchain timestamping systems such as OriginStamp do not give an immediate feedback or proof to the requestor. Instead,

  • they first accumulate several requests (the default is for 24 hours)
  • and only then submit them to the Blockchain,
  • where it may further take an hour or more before before it is immutably accepted to the Bitcoin Blockchain, and
  • then you as the requestor still do not have anything and will need to look through several different data structures to obtain a real proof (see OriginStamp FAQ item "What if your service doesn't exist in 20 years?"; sorry, but direct linking to that entry does not work. You have to scroll down and open the FAQ item yourself).

On the other hand, zeitgitter timestamping

  • returns an immediate timestamped signature as a proof, and
  • only requires the other operations to show that the timestamper itself is not misbehaving.

As a further benefit, a network of independent timestampers

  • is much more energy efficient: An zeitgitter timestamper on a tiny computer such as a Raspberry Pi may consume less than one Watt, while the Blockchain used a huge amount of power, more power as the whole country of Switzerland. (BTW: One small data center in Switzerland processes a copy of all global interbank transactions at only a tiny fraction of all the Swiss power consumption and therefore the Blockchain power consumption.)
  • is much more resilient: In a network of timestampers timestamping each other, it is enough to have just a single trustworthy timestamper. This already limits the window of wrongdoing for any cheating timestamper to around a day (i.e., no timestamper may backdate timestamps by more than this timespan). On the other hand, controlling 51% of computing power of a Blockchain allows complete control over the entire blockchain (and already at 33%, some cheating may occur).

The PGP Timestamper

An example is the already-mentiond PGP Timestamping service, which provides users with the ability to timestamp a document or a hash thereof, by having an independent party create a OpenPGP-signed and dated message, each of them with a unique and consecutive serial number.

To ensure trustworthyness and provide full transparency, daily digests of the hashes and signatures are then also (a) archived and (b) immediately posted to anyone wishing to be able to withness and reproduce the stamping process.

A disadvantage of the PGP Timestamper is its archaic interface and the log delays (several minutes). Also, the signatures are hard to verify by non-experts.

zeitgitter goals

zeitgitter is inspired by the PGP Timestamper, but trying to as simple to use as possible in a git context.

The goal of zeitgitter is to provide as many independent timestamping services as possible, so a user (or organization) can freely select a subset fulfulling their needs.

To establish trust in the service, the source code is made available under an open source license.

zeitgitter operation

zeitgitter listens on an HTTPS port and awaits POST requests for signing a tag or a branch commit. It then returns the appropriate information, ready for the client to integrate it into its git repository, from where it then can be

  • verified using git tag -v <tagname> or git verify-commit <commit>, and/or
  • published to other repositories.

At the same time, the timestamping server maintains a log of all commit hashes signed, in a git repository itself.

As a result,

  1. the requester of a timestamp will get immediate confirmation (a timestamping signature on a tag or branch).
  2. Later, the timestamper then either cross-timestamps its repository and/or publishes it.
  3. This allows third parties to inspect the timestamping server's operation and therefore strictly limits the timestamping server's ability to backdate anything beyond the cross-timestamping/publication interval.

This allows a compact, energy-efficient basis for many notarization services.

Name

The name zeitgitter tries to keep in line with the slang naming philosophy behind git).

Usage

This software is free software; so you may use it in any way you see fit, in accordance to the AGPL v3.0 license.

Timestamping has a need to be as transparent as possible. Therefore, you may want to make information about your timestamping service, including the running code and its settings, available publicly anyway. AGPL was chosen to reflect this spirit. Please contact me if you require other licensing terms.

It is desirable that as many people and organisations as possible do provide timestamping services. So a user may choose a subset of them which are mutually independent and generally trustworthy.

Installation and typical usage of the timestamping client is documented in doc/Install.md.

Naming

The zeitgitter name can refer to

  • the underlying protocol ("zeitgitter protocol"),
  • this software or other servers implementing the protocol ("zeitgitter server"), or
  • the entire network of servers ("zeitgitter network", "zeitgitter system").

It should not refer to an individual service, especially not a public service. When chosing a name for your service, please try to come up with a unique service name. The full service name has to be unique, obviously. But also, the first part of the name (before the first dot in the domain name) should be unique. A list of currently know public servers is maintained as ServerList.md here.

Client plausibility tests

The client should perform the following tests on objects returned from this service:

  • For tag-based verifications
    • Object ID, tag type, tag name, tagger name and email matches the information submitted
    • Timestamp is between the time the request started and the time the request finished, with a fuzz of f seconds (recommended: 30 s)
    • The tag message is at most 1000 ASCII chars long (printable + carriage return + newline)
    • The PGP signature is at most 2000 ASCII chars long (base64 + space + equal sign + carriage return + newline)
    • The PGP signature verifies OK