Cryptographically timestamping all your Git commits automatically
gwern.net
gwern.net
For the use described here, however - proving to someone else that you had a specific repository content - collision availability renders a proof useless. Similarly, for this specific use, Git's standard support for PGP signatures is also useless - you can use a 4,096 bit RSA signature, but it only guarantees a 160-bit SHA1 hash, which (given collisions) is not dependable as a proof.
If you really need it, you need something else - use an SHA2 or SHA3 variant on an repeatable export of the database, e.g. using git-evtag [1] (not my project; Note: I haven't audited it, and I don't consider myself a qualified cryptographer - Use at your own peril).
[0] https://sites.google.com/site/itstheshappening/
[1] https://github.com/cgwalters/git-evtag
edit: added wording to make clear I am not the author of git-evtag
Can you elaborate on this? While it's true that SHA-1 is now broken, my understanding is that git's reason for using SHA-1 was to ensure the integrity of the entire history.
However, Linus used SHA1, which offered two additional properties not strictly needed for the git use case:
1) Preimage resistance - that is, it is considered practically impossible in the next few decades to find an input file with a given hash
2) Collision resistance - that is, to find two different input files with the same hash.
preimage collision means that given a hash for a known repository state in which no file was controlled by an adversary at any point in time, you can be sure that if the hashes match, the content matches.
collision resistance means that given a hash for a known repository state, you can be sure that if the hashes match, the content matches. (Notice that with collision resistance, it is ok even if some files were controlled by an adversary).
When Linus chose SHA1, he got those two features "for free" (almost free - CRC-160 would be slightly faster to compute than SHA-1, but either is negligible in the grand scheme of things). But IIRC he explained several times that he wasn't looking for them. It turns out that collision resistance is probably not a feature of SHA1.
Now, SHA1 is still useful to prove to yourself that nothing was changed provided that none of the files was created by an adversary (no preimage attack known yet). However, for proving the state of a repository to a 3rd party (who may assume you are an adversary), is no longer provided through SHA1.
(As I understand the writeup, it is ultimately just generating a longer/securer hash of the entire tree's contents rather than just SHA1s, and so the post-commit script could be as simple as 'timestamp `git-evtag`', but the compile failed on my system so I am unable to try it out personally.)
1) No reliance on external archives, so all the data required to prove a timestamp should be automatically downloaded after the stamp has hit the blockchain. This should certainly include the necessary subset of the "OriginStamp archives". I'm not sure if it needs to include the blockchain or not.
2) Automatic verification that my requested timestamps have hit the blockchain on schedule and the data required to prove the timestamp downloaded and saved.
Both of these could be done in client software - I have no objection to the principle of the system which seems sound to me.
I agree that ideally one would somehow get that data automatically as well (it's just that writing the scripts for automatically submitting is much easier than writing scripts for automatically retrieving...) I've already emailed the two OriginStamp devs asking for thoughts on how users could automatically get the list of hashes for each day that concerns them.
There's some email functionality in OriginStamp which might be reusable for this purpose, in which case one could include one's email address in the shell script and get one email a day listing the hashes you made and containing an attachment with that day's total hashes (so you can verify that your hashes are in the master list, that the master list hashes to the master hash, and then look up whether that master hash's corresponding Bitcoin address has received a transaction or not that day).
How is this a time stamp? The hash doesn't change if you touch the file's modification 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!
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.
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.
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.
(If you could certify a timestamp forever, in a non-expiring, uncrackable way, why wouldn't you just use that for the whole file?)
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!
(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.)
Seriously?
E.g. https://startssl.com/?app=25#61
Decentralized not usable in a legal context in any jurisdiction I can think of, and why do you timestamp if not to cover your ass?
I haven't seen anyone writing on this topic who argues that a Bitcoin timestamp would not be usable anymore than your favored old-style notaries would be unusable. Can you point to any specific cases, or even something like a legal review, in which a Bitcoin timestamp is rejected as invalid?
> why do you timestamp if not to cover your ass?
There are many uses for timestamps. Legal ones are not even my particular use case.
And your stated used case "Local archives are useful for personal purposes, but sometimes, in investigations that may be controversial, you want to be able to prove that the copy you downloaded was not modified and you need to timestamp it" looks like planning to defend yourself in court to me...
[1] http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:319... also https://en.wikipedia.org/wiki/Electronic_Signatures_Directiv...
Not what I asked. I asked if there was any evidence indicating that courts would reject Bitcoin timestamping despite being based on the same concepts, and in several ways superior to, the old-fashioned centralized timestampers. To which your answer is apparently simply 'no'.
> looks like planning to defend yourself in court to me...
I know what I said.
I don't see how a distributed ledger can be compared, even remotely, to a notary. The fact that both are based on digital signature is pretty irrelevant...
If things go far, the notary can be audited, can testify in court... It is completely old fashioned, quite possibly retarded, but courts like physical or legal entities vouching for stuff, and being accountable for it...
I could return the question to you, have a Bitcoin secured timestamp ever held up in court? Because notary signed timestamp are used for many things from contracts to tax fillings all over the EU...
I know what I said.
So, if the purpose is not defending yourself in court, what is it? Winning Internet arguments?
You're right. A distributed ledger is much securer and more reliable, far less vulnerable to any form of coercion or corruption, and so the comparison is kind of silly.
> I could return the question to you, have a Bitcoin secured timestamp ever held up in court?
Since it is based on the same basic principles but in a much superior fashion, I, and everyone using Bitcoin-based timestamps, am comfortable in believing there's a excellent chance the courts will not be unaccountably incompetent and reject them, until such time as shown otherwise. If you can't provide any specific concrete reason they would reject Bitcoin timestamps other than 'it has not been yet been tested in court', then there's nothing further to discuss.
> So, if the purpose is not defending yourself in court, what is it? Winning Internet arguments?
That is not an answer I'm allowed to give now. (And in any case, you have shown yourself sufficiently unpleasant and arrogant I wouldn't answer it anyway.)
I wish I shared your optimism, but as of now, I'd take tested in court over untested in court in most cases.
That is not an answer I'm allowed to give now. (And in any case, you have shown yourself sufficiently unpleasant and arrogant I wouldn't answer it anyway.)
I'm sorry I came out that way, I was just very surprised you didn't even talk of the technology behind what amount to the vast majority of cryptographic timestamping activity (e.g. bills, contract are routinely cryptographically timestamped in Europe).
Protip: don't tell someone what they think when they clearly and intentionally wrote the opposite; don't ask for things they are clearly intentionally withholding; and don't criticize without even bothering to understand what the advantages might be of a method.