It's time for timestamping

Sep 7th, 2023
by makeworld

Recently I’ve been thinking a lot about trusted timestamping. Normally timestamping is very easy: simply adding a timestamp field to your metadata and calling time.Now() or similar. But trusted timestamping is concerned with proving that the provided timestamp is actually correct, and wasn’t forged after the fact.

This is simple for one direction: proving some data existed after a certain point in time. That can be easily achieved by including unguessable current information, such as news headlines and stock prices. A classic pop culture example is kidnappers proving a hostage is still alive by having them pose with the day’s newspaper.

But trusted timestamping is concerned with the opposite direction: proving data existed before a certain time. This is not so easily done, but it is possible, and the use cases are quite important in my opinion.

Purpose

I see three main reasons for doing trusted timestamping.

1. Verifying old cryptographic signatures
2. Data integrity
3. Proof of technology ✨

In addition to these there is the obvious one: authenticity. Trusted timestamping can prove that a document that claims to have been made on a certain date actually was.

Verifying signatures

This is the mainstream industry use case, as far as I can tell. For example Apple requires timestamping as part of its code-signing process. The reasoning is simple: sometimes private keys get leaked or revoked. After that happens, how can we validate any previous signatures? They might have been made by a third party using the leaked key. But if the signature was timestamped, we can know that the signature was created before the key was made invalid. This is a real problem that trusted timestamping solves.

Data integrity

A basic method of ensuring data integrity is storing hashes. But what if those hashes are tampered with? Using signatures instead allows us to verify that no one but a person/org we trust has modified the data. But what if we don’t want to trust that person, or their ability to guard their keys? Using signatures adds an extra moving part and security risk that in some cases may not even be needed. If we can agree that the data was valid and unmodified at a certain point in time, trusted timestamping will provide data integrity forever. An example use case is backups, or storing org-internal archival data like legal agreements.

Proof of technology

This is my personal, special, modern use case. As AI-generated content gets better and better, being able to prove that a piece of media was generated before certain AI software even existed will become extremely important. Trusted timestamping has the ability to end all these new uncomfortable arguments that such-and-such picture was created whole-cloth by some incrutable algorithm, and instead bring us back into old school discussions about whether it looks “PhotoShopped”.

Of course, it can be argued we are too far gone at this point, AI image generation is too good. But AI video remains unsolved for now, and the images are not truly perfect yet. As the saying goes, the best time to plant a tree timestamp data was 20 years ago, the second best time is now.

Software

There currently exist two viable trusted timestamping methods I am aware of. There is OpenTimestamps, and there is the Time-Stamp Protocol, or RFC 3161. The former timestamps using Bitcoin (but efficiently, not one timestamp per block) and the latter uses the signature of a trusted service (Time Stamp Authority).

Here is a quick comparison:

You can learn more about OpenTimestamps on the website. Beyond the actual RFC linked above, you can learn more about RFC 3161 by playing around with OpenSSL, see man openssl-ts.

I’m not going to dive any deeper into these tools than the above table, but my general recommendation is to use RFC 3161 with a good third-party unless not needing to trust anyone is actually a requirement for your project. And you could always do both!

Usage

OpenTimestamps has a CLI tool and libraries in several programming languages, see here. It also has a GUI on the website.

RFC 3161 is supported by OpenSSL as a CLI tool with the openssl ts command. To make RFC 3161 timestamping on the CLI easier (as it’s not just one OpenSSL command), I’ve created a Bash script each for timestamping and verifying. You can get them here.

The only GUI option for RFC 3161 I’m aware of is on the freeTSA.org website, although personally I have no reason to trust freeTSA. Better than nothing though, for anyone who doesn’t use the commandline.

For trusted third-parties there are various options, including reputable companies such as DigiCert.

Conclusion

It’s time for trusted timestamping! The cost of this is basically zero (storing a few kilobytes of proof at most), but the advantage can be very large. It’s one of those things that you’ll wish you had done at the start.

Many groups can act on this (in increasing order of importance):

• General public: timestamp your important documents and media to prove their authenticity. You can do this today on your phone with ProofMode, and on the desktop using CLI or GUI tools as discussed above.
• Archivists: timestamp everything you archive, for integrity and authenticity. For redundancy consider using both methods mentioned above and many RFC 3161 timestamp authorities.
• Developers: if you work on software where data or signature integrity is at all important, add trusted timestamping to your application. And if you use Git signing, you can easily start timestamping all those signatures, see here.

If you create software or projects related to trusted timestamping, feel free to let me know about them!