8 ms·

Strange that people are still implementing technology around SHA1. It is still challenging to find collisions, but none the less SHA1 is provably broken.

mehrdadn 6y ago
It's not "strange"... earlier hash algorithms tend to enjoy better performance and compatibility, and there are still use cases for which SHA1 (and even MD5) aren't broken.
- bawolff 6y ago
  Sha256 has special instructions in silicon for it. Performance is not a reasonable excuse. If performance mattered and you didnt need sha's security properties, you would be using CRC32 or something.
  - mehrdadn 6y ago
    Excused or not, I'm merely explaining why this isn't surprising.
- cyphar 6y ago
  But there are even better choices for non-cryptographic hash functions (FNV and MurmurHash for instance) because they were designed without the need to have a tradeoff between cryptographic security and efficiency.
userbinator 6y ago
Just like security in the physical world, sometimes the weakness is not that great in practice. If you watch enough lockpicking videos on YouTube you may come to the same conclusion. Would I still trust MD5 to be a strong check against random/non-malicious corruption? Yes. Would I trust it against malicious corruption? No.
- saagarjha 6y ago
  I would, depending on what I was protecting. I use it every day in Git, for example, on projects where integrity is of moderate importance. Now, against a nation-state? No way.
  - bawolff 6y ago
    Against nation state, that ship sailed a long time ago. We're currently in the realm of 10-20 thousand dollars to make SHA-1 collisions. That's in the realm of an individual, albeit a reasonably (but not extremely) wealthy one. In 5-10 years it may be in the realm of J. random hacker.
    - entee 6y ago
      Naive question: how often is that collision the same number of bytes as the original?
      - userbinator 6y ago
        I've never seen a colliding pair in a "true" hash function (not just CRC) be of differing lengths. They've always been a pair of blocks with very few differing bits, such that the differences "cancel out" in the computation and the internal state is the same regardless of which of the pair is run through it. I suspect trying to create a colliding pair with differing lengths is much more difficult, since SHA1 also includes the length as part of the calculation.
- WrtCdEvrydy 6y ago
  In forensics work, MD5 is still used for checksums. It's used for consistency, not uniqueness, so it will likely be usable for years to come.
  - eli 6y ago
    Still seems less than ideal to be able to generate a second document that hashes to the same value.
upofadown 6y ago
Well they are not in this particular case. These are old keys.
- bawolff 6y ago
  The article said they were new keys.
_jjkk 6y ago
You're assuming that all code performing SHA requires a "secure" hash. It's only "broken" for security applications, and there are tons of others for which security is not even a consideration, or where collision is not possible due to input constraints.
- bawolff 6y ago
  That would have to be some pretty constrained input if you are rulling out collisions in principle
  - deleted 6y ago
    [deleted]
- cyphar 6y ago
  There are hashes which require much less computing power and thus have better throughput if you don't require cryptographic security (examples include FNV-1 and MurmurHash). Using SHA-1 because you "don't need it for security" is still a poor choice. I'd also argue that the default choice of hash function should always be a secure one until a strong counterargument is given, because it turns out that at some point most developers assume hashes have some minimal security properties (Linus always claimed that the choice of hash function in Git was not about cryptographic security -- and yet the security of the GPG signing of Git objects depends entirely on SHA-1 being cryptographically secure because Git signs the commit hash, and the BitKeeper attack against Linux's source tree only failed because the attack was done so poorly they didn't try to find a collision in the commit ID hash function). Better to be safe than sorry.
  - _jjkk 6y ago
    I agree SHA-1 is a poor choice for signing git objects, for reasons that should have been obvious when it was implemented. Unfortunately I don't think the same developers who are assuming all hashes have some kind of magic security properties, are the ones who would follow your best practice for default choice of hash functions. Also I wish some of those higher throughput hashes were available in e.g. python's hashlib by default. For applications that can include minimal or no external packages, hashlib.sha1 still turns out to be the best choice in certain cases.
ReactiveJelly 6y ago
Someone in my company is using MD5 for passwords. This is recent software, like built in the last decade. Passwords were not a mystery to anyone when it was written, at least not anyone who cared about security. I don't know what to say about it. It's not the first time something dumb has happened, and I'm tired of screaming at the brick wall.
- bawolff 6y ago
  Well the reason that md5 is a bad choice for that has nothing to do with collisions or this article. Sha-256 would also be a bad choice for that.
