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.

15 of 87 comments (clear)

  1. what about git? by slashdice · · Score: 5, Funny

    Git uses SHA1 so every git repository should now be considered compromised. Dice is holding an all-hands meeting this afternoon to find a replacement. Since sourceforge supports SVN and CVS, we may use them. They're highly performant, easy to use, and (most importantly) their crypto can't be broken since they don't have any.

    --
    Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
    1. Re:what about git? by Immerman · · Score: 3, Interesting

      Har har.
      But seriously, as I recall git doesn't use SHA 1 for security, but just as a really good hashing algorithm.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    2. Re:what about git? by queazocotal · · Score: 5, Insightful

      Not quite.
      This is not yet a full attack on SHA-1.
      It cannot - yet - be used to generate a collision for any known hash.
      It is an indication that you should move away from sha-1 as fast as you can.

    3. Re:what about git? by NotInHere · · Score: 3, Insightful

      No. That's second preimage attack. Collision is if you can chose multiple versions to map to the same hash.

    4. Re:what about git? by John+Allsup · · Score: 5, Interesting

      Immerman's point is essentially right. Here is a more thorough opinion.

      Git does not use SHA1 for cryptographic purposes. The use of SHA1 for cryptographic purpose is what should be deprecated. If major git repositories start calculating SHA256 hashes too, and keep an eye out for in the wild collisions, it will probably be ok. Git does not need to be attack resistant like TLS does. In any case, it is worth rejigging the code so that the hash is done via a plugin and can be migrated, if this isn't already done. I haven't read the git source and am not sure, but it would be easy to get it done before it becomes a problem for git. I use md5sum for a lot of applications which don't require security sufficient for cryptographic purposes. Cryptography is the Formula 1 of computation, and just like most vehicles don't need to compete against an F1 car, many of the trickle-down uses of cryptographic hashes will be fine for a while. Git only has an issue if two versions of files in the same repo produce the same hash. In practice that means two compilable source files, rather than arbitrary meaningful input. That makes cracking much harder since you have a language recognition problem bolted onto the frontend of your hash, so most potentially colliding inputs will be excluded by this (if one colliding file is a C file, and the other is bad French poetry, it is clear which is intended -- cryptographic purposes cannot rely upon such applications of commonsense recognition). Do not worry about Git.

      As an exercise, try and write two valid Python3 files between 10 and 30 lines long importing only sys, re and glob, such that they have identical md5sum outputs. By reducing the input space for a hash, you can make collisions less likely. What is important about this attack is that there is a round trip forward through the hash, and then backwards to a different input. By looking at the information discarded by the nonlinear parts of the hashing algorithm (that is, the non-reversible steps) you can start to make meaningful sense of what the hash is doing. Interestingly, if you produce a language specification which permits fewer valid inputs than the number of possible hash outputs, it is in principle possible that no collisions will occur. Indeed it would be a good exercise for a beginning cryptanalyst to try and construct a language such that valid inputs were guaranteed to get different md5sum outputs.

      --
      John_Chalisque
    5. Re:what about git? by Anonymous Coward · · Score: 5, Informative

      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)

    6. Re:what about git? by Anonymous Coward · · Score: 5, Funny

      The colliding file will be line noise

      I guess Perl projects using git are in trouble.

  2. Re:I won't be all that surprised... by Lunix+Nutcase · · Score: 5, Interesting

    People have been attacking SHA-1 since 2005.

    https://en.wikipedia.org/wiki/...

    No need for any conspiracy since people were warned about potential weaknesses in SHA-1 for a decade.

  3. combine them? by JigJag · · Score: 3, Interesting

    One thing that always bothered me with announcements like 'MD5 is dead because we can forge collisions' is that what are the chances that the forgery would pass *both* MD5 and SHA1 ?

    Say you have a string S and a forged S' so that S != S' and MD5(S) = MD5(S') and let's say you can create S' easily regardless of S. That's the definition of a hash collision and a proof that the algorithm can't be trusted anymore. Surely, the odds that it also satisfies SHA1(S) = SHA1(S') are close enough to impossible, no?

    If that's the case, then sign your certs, code, etc with concat(MD5(S),SHA1(S)) instead of just one broken hash. Yes, two broken hashes are indeed protecting you.

    --
    "The hallmark of humanity is the ability to move beyond sensory inputs" - Mary Helen Immordino-Yang
    1. Re:combine them? by Sigma+7 · · Score: 3, Informative

      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...

  4. Re:I won't be all that surprised... by Lunix+Nutcase · · Score: 3, Informative

    Not really. People at Microsoft Research showed it to be broken years before it became a scandal. No one bothered to listen.

  5. Deliberately Incoherent Ramblings by Anonymous Coward · · Score: 3, Funny

    LOL, I successfully trolled a mod. :)

    That's going to keep me smiling all day!

    And here I thought you were just smoking crack.

  6. Re:I won't be all that surprised... by TheRealHocusLocus · · Score: 5, Interesting

    Well, wasn't that what happened with Dual_EC_DRBG?

    We can never know for sure, but empirically, I really don't think Dual_EC_DRBG ever pinged on NSA's --- or any other state intel actor's --- radar. At least not before EC vulnerabilities became public knowledge. Its use by default in the RSA BSafe toolkit meant that products using that toolklit would be vulnerable. And YES, that was a rich prize. BSafe may have been part of a program to seed a backdoor towards, say, a particular target state or industry.

    BUT... there is for me an irreconcilable problem with that theory. I ran an ISP in those crazy early days when administrators were faced with a choice of whether to 'drop in' a BSafe object library under license (prove USA blahdy-blah) or compile the SSLeay/OpenSSL source, which was by no means as smooth and functional as it is today. But even pre-2000 it was obvious that the whole world was going the OpenSSL open source route as soon as it was stable.

    Given that OpenSSL's populary was increasing by leaps and bounds... and yet, the OpenSSL FIPS Object Module v2.0 had a bug that prevented Dual_EC_DRBG from being used. *IF* the back door was being actively exploited by some state actor, they would have noticed this right away and it would have been a trivial matter (and top priority) for some helpful volunteer to emerge from the shadows and toss in a fix for it. Maybe even a soft-sell for epileptic curves. But this did not happen. Ergo, circumstances more closely resemble a situation in which NOBODY, including NSA, cared.

    Remember that intel agencies are padded with the same bloviating internal memos as any organization, and love to take 'credit' for a thing to show their prowess whether or not the thing is actively being used. Maybe a good part of Snowden's trove are empty boasts.

    --
    <blink>down the rabbit hole</blink>
  7. Re:Weak attack by BronsCon · · Score: 3, Informative

    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.
  8. Re:I won't be all that surprised... by arglebargle_xiv · · Score: 3, Insightful

    People have been attacking SHA-1 since 2005.
    https://en.wikipedia.org/wiki/...
    No need for any conspiracy since people were warned about potential weaknesses in SHA-1 for a decade.

    It's also important to point out that this is a free-start collision, where the attacker gets to choose the initial values, something that isn't possible with full SHA-1. This makes the attack much, much easier than an attack on full SHA-1. It took nearly a decade to go from the first free-start collision on MD5 to an actual attack, and MD5 was a much weaker function than SHA-1. Their estimate of "end of the year" may be a bit optimistic.