
Cryptographically timestamping all your Git commits automatically - gwern
http://www.gwern.net/Archiving%20URLs#cryptographic-timestamping
======
beagle3
The main problem is relying on Git's SHA1s for security. Git was not designed
for security - it was a nice side effect while SHA-1 was dependable. But it
isn't any more; a method for finding freestart collisions ("SHAppening" [0])
is already known, and it is expected that standard collisions will be found
within a year. (Preimages are not expected for a few decades or hundred years
though)

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/](https://sites.google.com/site/itstheshappening/)

[1] [https://github.com/cgwalters/git-evtag](https://github.com/cgwalters/git-
evtag)

edit: added wording to make clear I am not the author of git-evtag

~~~
detrino
> Git was not designed for security

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.

~~~
beagle3
The requirement for git was integrity against random bit flips. Linus could
have used CRC-160 instead (or any other good hash, e.g. modolu 2^160-x for
small x that makes it prime), and get equally good protection against random
bit flips, or honest mistakes.

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.

~~~
detrino
I've looked into this and it seems you are correct, thanks for the
explanation.

------
rlpb
This is quite useful. But to have full confidence in it, I'd like to see:

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.

~~~
gwern
> 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 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).

------
kazinator
> _The most robust way of timestamping is cryptographic timestamping, where
> the downloaded file is hashed using a cryptographic hash function like
> SHA-256, and then the hash is published._

How is this a _time_ stamp? The hash doesn't change if you touch the file's
modification time.

~~~
michaelt
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!

~~~
kazinator
> _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.

~~~
cba9
> 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.

~~~
kazinator
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?)

~~~
cba9
> 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!

~~~
kazinator
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.)

------
brohee
Talking cryptographic timestamping and talking only about random brodude
startups and not about established, working standard like RFC 3161/3628 and
the many digital notaries offering the service...

Seriously?

~~~
gwern
Are any of those digital notaries provably decentralized, secure, free, and
scriptable in one or two lines?

~~~
brohee
Decentralized no, but free and scriptable yes

E.g. [https://startssl.com/?app=25#61](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?

~~~
gwern
> Decentralized not usable in a legal context in any jurisdiction I can think
> of

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.

~~~
brohee
Well the use of digital certificats for timestamping is explicitely covered in
Directive 1999/93/EC [1]. I'll freely admit not being up to date on the
situation on the other side of the Atlantic. While Bitcoins may start to get
some recognition as an asset, I'd wage real money that no law anywhere
explicitely recognize the blockchain as a legaly opposable timestamping
authority.

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...](http://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=celex:31999L0093) also
[https://en.wikipedia.org/wiki/Electronic_Signatures_Directiv...](https://en.wikipedia.org/wiki/Electronic_Signatures_Directive)

~~~
gwern
> Well the use of digital certificats for timestamping is explicitely covered
> in Directive 1999/93/EC [1].

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.

~~~
brohee
_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'._

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?

~~~
gwern
> I don't see how a distributed ledger can be compared, even remotely, to a
> notary.

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.)

~~~
brohee
_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_

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).

~~~
gwern
> I'm sorry I came out that way

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.