- kzrdude 6y ago
  Depends on how they use it. HMAC-MD5 is not broken, for example. MD5 could potentially be a building block for password hashing still (but it has to be a _building block_)

mehrdadn 6y ago

It's not "strange"... earlier hash algorithms tend to enjoy better performance and compatibility, and there are still use cases for which SHA1 (and even MD5) aren't broken.

bawolff 6y ago
Sha256 has special instructions in silicon for it. Performance is not a reasonable excuse. If performance mattered and you didnt need sha's security properties, you would be using CRC32 or something.
- mehrdadn 6y ago
  Excused or not, I'm merely explaining why this isn't surprising.
cyphar 6y ago
But there are even better choices for non-cryptographic hash functions (FNV and MurmurHash for instance) because they were designed without the need to have a tradeoff between cryptographic security and efficiency.

userbinator 6y ago

Just like security in the physical world, sometimes the weakness is not that great in practice. If you watch enough lockpicking videos on YouTube you may come to the same conclusion. Would I still trust MD5 to be a strong check against random/non-malicious corruption? Yes. Would I trust it against malicious corruption? No.

saagarjha 6y ago
I would, depending on what I was protecting. I use it every day in Git, for example, on projects where integrity is of moderate importance. Now, against a nation-state? No way.
- bawolff 6y ago
  Against nation state, that ship sailed a long time ago. We're currently in the realm of 10-20 thousand dollars to make SHA-1 collisions. That's in the realm of an individual, albeit a reasonably (but not extremely) wealthy one. In 5-10 years it may be in the realm of J. random hacker.
  - entee 6y ago
    Naive question: how often is that collision the same number of bytes as the original?
    - userbinator 6y ago
      I've never seen a colliding pair in a "true" hash function (not just CRC) be of differing lengths. They've always been a pair of blocks with very few differing bits, such that the differences "cancel out" in the computation and the internal state is the same regardless of which of the pair is run through it. I suspect trying to create a colliding pair with differing lengths is much more difficult, since SHA1 also includes the length as part of the calculation.
WrtCdEvrydy 6y ago
In forensics work, MD5 is still used for checksums. It's used for consistency, not uniqueness, so it will likely be usable for years to come.
- eli 6y ago
  Still seems less than ideal to be able to generate a second document that hashes to the same value.

upofadown 6y ago

Well they are not in this particular case. These are old keys.

bawolff 6y ago
The article said they were new keys.

_jjkk 6y ago

You're assuming that all code performing SHA requires a "secure" hash. It's only "broken" for security applications, and there are tons of others for which security is not even a consideration, or where collision is not possible due to input constraints.

bawolff 6y ago
That would have to be some pretty constrained input if you are rulling out collisions in principle
- deleted 6y ago
  [deleted]
cyphar 6y ago
There are hashes which require much less computing power and thus have better throughput if you don't require cryptographic security (examples include FNV-1 and MurmurHash). Using SHA-1 because you "don't need it for security" is still a poor choice. I'd also argue that the default choice of hash function should always be a secure one until a strong counterargument is given, because it turns out that at some point most developers assume hashes have some minimal security properties (Linus always claimed that the choice of hash function in Git was not about cryptographic security -- and yet the security of the GPG signing of Git objects depends entirely on SHA-1 being cryptographically secure because Git signs the commit hash, and the BitKeeper attack against Linux's source tree only failed because the attack was done so poorly they didn't try to find a collision in the commit ID hash function). Better to be safe than sorry.
- _jjkk 6y ago
  I agree SHA-1 is a poor choice for signing git objects, for reasons that should have been obvious when it was implemented. Unfortunately I don't think the same developers who are assuming all hashes have some kind of magic security properties, are the ones who would follow your best practice for default choice of hash functions. Also I wish some of those higher throughput hashes were available in e.g. python's hashlib by default. For applications that can include minimal or no external packages, hashlib.sha1 still turns out to be the best choice in certain cases.

ReactiveJelly 6y ago

Someone in my company is using MD5 for passwords. This is recent software, like built in the last decade. Passwords were not a mystery to anyone when it was written, at least not anyone who cared about security. I don't know what to say about it. It's not the first time something dumb has happened, and I'm tired of screaming at the brick wall.

bawolff 6y ago
Well the reason that md5 is a bad choice for that has nothing to do with collisions or this article. Sha-256 would also be a bad choice for that.
kzrdude 6y ago
Depends on how they use it. HMAC-MD5 is not broken, for example. MD5 could potentially be a building block for password hashing still (but it has to be a _building block_)