The Git project selects SHA-256 as the next-gen hash function to migrate to | Hacker News Reader

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

public-inbox.org

133 pointsavar22 comments

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

> dev_dull

Checks out. :)

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

Well, sha512 with different initialisation vectors. Even OpenSSL doesn't support sha512_256 yet, but it's coming in the next major release.

Thanks. I hadn't realized it started with a different initial value. That small difference really cuts down on availability of implementations.

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.

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?

It's explained here: https://github.com/git/git/blob/master/Documentation/technic...

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?

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

[1] https://github.com/git/git/blob/master/Documentation/technic...

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?

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

Impossible! That doesn’t fit in 80 columns!

It does if you represent it in base64

Can someone explain why the change?

I believe this was in response to the SHAttered[0] attack which was a demonstrated SHA-1 collision

[0] https://shattered.io/

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

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

[1] https://shattered.io/

Wow, great source. Thanks!

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

The SHA1DC algorithm implements a different hash function, since it doesn't return the same hash as SHA-1 for all inputs, those inputs just happen to be really rare.

This is SHA-1:

    hash = SHA1(input)

This is SHA-1DC in "only detect collision mode":

    collided, hash = SHA1DC(input)

Where "hash" for SHA1DC(input) will be the same value as SHA1(input), then there's the mode to work around such collisions:

    hash = SHA1DC_safe(input)

In this case "hash" will be the same as SHA1(input) in all cases, except those where the input is detected to be malicious (as in the SHAttered attack). Then SHA1DC_safe(input) will return a different ("safe") hash than SHA1(input) would.

So depending on the mode you use it in it's a different hash function than SHA-1. The Git project only uses it in the "detect a collision and die" mode: https://github.com/git/git/blob/master/sha1dc_git.c#L17-L23

Here's the part of the code where you can see it's implementing a different hash function: https://github.com/git/git/blob/v2.19.0-rc0/sha1dc/sha1.c#L1...

I.e. if detect_coll and safe_hash are set, it will return different hashes than SHA1() for the same input.

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

Reply on news.ycombinator.com