Re: SHA1 collisions found
- From
Jeff King <peff@peff.net>
- Date
- Feb 23, 2017, 20:57 UTC
- Message-ID
- <20170223205739.t4kekrp2kb7zkimv@sigill.intra.peff.net>
- In-Reply-To
- <e57958d4-7c51-3f5e-6ff5-f863920fd883@gmail.com>
On Thu, Feb 23, 2017 at 09:49:09PM +0100, Jakub Narębski wrote:
Show 12 quoted lines
> > How is GIT affected? GIT strongly relies on SHA-1 for the > > identification and integrity checking of all file objects and > > commits. It is essentially possible to create two GIT repositories > > with the same head commit hash and different contents, say a benign > > source code and a backdoored one. An attacker could potentially > > selectively serve either repository to targeted users. This will > > require attackers to compute their own collision. > > The attack on SHA-1 presented there is "identical-prefix" collision, > which is less powerful than "chosen-prefix" collision. It is the > latter that is required to defeat SHA-1 used in object identity. > Objects in Git _must_ begin with given prefix;
I don't think this helps. The chosen-prefix lets you append hash data to an existing file. Here we just have identical prefixes in the two colliding halves. In the real-world example, they used a PDF header. But it could have been a PDF header with "blob 1234" prepended to it (note also that Git's use of the size doesn't help; the attack files are the same length).
> the use of zlib > compression adds to the difficulty. 'Forged' Git object would > simply not validate...
No, zlib doesn't help. The sha1 is computed on the uncompressed data.
-Peff