Hem , sha-3 i suppose, keccak, no ? But really is not so urgent as you
have already told .
2012/10/15, Jeff King <p...@peff.net>:
> On Mon, Oct 15, 2012 at 07:47:09PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Oct 15, 2012 at 6:42 PM, Elia Pinto <gitter.spi...@gmail.com>
>> > Very clear analysis. Well written. Perhaps is it the time to update
>> > http://git-scm.com/book/ch6-1.html (A SHORT NOTE ABOUT SHA-1) ?
>> > Hope useful
>> > http://www.schneier.com/crypto-gram-1210.html
>> This would be concerning if the Git security model would break down if
>> someone found a SHA1 collision, but it really wouldn't.
>> It's one thing to find *a* collision, it's quite another to:
>> 1. Find a collision for the sha1 of harmless.c which I know you use,
>> and replace it with evil.c.
>> 2. Somehow make evil.c compile so that it actually does something
>> useful and nefarious, and doesn't just make the C compiler puke.
>> If finding one arbitrary collision costs $43K in 2021 dollars
>> getting past this point is going to take quite a large multiple of
> There are easier attacks than that if you can hide arbitrary bytes
> inside a file. It's hard with C source code. The common one in hash
> collision detection circles is to put invisible cruft into binary
> document formats like PDF or Postscript. Git blobs themselves do not
> have such an invisible place to put it, but you might be storing a
> format that does.
> But worse, git _commits_ have such an invisible portion. We calculate
> the sha1 over the full commit, but we tend to show only the portion up
> to the first NUL byte. I used that horrible trick in my "choose your own
> sha1 prefix" patch. However, we could mitigate that by checking for
> embedded NULs in git-fsck.
>> 3. Somehow inject the new evil object into your repository, or
>> convince you to re-clone it / clone it from somewhere you usually
> Yeah, this part is the kicker. With the commit NUL trick, you would make
> a useful commit and then ask somebody to pull it, and then later replace
> it with a commit pointing to an arbitrary tree. But if we assume we can
> detect that easily (which I think we can), we are left with replacing
> binary blobs that have hidden bits. And most projects do not take many
> such blobs, and the result is that you could only replace the contents
> of that particular blob, not an arbitrary part of the tree.
>> It would be very interesting to see an analysis that deals with some
>> actual Git-related security scenarios, instead of something that just
>> assumes that if someone finds *any* SHA1 collision the sky is going to
> I agree that most of the analysis is overblown. Having read the analysis
> Schneier pointed to, it actually is not that bad. We have 5-10 years to
> get to a point where it's really expensive and extremely complex to
> mount a single attack.
> That doesn't seem like an emergency to me. It sounds like something we
> should be thinking about (and we are). The simplest thing would be to
> wait for a moment when it makes sense to break compatibility (e.g., we
> decide that "git 2.0" is here, and everybody will have to rewrite to
> take advantage of new features, so we can jump to sha-2). We can also
> start building sha-2 history that references sha-1 history. That would
> mean everybody needs to upgrade their git, but that is not a problem
> that requires 5-10 years of foresight and planning.
Inviato dal mio dispositivo mobile
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html