I was thinking about the way git allows to edit the timestamp on commits, and how you can rewrite (public) history that way.

I then drifted from that to "can we prove someone did an action at time X a posteriori? " to prevent these rewrites.

And surprisingly, my brain found little or no ways to prove an action was taken on time, with no way of doctoring that afterwards.

I assume that we can't just ask a trusted server's log on date/time involved for connection as proof, and have to rely on a crypto-thingy to prove "we were there",

I thought about a trusted server sending a hash/key dependent on time when it was contacted, so that you would have to query the server and "be there on time" to get the code. But this is silly, as anyone could record these hashes by hitting the server often enough.

Any computation based on the exact date time would also be broken of course, which leaves me at a loss.

My actual questions now :

  • Is such a problem actually important for some ? Important enough for someone else to solve it / take a stab ?
  • What did I miss ? Any insight ?
  • 1
    This is a very important problem for legal matters. Like who was the first to file a patent, if someone shredded a document before or after receiving a court order to turn it over or if an objection was made within a objection period. Unfortunately you can only prove that something was done after a specific point in time (by proving the knowledge of some information which didn't exist before) but not that something was done earlier (because you can not prove the non-possession of information)
    – Philipp
    Sep 27, 2015 at 23:29
  • Try looking into bitcoin block chain. Seems like your case scenario.
    – Agent_L
    Sep 28, 2015 at 12:41

5 Answers 5


Trusted timestamps

You can use a trusted timestamp service. There are companies (such as GlobalSign) that will provide that service for a fee.

But this is silly, as anyone could record these hashes by hitting the server often enough.

Yes. But only if you have a small search space. But in the case of SHA256 there you would have to devote 10^77 rows in your database to storing the results. And that is WITHOUT any data in those rows. That number is close to the estimated atom count in the universe of 10^80. And that is too high.

And that makes you safe: the sheer, overwhelming amount.

Nobody will have enough time to submit all the hashes. (And also: nobody will have that much money to pay the processing fees.) Nobody will have enough hard drives to store all the results.

Further reading

Wiki has an nice explanation of the general idea.

  • Wikipedia: Trusted timestamping, Section Creating a timestamp: (line breaks mine)

    The technique is based on digital signatures and hash functions.

    First a hash is calculated from the data. A hash is a sort of digital fingerprint of the original data: a string of bits that is practically impossible to duplicate with any other set of data. If the original data is changed then this will result in a completely different hash.

    This hash is sent to the TSA.

    The TSA concatenates a timestamp to the hash and calculates the hash of this concatenation.

    This hash is in turn digitally signed with the private key of the TSA.

    This signed hash + the timestamp is sent back to the requester of the timestamp who stores these with the original data (see diagram).

  • Good to know, thanks ! What about this : given a time boundary (a few days at max), couldn't I get the hashes by bruteforcing as mentioned before ? Do these companies enforce any measure to prevent spoofing ?
    – Jiby
    Sep 28, 2015 at 7:32
  • Yes. You would not be able to pay that with all the money in the world. All the money in the world is about 4*10^12 USD. SHA256 can take 2^256 possible values (about 10^77 in powers of ten.) And to brute force that, you'd need to try about half of them. You (and nobody else) don't have that kind of money. Sep 28, 2015 at 8:37
  • True enough. I meant querying the server on these time boundaries and storing the issued hash. Subsequently I would use one of these stored hashes as needed to "pick a time" for an event taking place. The exhaustive query-storage given a time frame was what I meant by bruteforcing. Sorry for confusion
    – Jiby
    Sep 28, 2015 at 9:15
  • You don't get just a singular signed timestamp. You submit context to that timestamping service (like the Git commit ID) for example. Then the timestamping service ADDS a timestamp to that ID you provided, then computes a HASH OVER THE PACKAGE of those two. Then SIGNS THAT HASH. Then returns that signed hash. In other words: You provide the WHAT, the timestamping service provides the WHEN (Or a IT-EXISTED-AT-THIS-TIME.) statement. Sep 28, 2015 at 9:26
  • Nice ! Makes more sense now. Can you update your answer to add this idea of what the customer bring to the timestamp so I can accept it ?
    – Jiby
    Sep 28, 2015 at 9:31

You can put the hash of your commit into Bitcoin blockchain, and after some blocks added upon the block having your hash, you will be able to convince people that you had had that commit prior the time the block has been added into the blockchain.


Another way to document something with a timestamp is by way of a DKIM signature on an email. Many email providers nowadays (e.g. Gmail, Yahoo Mail, etc) DKIM-sign each message that is sent through their service. Although the primary purpose of a DKIM signature is to vouch that a message is legitimate and not spam, a DKIM signature also renders the signer as a notary of sorts. To document something with a timestamp, you can send a message to someone else - or even yourself - through an email service that will DKIM sign the message. Then, by verifying the DKIM signature (which appears in the headers of the message on the receiving end) the recipient (either yourself or someone else) can prove that you sent the content of that message at the date and time that appears in the message headers.


Yes it has a lot of applicability to digital evidence (particularly log files).

In order to prove a fact after a specific point in time, then one simply needs to combine the fact with some information which emerged at that point in time - consider the picture of a kidnap victim holding up a newspaper. In a digital sense one could do this by signing the data with a newly released key, or, more generally,hashing it with a known, changing, searchable data feed.

But this method does not work for proving that data existed before a specific time. The only solution I've thought of in that scenario is to log (at least a digest of) the data with a trusted party. And if this entity can sink data it should also be able to produce a verifiable timestamped data stream allowing for well defined windows to be be provably linked to data.

I think there is a potential business opportunity there, but a lot of thought and organisation needs to be put into establishing trust.


Even though not specifically related to your use-case, but there are some distributed databases that use time to resolve conflicts (search google for spanner database). These solutions use multiple physical timesource attached to network to ensure that the accurate time is available to each server.

Another option could be the use of blockchain to ensure that the transaction you are trying to perform is attached with specific time and signed for later verification.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .