| 1 |
On Tue, Sep 16, 2014 at 5:11 AM, Gordon Pettey <petteyg359@×××××.com> wrote: |
| 2 |
> On Mon, Sep 15, 2014 at 7:02 AM, hasufell <hasufell@g.o> wrote: |
| 3 |
>> |
| 4 |
>> hasufell: |
| 5 |
>> > |
| 6 |
>> > * there is no known SHA-1 collision afais |
| 7 |
>> > * calculating one isn't that hard. NSA might be able to do it in |
| 8 |
>> > reasonable time |
| 9 |
>> > * however, the algorithms to do that will come up with random garbage, |
| 10 |
>> > so it's a completely different thing to hide a useful vulnerability |
| 11 |
>> > behind a SHA-1 collision |
| 12 |
>> > |
| 13 |
>> |
| 14 |
>> That said... an attacker who has that much resources to calculate a |
| 15 |
>> _random_ hash collision in reasonable time would certainly have a lot of |
| 16 |
>> easier attack vectors than forging a _non-random_ hash collision that |
| 17 |
>> contains actual working code (which, afaiu doesn't effectively work with |
| 18 |
>> the current attack algorithms on SHA-1). |
| 19 |
>> |
| 20 |
>> He could simply break into one of the ~200 developer computers. There's |
| 21 |
>> a pretty high chance at least one of them is running windows or known |
| 22 |
>> vulnerable versions of the kernel or other random packages. |
| 23 |
>> |
| 24 |
>> No need to waste millions of dollars on SHA-1. |
| 25 |
> |
| 26 |
> |
| 27 |
> Even if you wanted to burn the money to find that magical collision that |
| 28 |
> actually contains working code, you've still got to somehow propagate that |
| 29 |
> to other repositories, since they'll just ignore it for having the same hash |
| 30 |
> as an already-existing object. |
| 31 |
|
| 32 |
In the fetch/pull case, if you receive the "same" object that you |
| 33 |
already have, git performs byte-to-byte comparison and warns loudly if |
| 34 |
the "new"object does not match yours. |
| 35 |
-- |
| 36 |
Duy |
Archives