[pslam]

Marc Stevens quotes $500K, which is very much still a threat (even an order of magnitude more would be). Plenty of organizations would be willing to spend that much pocket change on a single attack.

The game-changer is it's chosen-prefix. A vendor can produce a pair of entirely different binaries with the same hash, but most importantly, they look and behave sane except for the last few blocks of the file. This is easily hidden, especially if the binary is encrypted.

It's not a stretch of the imagination to see how, for example, an IP camera vendor could do exactly this. Yes, it requires a nefarious/complicit vendor, or an insider who can pull this off undetected (not everyone has a fully automated build/release pipeline).

So it changes the threat model. SHAtter was waived by many because the threat model didn't convincingly apply to them. Example: git. That analysis needs to be repeated.

(All this assuming the attack described in the paper is correct and practical in real world implementation)

[avar]

> SHAtter was waived by many because the threat model didn't convincingly apply to them. Example: git.

Git quickly switched to the sha1collisiondetection library[1] by default after the SHAttered attack was published. It's a SHA-1 library written by the authors of the paper which the attack.

Edit: Marc Stevens saying that existing library will mitigate this new attack: https://twitter.com/realhashbreaker/status/11284190295369236...

1. https://github.com/cr-marcstevens/sha1collisiondetection

[AnaniasAnanas]

That still does not solve the issue with OpenPGP signatures though, does it?

[avar]

It does, because a tag pointing to the malicious content wouldn't hash with sha1collisiondetection's modified SHA-1, just like you can't add the SHAttered PDFs to git.

[bin0]

Git isn't really designed for cryptographic security, is it? I have heard that Linus wants it mostly secure so people can verify the integrity of linux source code, but it's not its core competency, so to speak. Though I suppose a project the size of the linux kernel could be a serious target for a collision attack.

Regardless, it's switching to SHA-256: https://stackoverflow.com/questions/28159071/why-doesnt-git-...

[gnomewascool]

Git signatures are designed for cryptographic security, and they (currently) rely on the SHA-1 hashes.

When you're signing a commit (or a tag) you're just signing the commit (or tag) message which includes the SHA-1 hash of the relevant "root" tree object (or commit object). The tree object, in turn is (in effect) a list of SHA-1 hashes of the files directly in the directory, along with their file sizes and permissions, plus the hashes of the tree objects corresponding to any subdirectories.

Consequently, if you replaced a file with another having the same SHA-1 hash (and the same file size — a considerable complication), all the hashes would remain the same and the signature would still be valid.

Obviously, once git transitions to SHA-256, the problem will disappear.

[pslam]

An easy example with git would be to create a pair of read-only repositories: one public-facing which is cloned by the general public, and one with (potentially entirely) different contents which can be selectively pulled depending on the client.

There's a complication with the few appended trailing blocks being invalid data, but the format might allow it, and git doesn't verify its integrity recursively.

[avar]

> git doesn't verify its integrity recursively

Yes it does. On clone the entire history is recursively hashed, and incrementally on fetch.

There isn't even any place in the protocol to transfer pre-hashed content, it must be hashed to make it addressable.

[hannob]

> Git isn't really designed for cryptographic security, is it?

Well, the git documentation says it is: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

It is certainly not helpful that Linus at the same time says conflicting things publicly. It would be nice to have some clearly documented expected security properties of the git structure.

This confusion is all a bit unfortunate. While the attack scenarios are obscure, with a secure hash function Git would have some really nice properties to use it in other areas, it would effectively be a secure append-only log. (Some people call this something with the B word which I'll avoid, but that's effectively what it is.)

[jwilk]

FWIW, this isn't official Git documentation, just a book about Git.