Live data from Hacker News

A new hash algorithm for Git

lwn.net

1–10 of 240 posts

Re: A new hash algorithm for Git

#2
Is there an archive of crypto related future predictions?

How long until a specified length preimage attack can break bittorrent blocks?

I remember a paper published a ~decade ago estimating very short (well funded) ASIC sha1 collisons. Anyone have that ref?

EDIT: Should I have not said preimage? My understanding is bittorrent is broken (by DDoS, not infohash(?)) if you can make a bad block that matches the length and sha1 of a target block.

Re: A new hash algorithm for Git

#4
post #2

Is there an archive of crypto related future predictions? How long until a specified length preimage attack can break bittorrent blocks? I remember a paper published a ~decade ago estimating very short (well funded) ASIC sha1 collisons. Anyone have that ref? EDIT: Should I have not said preimage? My understanding is bittorrent is broken (by DDoS, not infohash(?)) if you can make a bad block that matches the length an…

> How long until a specified length preimage attack can break bittorrent blocks?

Even MD5 still doesn't have a known preimage attack, so... many many years?

Re: A new hash algorithm for Git

#5
I can't find documentation for the command in the article:

    git convert-repo --to-hash=sha-256 --frobnicate-blobs --climb-subtrees \
    --liability-waiver=none --use-shovels --carbon-offsets
Surely some of those options aren't real...

Re: A new hash algorithm for Git

#6
> Thus, unlike some other source-code management systems, Git does not (conceptually, at least) record "deltas" from one revision to the next. It thus forms a sort of blockchain, with each block containing the state of the repository at a given commit.

Color me surprised, dropping the "blockchain" word in the middle of the introduction

Re: A new hash algorithm for Git

#7

does anyone know if github/bitbucket support it today ?

Why would they support it? The article clearly states it is nowhere close to being useful yet.

It is untested, unstable code that can only write to repositories and not read them.

"Much of the work to implement the SHA‑256 transition has been done, but it remains in a relatively unstable state and most of it is not even being actively tested yet. In mid-January, carlson posted the first part of this transition code, which clearly only solves part of the problem:

"First, it contains the pieces necessary to set up repositories and write _but not read_ extensions.objectFormat. In other words, you can create a SHA‑256 repository, but will be unable to read it. "

Re: A new hash algorithm for Git

#8

I can't find documentation for the command in the article: git convert-repo --to-hash=sha-256 --frobnicate-blobs --climb-subtrees \ --liability-waiver=none --use-shovels --carbon-offsets Surely some of those options aren't real...

> A new version of Git can be made…with a simple command like: … note that the specific command-line options may differ

Gives me the impression that it’s a construction of the article alone. Unsurprising, given the snark of the options.

Re: A new hash algorithm for Git

#9
I don't understand the practical attack vector for breaking SHA1s in Git. Not only are objects checksummed by SHA1, they also encode the length. Finding a SHA1 collision is plausible, but finding a SHA1 collision that both lets you do something Nefarious, and is the length you need, seems really really unlikely

Re: A new hash algorithm for Git

#10

I can't find documentation for the command in the article: git convert-repo --to-hash=sha-256 --frobnicate-blobs --climb-subtrees \ --liability-waiver=none --use-shovels --carbon-offsets Surely some of those options aren't real...

Of course they are ?!?!!? https://git-man-page-generator.lokaltog.net/

(never fails to amuse me)

Post reply on HN