5 ms·

It shows this as justification right now: Oakley Group 14 is no longer considered secure enough. SHA-1 is no longer considered secure enough (see shattered.io)

It shows this as justification right now: Oakley Group 14 is no longer considered secure enough. SHA-1 is no longer considered secure enough (see shattered.io).

pawadu 9y ago
Here is my problem with this statement: SHA-1 can be used in different configurations for different applications. Some are secure, some are not. People making these blanket statement very clearly demonstrate that they don't understand security and cryptography. Do you really want to use a security tool written by such people? https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL
- CJefferson 9y ago
  I disagree with Linus here -- there are hashes which are secure in all ways, and hashes which are broken, like SHA1. Why try to figure out where SHA1 is safe? Also, git's use of SHA1 is completely broken, it's just that no-one (that we know of) has chosen to spend the money required to make evil git repositories (you can't just take existing collisions and use them in git, you would have to go find git-specific ones).
  - breser 9y ago
    You'd have to find collisions that are of an identical length and still be useful (i.e. able to do something evil rather than just being a bunch of random data). The current techniques for creating collisions in SHA1 don't make it possible to find identical length collisions. So your statement that nobody has bothered to spend the money to create the collisions is not correct. Now if you want to say that nobody has spent the time to find a technique to produce identically sized collisions, that would be correct. But that's far from trivial and we don't know that such a technique is guaranteed to exist.
    - CJefferson 9y ago
      I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/ http://shattered.io/. Both 422435 bytes.
      - 0x6c6f6c 9y ago
        Or you aren't understanding the key statement of his comment > You'd have to find collisions that are of an identical length and still be useful Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible. Git doesn't simply SHA-1 a file or the repo, it's more than that. Linus: > I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header. [https://stackoverflow.com/questions/42433126/how-does-the-newly-found-sha1-collision-affect-git https://stackoverflow.com/questions/42433126/how-does-the-ne...]
        deathanatos 9y ago
        > Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible. This is incorrect. Git attaches a header to the blob before hashing, that much is true, but the technique used by Shattered to create colliding hashes can be used to create colliding Git hashes as well — you simply need to take the header into account in advance of doing the collision. (Which is why the particular PDF files released by Shattered do not hash to the same value in Git, but that does not mean that the technique used does not apply: it does.) At the time of shattered's release, I commented on this[1]; that comment goes a bit more into the paper's findings. > Or you aren't understanding the key statement of his comment Frankly, I thought the key statement of his original comment, as applicable to SSH, was, why use SHA1 when SHA256 exists, and doesn't have these issues? Take the route that requires you to not need to be a cryptographer to figure out if it'll work or not. [1]: https://news.ycombinator.com/item?id=13729985 https://news.ycombinator.com/item?id=13729985

It shows this as justification right now: Oakley Group 14 is no longer considered secure enough. SHA-1 is no longer considered secure enough (see shattered.io).

pawadu 9y ago

Here is my problem with this statement: SHA-1 can be used in different configurations for different applications. Some are secure, some are not. People making these blanket statement very clearly demonstrate that they don't understand security and cryptography. Do you really want to use a security tool written by such people? https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

CJefferson 9y ago
I disagree with Linus here -- there are hashes which are secure in all ways, and hashes which are broken, like SHA1. Why try to figure out where SHA1 is safe? Also, git's use of SHA1 is completely broken, it's just that no-one (that we know of) has chosen to spend the money required to make evil git repositories (you can't just take existing collisions and use them in git, you would have to go find git-specific ones).
- breser 9y ago
  You'd have to find collisions that are of an identical length and still be useful (i.e. able to do something evil rather than just being a bunch of random data). The current techniques for creating collisions in SHA1 don't make it possible to find identical length collisions. So your statement that nobody has bothered to spend the money to create the collisions is not correct. Now if you want to say that nobody has spent the time to find a technique to produce identically sized collisions, that would be correct. But that's far from trivial and we don't know that such a technique is guaranteed to exist.
  - CJefferson 9y ago
    I think you are behind the times. There is already pairs of identical SHA1s, that do "interesting things", like these two PDFs by Google (and others): http://shattered.io/ http://shattered.io/. Both 422435 bytes.
    - 0x6c6f6c 9y ago
      Or you aren't understanding the key statement of his comment > You'd have to find collisions that are of an identical length and still be useful Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible. Git doesn't simply SHA-1 a file or the repo, it's more than that. Linus: > I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header. [https://stackoverflow.com/questions/42433126/how-does-the-newly-found-sha1-collision-affect-git https://stackoverflow.com/questions/42433126/how-does-the-ne...]
      - deathanatos 9y ago
        > Creating a collision is possible, making it work in a way that conforms to the manner of which Git uses SHA1 and also provides the malicious code is the part that the Shattered research did not prove possible. This is incorrect. Git attaches a header to the blob before hashing, that much is true, but the technique used by Shattered to create colliding hashes can be used to create colliding Git hashes as well — you simply need to take the header into account in advance of doing the collision. (Which is why the particular PDF files released by Shattered do not hash to the same value in Git, but that does not mean that the technique used does not apply: it does.) At the time of shattered's release, I commented on this[1]; that comment goes a bit more into the paper's findings. > Or you aren't understanding the key statement of his comment Frankly, I thought the key statement of his original comment, as applicable to SSH, was, why use SHA1 when SHA256 exists, and doesn't have these issues? Take the route that requires you to not need to be a cryptographer to figure out if it'll work or not. [1]: https://news.ycombinator.com/item?id=13729985 https://news.ycombinator.com/item?id=13729985