News for hackers. Stuff that matters.
Re:Cryptographically timestamping all your Git commits autom... by beagle3 on Thursday December 03, 2015 @12:53PM (#10671174)
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/

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

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

Re:Cryptographically timestamping all your Git commits autom... by gwern on Thursday December 03, 2015 @05:07PM (#10673060)
SHA1 still seems pretty good for most purposes. It would be nice to see if git-evtag would work easily with timestamping.

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

Re:Cryptographically timestamping all your Git commits autom... by detrino on Thursday December 03, 2015 @03:20PM (#10672285)
> 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.

Re:Cryptographically timestamping all your Git commits autom... by beagle3 on Friday December 04, 2015 @09:06AM (#10676340)
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.

Re:Cryptographically timestamping all your Git commits autom... by detrino on Saturday December 05, 2015 @02:35PM (#10682997)
I've looked into this and it seems you are correct, thanks for the explanation.