
The Git project selects SHA-256 as the next-gen hash function to migrate to - avar
https://public-inbox.org/git/20180725083024.16131-1-avarab@gmail.com/
======
dev_dull
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

~~~
slavik81
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...](https://public-
inbox.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/)

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

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

------
phyzome
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
It's explained here:
[https://github.com/git/git/blob/master/Documentation/technic...](https://github.com/git/git/blob/master/Documentation/technical/hash-
function-transition.txt)

~~~
craftyguy
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
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...](https://github.com/git/git/blob/master/Documentation/technical/hash-
function-transition.txt#L289)

[1]
[https://github.com/git/git/blob/master/Documentation/technic...](https://github.com/git/git/blob/master/Documentation/technical/hash-
function-transition.txt#L567)

------
modells
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
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)

------
alexandernst
Impossible! That doesn’t fit in 80 columns!

~~~
LeoPanthera
It does if you represent it in base64

------
elpakal
Can someone explain why the change?

~~~
shakna
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...](https://github.com/git/git/blob/master/Documentation/technical/hash-
function-transition.txt)

[1] [https://shattered.io/](https://shattered.io/)

~~~
p-squared
"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.

~~~
avar
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](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...](https://github.com/git/git/blob/v2.19.0-rc0/sha1dc/sha1.c#L1728-L1763)

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

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

