Musings about Coding, Business and other Geek Stuff Live and Direct from somewhere on the planet
April 17, 2006
Launching TimeCert

I am now officially launching TimeCert which is a trusted third party service for proving the existence of a file, object or document at a certain time.

Applications

Lets say your application managed confidential documents or emails. You could use TimeCert for maintaining a proof that a document or email existed at a certain time. As this timestamp is generated outside your own server, it is evidence that you did not manipulate say a contract after the timestamp. It would also be pretty easy for someone to add timestamping to their blog software.

You could also use it to timestamp a sourcefile to help out with Intellectual Property issues.

The Details

Basically TimeCert receives queries based on a SHA1 digest of an object. The first time it receives a query it creates a small record in a database with a timestamp.

If you are not familiar with SHA1 digests, it takes any binary object and creates a tiny 20 byte “fingerprint” (all though TimeCert uses the 40 byte hex encoded variety), which uniquely identifies it. This is relatively secure cryptographically speaking even though it is not as secure now as it was before. However for most applications it should be secure enough.

TimeCert is not really intended as a end user application, but more as a third party service for existing applications to hook into.

Try it

Have a go at it your self. Go to the TimeCert Interactive Digest Generator to create and timestamp your own test data. This is really for testing purposes only, but I do not store the raw data you post.

This generator could potentially be very CPU intensive under high loads, so I might disable it if it’s abused.

REST API

It uses a standard REST style API where you create a HTTP GET to:

  • http://timecert/DIGEST for end user link
  • http://timecert/DIGEST.txt for a plain text file with ini style parameters
  • http://timecert/DIGEST.xml for xml
  • http://timecert/DIGEST.yml for yaml

Where DIGEST is a 40 byte hex encoded SHA1 digest that your own application generates. The reason why your own application should generate this is that this way you can actually maintain the object itself private from me. The only thing you make public is the digest.

Client libraries

I have a Ruby class which will call the service and will publish a Java one ASAP. As soon as my RubyForge project is up I will post them. If you want to write a client in any other language, just let me know.

Server details

The server is written in Ruby and uses the new Camping micro web framework and the Mongrel. The actual server OS is OpenBSD.

I will be releasing the extraordinarily simple application under GPL as well under the hope that other people will run similar services. As I think it best if there is at least a few other trusted third parties around.

What’s in it for me?

This is an App I have wanted to do for a long time. My original plan for it was to use digital signatures, but I do not think there is any real need for this any more.

The service will always be free to use. I need something like this for my own applications, which is the real reason why I’ve created it. The nature of the application does not call for accounts free or commercial, so I can’t ever see that will happen.

Posted by pelleb at April 17, 2006 11:57 AM
This entry was posted in the following Categories: Crypto & Security , Open Source , Ruby
Comments

How can somebody verify that your timestamps are accurate? The service at http://www.itconsult.co.uk/stamper.htm posts PGP digests of all messages it timestamps to a newsgroup, so that there is external evidence that the timestamping happened around the time indicated on the timestamp.

In other words, how does your system prevent you (the implementor) from giving people arbitrary timestamps? For example, let's say you are my buddy and I call you up and say "gee, I really need you to timestamp my term paper with yesterday's date because it was due this morning and I didn't turn it in." How does your system prevent this type of "time forgery"?

Posted by: Brian on April 17, 2006 03:51 PM

You raise some very valid points and they are hard to answer with that magic answer us geeks want. The short version is that you need to trust me. You need to trust me for any kind of service like this. The IT consult version sounds pretty nice, but I think for 80% of the cases it may be overkill.

My fix for this is that I will be releasing the source code ASAP so other competing services can pop up. Then we need to work out some kind of plumbing between us. As long as the competing services are not all owned by me, you get a pretty trustworthy system.

You could then timestamp on say 3 different services and the user can decide if they pick the earliest, the average or the last date.

I come from the crypto world myself and crypto/sigs are only part of the solution. As a matter of fact the whole gospel of digital signatures that I have believed in for years is slowly being yanked into the real world:

http://www.financialcryptography.com/mt/archives/000697.html

You might be interested in this article I wrote a while back about identifying your self the provider as one of the main security breach points.

http://neubia.com/archives/000409.html

Posted by: Pelle Braendgaard on April 17, 2006 04:06 PM
Post a comment
Name:


Email Address:


URL:


Comments:


Remember info?