Re:Cryptographically timestamping all your Git commits autom...
by kazinator on Friday December 04, 2015 @10:38AM
(#10676850)
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?)
Re:Cryptographically timestamping all your Git commits autom...
by cba9 on Friday December 04, 2015 @05:31PM
(#10679650)
> 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!
Re:Cryptographically timestamping all your Git commits autom...
by kazinator on Sunday December 06, 2015 @10:09PM
(#10687826)
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.)
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.