6 ms·

The Git project selects SHA-256 as the next-gen hash function to migrate to

133 points by avar 8y ago

dev_dull 8y ago
From the email discussion: > to support SHA-256, we would simply use the system's crypto libraries ... I think this is probably the single strongest argument for sha256. "It's just there". Sounds reasonable and well... boring. Just the kind of technical decisions I like
- arusahni 8y ago
  > dev_dull Checks out. :)
- slavik81 8y ago
  What was the case against SHA-512/256? It's the same size as SHA-256, is faster on 64-bit hardware, and is often more difficult to attack. It's just a truncated SHA-512 hash, which is widely supported. The only drawback I know of is that it's slower than SHA-256 on 32-bit hardware. edit: I found the email where they compared 256-bit hash functions [1]. It seems Apple Common Crypto, gcrypt and NSS don't implement SHA-512. A new twist to the performance story is that OpenSSL's SHA-256 is faster than SHA-512/256 in the AMD Ryzen tests, possibly due to the recent introduction of hardware support. [1]: https://public-inbox.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/ https://public-inbox.org/git/20180609224913.GC38834@genre.cr...
  - wvh 8y ago
    Well, sha512 with different initialisation vectors. Even OpenSSL doesn't support sha512_256 yet, but it's coming in the next major release.
    - slavik81 8y ago
      Thanks. I hadn't realized it started with a different initial value. That small difference really cuts down on availability of implementations.
- BjoernKW 8y ago
  Absolutely. "Use boring solutions" has become a bit of a mantra for me. Only build something yourself if it serves as a key differentiator or has the potential to do so. Otherwise, use off-the-shelf tools.
dang 8y ago
Url changed from https://git.github.io/rev_news/2018/08/22/edition-42/ https://git.github.io/rev_news/2018/08/22/edition-42/, which points to this.
elpakal 8y ago
Can someone explain why the change?
- eldridgea 8y ago
  I believe this was in response to the SHAttered[0] attack which was a demonstrated SHA-1 collision [0] https://shattered.io/ https://shattered.io/
  - shakna 8y ago
    Git uses a hardened SHA-1, not vulnerable to SHAttered, since v2.13.0 [0] But the fear of more attacks helped transition the move. [0] https://blog.github.com/2017-05-10-git-2-13-has-been-released/ https://blog.github.com/2017-05-10-git-2-13-has-been-release...
- shakna 8y ago
  The Background section of this [0] document explains it. In short, git migrated to a hardened SHA-1 hash after the SHAttered [1] attack became known. However, in the future more attacks against SHA-1 may be found, so git is trying to future-proof itself. However, even in the case a hash function is no longer cryptographically secure, git doesn't lose out completely, just losing signing and shorthand fetches over the git protocol. This project focuses on git with SHA256 and SHA-1 interchangeability, but doesn't address the git protocol side of things yet, which can come later. [0] https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt https://github.com/git/git/blob/master/Documentation/technic... [1] https://shattered.io/ https://shattered.io/
  - elpakal 8y ago
    Wow, great source. Thanks!
  - p-squared 8y ago
    "Hardened SHA-1 hash" is a confusing way to characterize git's current hash behavior. There is no change in the hash--it continues to be SHA-1. The change is in git's business logic: it will detect hash inputs that look like a SHA-1 collision attack, and will refuse to proceed.
phyzome 8y ago
Anyone know how the migration is intended to work? I'm guessing that git's storage model includes a table of SHA-1 hashes to object files/locations, and it will just need another lookup table... and then what? Maybe a fallback to SHA-1 hash to verify objects in older repos?
- avar 8y ago
  It's explained here: https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt https://github.com/git/git/blob/master/Documentation/technic...
  - craftyguy 8y ago
    Unless I missed it, it doesn't seem to address the usage of shortened sha1 hashes. It seems like sha1 hashes will stay in the repo, so how does it know if 'abcd12345' is sha1 or sha256?
    - shakna 8y ago
      I believe the SHA-1 hashes get 'translated' into SHA-256. [0] So though SHA-1 references stay in the repo, the preference is for SHA-256 hashes. But, an edge-case like this may not get a full explanation until implementation. They go into it a bit more here. [1] Where what they mean may change depending on the transition timeline. To begin with, prefer SHA-1, but convert internally to SHA256. Output names to users in SHA-1 still. Only late in the transition begin to use the SHA256 names. However, the mode of operation can be changed by your git config. [0] https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt#L289 https://github.com/git/git/blob/master/Documentation/technic... [1] https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt#L567 https://github.com/git/git/blob/master/Documentation/technic...
alexandernst 8y ago
Impossible! That doesn’t fit in 80 columns!
- LeoPanthera 8y ago
  It does if you represent it in base64
modells 8y ago
I'm sure others already asked: "y u no sha3?" on the git dev lists. Assuming quantum computers with many qubits land, aren't prime factorization, EC and matrix math crypto basically DOA?
- rurban 8y ago
  That's answered by one of the cryptologers. With quantum bitsizes need to double, i.e from 256 to 512. Which will be the next stage in 10-15 years. Enough time, not DOA. They just factored RSA-230, which was labelled to need 17 core years. https://news.ycombinator.com/item?id=17825383 https://news.ycombinator.com/item?id=17825383

