Trusted Timestamps: Proving When a Hash Was Recorded

What a timestamp does and does not prove

A hash value proves that data has not changed since the hash was computed—it is a measure of integrity, not of temporal origin. A trusted timestamp adds a temporal anchor: a digitally signed assertion, made by an independent authority at the moment of timestamping, that a specific hash existed at a specific time. The two together allow an examiner or fact-finder to conclude not only that the data is unchanged, but that the data existed before the dispute arose, and has remained unchanged since.[1]

Without a timestamp, a hash computed during litigation or investigation creates a different evidentiary inference. A party with control over evidence and an interest in the outcome can compute a hash at any moment, including long after data was created or modified. An adversary can fairly argue that the hash was computed in self-interest, after the data was altered or even fabricated. The temporal problem—when was the hash actually recorded—is structural and cannot be solved by improving the hash function itself. A timestamp authority solves it by inserting an independent third party with no stake in the outcome.[2]

How a Timestamp Authority works

A Timestamp Authority (TSA) is an entity, typically recognized by government or industry, with sufficient reputation that its assertions about time can be relied upon.[1] The process is straightforward in principle but depends on careful implementation:

A user (or an automated system on their behalf) submits a hash to a TSA, along with a Time Stamping Request (TSR). The TSA records the hash, obtains the current time from a highly accurate, externally verified clock source (ordinarily synchronized via the Network Time Protocol, or NTP, to atomic clocks maintained by government standards bodies such as NIST), and digitally signs a response packet—the Time Stamping Reply (TSR)—that binds three elements together: the hash, the time value, and the TSA's digital signature.[1] The signature is computed using the TSA's private key, which only the TSA possesses. Anyone with access to the TSA's public key can later verify that the TSA issued this signature and that none of the three bound elements have changed.[1]

The standard protocol for this exchange is defined in RFC 3161, the Internet X.509 Public Key Infrastructure Time-Stamp Protocol.[1] TSAs must maintain synchronization to an external time source with high accuracy.[2] The NIST SP 800-102 guidance addresses how trusted timestamps integrate into broader digital signature verification schemes.[2]

The critical feature is non-repudiation: once the TSA has issued a timestamp, it cannot later deny having done so (the signature proves it was issued with the TSA's private key), and the hash cannot have changed without the signature becoming invalid (changing even one bit of the hash or timestamp invalidates the digital signature).[1]

Why a computer's own clock is the weak link

Digital evidence differs fundamentally from physical evidence: it can be copied perfectly, instantaneously, and without degradation, and copies can be altered without leaving physical traces.[2] Unlike biological evidence, which decays over time in measurable ways, digital evidence has no intrinsic temporal characteristics. A computer file looks identical whether it was created today or ten years ago, and whether its contents were modified seconds ago or have remained constant since creation.

A computer's internal clock, if used to timestamp a hash without external verification, creates evidentiary problems that no encryption can solve:

No third-party attestation. If a custodian simply records that their computer says a hash was created at 14:32:17 UTC on a given date, a challenger can argue the clock was manually adjusted, the system's internal clock was never accurate, or the timestamp was written retroactively. There is no independent voice confirming the clock was correct at that moment.[2]

Lack of synchronization discipline. A standalone computer clock can drift by minutes or hours without alerting the user. Without synchronization to an external standard, there is no way to verify the clock's accuracy on the date in question. The computer might have been days behind or ahead of true time.[1]

Incentive misalignment. The party possessing and controlling the evidence has an incentive—financial, professional, or personal—to backdate or forward-date timestamps depending on the narrative they wish to construct. A TSA, by contrast, is a neutral institution with no interest in the outcome of any particular case. Its reputation, and thus its entire business model, depends on the credibility of its timestamps. A signature issued by a TSA carries evidentiary weight precisely because it represents an independent attestation.[1][2]

How timestamps are challenged in litigation or investigation

The tamper-evidence property of a timestamp—that any alteration of the hash or timestamp renders the signature invalid—is also the mechanism by which timestamps are scrutinized. A challenger typically pursues one or more of these lines:

Attack the TSA's credibility or independence. An adversary may argue that the TSA was not truly independent, was subject to pressure or compromise, or has a history of issuing unreliable timestamps. This approach requires evidence about the TSA's governance, independence, or prior errors.

Attack the protocol chain. An examiner or attorney may demand to see the original Time Stamping Request submitted to the TSA, and verify that the hash in that request matches the hash of the data now being offered as evidence. If the TSR contains a different hash, the timestamp does not apply to the current evidence. If the original TSR cannot be produced, questions arise about whether the timestamp was ever genuinely applied to the data in question.

Attack the clock source. If the TSA's synchronization procedure is known (for example, that it synchronizes via NTP to a specific reference server), evidence may be introduced showing that the reference server was itself inaccurate on the date in question, or that the NTP synchronization procedure itself contained errors. This is a technical challenge and requires expert testimony.

Introduce timing evidence inconsistent with the timestamp. If metadata, network logs, file-system records, or other independent evidence shows that the file was modified after the timestamp, or that the user could not have been in a position to submit the hash at the time claimed, the timestamp's reliability is undermined. For example, if a file's modification time (recorded in the file-system metadata) is later than the timestamp, the data must have changed after the timestamp was issued, and the signature would detect this change if both the original and the modified files were checked against the timestamp.[1]

Verification in practice

When a timestamp is presented as evidence, the verification process requires:

1. Obtaining the original timestamped data and the Time Stamping Reply packet issued by the TSA.

1. Computing a hash of the current data using the same algorithm the TSA applied.

1. Comparing the computed hash to the hash stored in the TSR. If they match, the data has not been altered since the timestamp was issued.

1. Verifying the TSA's digital signature on the TSR using the TSA's public key. If the signature is valid, the TSA genuinely issued this timestamp.

1. Extracting the time value from the TSR and confirming it is consistent with other evidence (metadata, logs, testimony) about when the data was created or recorded.

If any step fails—the hash does not match, the signature is invalid, or the timestamp is inconsistent with other evidence—the integrity or timing of the data is called into question. A timestamp that survives verification does not prove the data is accurate or truthful; it proves only that the data in question existed at the specified time and has not been altered since.[1][2]

Standards and long-term archival

For evidence that must be preserved over many years, specifications for evidence records are designed to maintain the provability of data existence and integrity over extended periods, even as cryptographic algorithms age or become obsolete. Standards establish minimum security requirements for timestamp management in regulated environments.[2]