Protocol workshop · Historical reference: Schneier (1996), §4.1 · Intermediate

Was it already there?

A fingerprint fixes the document. A signature identifies a key. What makes the time believable?

Make a timestamp, challenge its evidence, then try rewriting a linked history.

1 · Put a time claim on a document

Our fictional library wants to show which exhibition proposal existed before a deadline. Only its SHA-256 fingerprint goes into the signed record.

Preparing an ephemeral authority key…
Inspect the signed receipt
No timestamp yet.

The nonce links the response to this request. Changing it tests response freshness, not document integrity.

2 · Rewrite a linked history

Each record includes the previous record's hash. The final hash below is copied to a separate simulated public checkpoint before the attack.

Pinned checkpoint: Preparing…

    Preparing three records…

    What should you conclude?

    • Changing a document breaks the match to its signed fingerprint.
    • Changing a signed time breaks signature verification.
    • A dishonest authority can sign a false time with a valid key.
    • A rewritten chain can be internally consistent. A previously published checkpoint can expose the rewrite.

    Try explaining why the third result is compatible with the first two.

    Where trust enters

    RFC 3161 uses signed tokens, a trustworthy time source, policy identifiers and certificate validation. Linked timestamping binds records to earlier commitments; an external publication or witness prevents an operator from quietly replacing the whole history.

    This workshop computes real SHA-256 and P-256 ECDSA. The clock, signer and checkpoint are all local simulations. It creates no independently trusted timestamp, certificate chain, blockchain or interoperable RFC 3161 token. Existence evidence does not by itself establish authorship.

    Read the sources · then go deeper