Hacker News Reader

Comment by michaelt | Hacker News Reader

Sometimes it's useful to be able to prove a file was created /before/ a given time.

For example, if you download a signed executable, but the signing certificate expired a while ago, does that mean you don't trust the executable? If you don't trust it, every executable would eventually break when the signing certificate went out of date. The solution is to require a cryptographic timestamp proving the executable was generated at a time when the code signing certificate was valid.

That's how you can download Java applets that were published and signed in 2005 and still know the signature is valid. Not that many people are using that technology these days!

View on HN

> Sometimes it's useful to be able to prove a file was created /before/ a given time.

Let me give a personal example: some time ago, someone deleted the public copies of some webpages we were using in our investigation and threatened to us that if we continued, they would simply claim that our copies of were forged later (after we had contacted them), and, they thought, make us look like fools & scuttle our claims (with some hints that they might also sue us for libel to boot). Fortunately, I had been timestamping all along and had timestamped the archived webpages in question; so I could prove that my copies are unaltered from well before they raised the question, and, further, at around the same time as they were independently captured in a different archive service. After we noted this to them, they had to back down on the threats and take us more seriously.

> If you download a signed executable, but the signing certificate expired a while ago, does that mean you don't trust the executable?

Indeed, no you don't---not on the basis of cryptographic reasoning, at least.

Certificates expire for a reason. That reason is the assumption that they are being actively cracked, and so have a limited shelf life. You can trust a 2005 certificate only to the extent that you bank on the underlying private key not to have been cracked.

If the key is cracked, then the attackers can create a brand new file, and make it look like its existence had been certified in 2005.

Old stuff that still matters has to be re-certified with new certificates in the face the impending expiry of the old ones.

> If the key is cracked, then the attackers can create a brand new file, and make it look like its existence had been certified in 2005.

What? If someone cryptographically timestamped a particular signed file in 2005, even if Eve cracks the original public key and can now produce arbitrary new signed files with that key, they still do not have 2005 timestamps for any of those new files! They could only make 2015 timestamps. That's the whole point of cryptographic timestamps.

That just means that the timestamps have their own certification mechanism which is independent of the certificate on the file. That certification mechanism also has expiring keys. The attacker uses the cracked 2005 stamping key to stamp the file and the cracked certificate to sign it.

(If you could certify a timestamp forever, in a non-expiring, uncrackable way, why wouldn't you just use that for the whole file?)

> The attacker uses the cracked 2005 stamping key to stamp the file and the cracked certificate to sign it.

OK, so you don't actually understand how cryptographic timestamping works or the Bitcoin version. Please read up on it before commenting.

> If you could certify a timestamp forever, in a non-expiring, uncrackable way, why wouldn't you just use that for the whole file?

What you are timestamping is the whole file!

Sorry, I mean something like "for the whole aspect of certifying the file, not just its time stamp".

(Of course the time stamp is for the whole file; not just for a subrange of bytes or whatever; if anything is altered, then the timestamp doesn't hold for the altered object.)

Reply on news.ycombinator.com