‹ BackHN Continuity

Thread

Git 3.0's upcoming SHA-256 default will be a costly mistake

570 points · 536 comments · chmaynard

  1. r3trohack3r · · focus · HN ↗
    > We can go through years of this SHA-1 to SHA-256 migration and then quantum computers break 256 and we're back in the same stupid boat again.

    SHA-256 is considered quantum safe by the NIST and is left out of PQC migration guidance entirely.

    1. TheRealPomax · · focus · HN ↗
      For now. Turns out the pigeon hole principle still holds.
      1. AndrewDucker · · focus · HN ↗
        1x10^77 is a lot of pigeon holes.
        1. TheRealPomax · · focus · HN ↗
          Yep. So was 1.46 x 10^48
    2. ghusto · · focus · HN ↗
      Until it isn't.

      Things like this have a tendency to to be revised as time passes.

    3. schacon · · focus · HN ↗
      It was theoretical - the point was that maybe some paper is published or some new tech or issue comes up. Now we have to do this again. If we separate the concerns, then we don't have to deal with both as though they're one problem. We can deal with one thing for content addressing and another for trust and security.
      1. r3trohack3r · · focus · HN ↗
        Heard. If we’re going through this pain of a migration- adopting something that is forward compatible at the ecosystem/community level like ipfs makes sense to me. You throw a byte at the front of the hash which indicates the format the hash is in.

        We have a content addressable storage system internally and we use a self describing hash for it, so we can change the hashing scheme for different use cases.

        Multihash is ipfs’ container for this.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.