Slashdot Mirror
First Successful Collision Attack On the SHA-1 Hashing Algorithm (google.com)
Artem Tashkinov writes: Researchers from Dutch and Singapore universities have successfully carried out an initial attack on the SHA-1 hashing algorithm by finding a collision at the SHA1 compression function. They describe their work in the paper "Freestart collision for full SHA-1". The work paves the way for full SHA-1 collision attacks, and the researchers estimate that such attacks will become reality at the end of 2015. They also created a dedicated web site humorously called The SHAppening.
Perhaps the call to deprecate the SHA-1 standard in 2017 in major web browsers seems belated and this event has to be accelerated.
Perhaps the call to deprecate the SHA-1 standard in 2017 in major web browsers seems belated and this event has to be accelerated.
Why can't git be updated to just use another algorithm?
First off, Linus on the topic of SHA1 safety: (SO link, as the git mailing list links are flaky on me today)
The problem is that git uses the SHA1 hash *extensively* for "permanent" identification of things. There's a host of existing usage out there which would need to be updated/converted, and any conversion of an existing repository would completely invalidate any crosslinks/references using the SHA1 format. Also, because git allows shortened hashes to be used for identification, there's no way you can use the length of the hash to tell the difference between two hash formats for a "mixed" repository.
That said, it's not really a big deal. Even if you can manufacture a hash collision, there really isn't a good way to use it to attack a (remote) git repository. Even if you could create a file with the same SHA1 hash as a typical file in a git repository, it's highly unlikely to be anything approximating something that's in an appropriate format. The colliding file will be line noise, rather than a compile-able C++ file, for example.
Moreover, git is set up to use the *previous* version of a file in case two files have the same SHA1 has. So you can create a SHA1 collision of an existing file ... which is then ignored by git in favor of the other file. The only way around that is if you have admin access to the remote git repository, or can somehow contrive to get your malicious file accepted to the repository prior to the file you're trying to collide with. (In which case, where are you getting the SHA1 you're targeting from?)
Even then, if someone has a "clean" copy of the file you're colliding with, makes a modification to that and re-commits, your malicious file will be overwritten wholesale by the new version of the non-malicious file (as git commits encode full file changes, rather than file deltas, so the new SHA1 will be encoded as the new version of the old SHA1).
You might be able to promote a divergence in the code tree due to the different files, but given that everyone in git has a full version of the repository on their disk, it would soon become apparent that something "funky" is going on in the commit history.
In short, even if you can make deliberate collisions with SHA1, that doesn't change the usefulness (and safety) of SHA1 for git, just like rot13 being a poor encryption doesn't mean you need to use PGP to encode your usenet joke punchlines.
(BTW,. I'm guessing the GP post is supposed to be a joke)
Not really. People at Microsoft Research showed it to be broken years before it became a scandal. No one bothered to listen.
Apparently, concatenation isn't as effective as it could be. It will be at least as strong as either MD5 or SHA1, and while it seems that you'd get a 288 bit hash, it's about as strong as if you had 174 bits.
It's probably easier to make a 288 bit hash from the start.
Discussion page: http://crypto.stackexchange.co...
Unlike MD5, it is still impossible to get two different files that have the same standard SHA-1 checksum.
False. As long as there are potentially more bits in the input than there are in the output (read: the input can be longer than the resulting hash), any hashing algorithm will have collisions. It is the difficulty in generating these collisions that makes the algorithm strong or weak; and they are quite easy to generate for MD5.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.