133 points by avar 8y ago

From the email discussion: > to support SHA-256, we would simply use the system's crypto libraries ... I think this is probably the single strongest argument for sha256. "It's just there". Sounds reasonable and well... boring. Just the kind of technical decisions I like

arusahni 8y ago
> dev_dull Checks out. :)
slavik81 8y ago
What was the case against SHA-512/256? It's the same size as SHA-256, is faster on 64-bit hardware, and is often more difficult to attack. It's just a truncated SHA-512 hash, which is widely supported. The only drawback I know of is that it's slower than SHA-256 on 32-bit hardware. edit: I found the email where they compared 256-bit hash functions [1]. It seems Apple Common Crypto, gcrypt and NSS don't implement SHA-512. A new twist to the performance story is that OpenSSL's SHA-256 is faster than SHA-512/256 in the AMD Ryzen tests, possibly due to the recent introduction of hardware support. [1]: https://public-inbox.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/ https://public-inbox.org/git/20180609224913.GC38834@genre.cr...
- wvh 8y ago
  Well, sha512 with different initialisation vectors. Even OpenSSL doesn't support sha512_256 yet, but it's coming in the next major release.
  - slavik81 8y ago
    Thanks. I hadn't realized it started with a different initial value. That small difference really cuts down on availability of implementations.
BjoernKW 8y ago
Absolutely. "Use boring solutions" has become a bit of a mantra for me. Only build something yourself if it serves as a key differentiator or has the potential to do so. Otherwise, use off-the-shelf tools.

dang 8y ago

Url changed from https://git.github.io/rev_news/2018/08/22/edition-42/ https://git.github.io/rev_news/2018/08/22/edition-42/, which points to this.

elpakal 8y ago

Can someone explain why the change?

eldridgea 8y ago
I believe this was in response to the SHAttered[0] attack which was a demonstrated SHA-1 collision [0] https://shattered.io/ https://shattered.io/
- shakna 8y ago
  Git uses a hardened SHA-1, not vulnerable to SHAttered, since v2.13.0 [0] But the fear of more attacks helped transition the move. [0] https://blog.github.com/2017-05-10-git-2-13-has-been-released/ https://blog.github.com/2017-05-10-git-2-13-has-been-release...
shakna 8y ago
The Background section of this [0] document explains it. In short, git migrated to a hardened SHA-1 hash after the SHAttered [1] attack became known. However, in the future more attacks against SHA-1 may be found, so git is trying to future-proof itself. However, even in the case a hash function is no longer cryptographically secure, git doesn't lose out completely, just losing signing and shorthand fetches over the git protocol. This project focuses on git with SHA256 and SHA-1 interchangeability, but doesn't address the git protocol side of things yet, which can come later. [0] https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt https://github.com/git/git/blob/master/Documentation/technic... [1] https://shattered.io/ https://shattered.io/
- elpakal 8y ago
  Wow, great source. Thanks!
- p-squared 8y ago
  "Hardened SHA-1 hash" is a confusing way to characterize git's current hash behavior. There is no change in the hash--it continues to be SHA-1. The change is in git's business logic: it will detect hash inputs that look like a SHA-1 collision attack, and will refuse to proceed.

phyzome 8y ago

Anyone know how the migration is intended to work? I'm guessing that git's storage model includes a table of SHA-1 hashes to object files/locations, and it will just need another lookup table... and then what? Maybe a fallback to SHA-1 hash to verify objects in older repos?

avar 8y ago
It's explained here: https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt https://github.com/git/git/blob/master/Documentation/technic...
- craftyguy 8y ago
  Unless I missed it, it doesn't seem to address the usage of shortened sha1 hashes. It seems like sha1 hashes will stay in the repo, so how does it know if 'abcd12345' is sha1 or sha256?
  - shakna 8y ago
    I believe the SHA-1 hashes get 'translated' into SHA-256. [0] So though SHA-1 references stay in the repo, the preference is for SHA-256 hashes. But, an edge-case like this may not get a full explanation until implementation. They go into it a bit more here. [1] Where what they mean may change depending on the transition timeline. To begin with, prefer SHA-1, but convert internally to SHA256. Output names to users in SHA-1 still. Only late in the transition begin to use the SHA256 names. However, the mode of operation can be changed by your git config. [0] https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt#L289 https://github.com/git/git/blob/master/Documentation/technic... [1] https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt#L567 https://github.com/git/git/blob/master/Documentation/technic...

alexandernst 8y ago

Impossible! That doesn’t fit in 80 columns!

LeoPanthera 8y ago
It does if you represent it in base64

modells 8y ago

I'm sure others already asked: "y u no sha3?" on the git dev lists. Assuming quantum computers with many qubits land, aren't prime factorization, EC and matrix math crypto basically DOA?

rurban 8y ago
That's answered by one of the cryptologers. With quantum bitsizes need to double, i.e from 256 to 512. Which will be the next stage in 10-15 years. Enough time, not DOA. They just factored RSA-230, which was labelled to need 17 core years. https://news.ycombinator.com/item?id=17825383 https://news.ycombinator.com/item?id=17825383