Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new hash algorithm for Git

lwn.net

Post reply on HN
Print view View original

71–80 of 240 posts

Re: A new hash algorithm for Git

#71

Post by donatj »

Excuse my ignorance, but couldn’t they just add a SHA256 hash to commit objects (or some new commit-verify object) of the entire trees current concatenated content, leave everything else SHA1 and get the same benefit without rewriting the entire thing from the ground up? Git could even do that as part of the git gc step slowly over time - tag commits with a secondary hash.

Rewriting the whole thing including every git repos history seems like throwing the baby out with the bathwater, when you could just add a secondary transparent verification instead. Just seems like there has to be a better way.

Re: A new hash algorithm for Git

#72

Post by kzrdude »

donatj wrote: post #71

Excuse my ignorance, but couldn’t they just add a SHA256 hash to commit objects (or some new commit-verify object) of the entire trees current concatenated content, leave everything else SHA1 and get the same benefit without rewriting the entire thing from the ground up? Git could even do that as part of the git gc step slowly over time - tag commits with a secondary hash. Rewriting the whole thing including every gi…

Hashing everything in one go doesn't scale well. When making a new commit you want to only hash a proportional part of the repository, and the tree structure of git allows that, only the files and "tree" objects (directory listings) that change are hashed again.

Re: A new hash algorithm for Git

#75

Post by bawolff »

bangboombang wrote: post #32
dchest wrote: post #25

Earlier quoted context omitted.

Something to remember about the security of concatenated hashes: https://crypto.stackexchange.com/a/63543/291

This is pretty interesting and shows you shouldn't try to pull any sort of stunts if you're not a crypto expert. I've actually wondered before whether md5 + sha1 would result in something stronger than those two used individually. Now I know.

The linked article doesnt contradict the original post. Linked article says strength of 2 hash algos (of this type) is only as strong as the strongest and not the sum of their strengths. But original poster only needed the combined hash to be as strong as the sha256 for his/her purpose.

Notwithstanding, i still dont like it as an idea.

Re: A new hash algorithm for Git

#76

Post by bawolff »

afiori wrote: post #47
AndrewDucker wrote: post #17

Earlier quoted context omitted.

Git is a blockchain. Being, as it is, a chain of signed blocks.

It is still a sort of namedropping. In the sense that it is used due to the trendiness of the term. It is entirely possible and likely that it is used for didactic purposes as many people are familiar with the blockchain structure and its use of hashes.

I thought it was a joke. The whole: blockchain isnt that inovative if you use a strict technical definition because lots of things are a chain of blocks before bitcoin was cool, meme.

And honestly fair enough. The inovative part of bitcoin is not the blockchain but all the economics & game theory going on to create trust in the system

Re: A new hash algorithm for Git

#77

Post by hrgiger »

buserror wrote: post #10
tcharlton wrote: post #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...

Of course they are ?!?!!? https://git-man-page-generator.lokaltog.net/ (never fails to amuse me)

reminds me https://projects.haykranen.nl/java/

Re: A new hash algorithm for Git

#78

Post by kzrdude »

anaisbetts wrote: post #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

SHA1 is crumbling. It's being replaced because it is likely to be broken further, in practice.

Re: A new hash algorithm for Git

#79

Post by afiori »

bawolff wrote: post #76
afiori wrote: post #47

Earlier quoted context omitted.

It is still a sort of namedropping. In the sense that it is used due to the trendiness of the term. It is entirely possible and likely that it is used for didactic purposes as many people are familiar with the blockchain structure and its use of hashes.

I thought it was a joke. The whole: blockchain isnt that inovative if you use a strict technical definition because lots of things are a chain of blocks before bitcoin was cool, meme. And honestly fair enough. The inovative part of bitcoin is not the blockchain but all the economics & game theory going on to create trust in the system

I think this is the reason why it the parent was criticizing it. Blockchain as a term generally mean "crypto-magic-stuff on a blockchain" so for git to use it instead of a more academical Merkel trees (or Merkel DAG if they exist) sound a bit like low effort name dropping.

Again it is not a criticism of the article, but it is not a criticism of the criticism either.

Re: A new hash algorithm for Git

#80

Post by SAI_Peregrinus »

tialaramex wrote: post #61
jakeogh wrote: 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…

> 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. There are three different attacks 1. Collision, which is practical (expensive but practical) for SHA-1 today, lets somebody make two documents A and B which have the same hash. This is only useful if you can fool people somehow int…

1.5 Chosen-prefix collision: Given a prefix A, generate two values AB and AC, where B and C differ but are both prefixed with A. (AX is A concatenated with X). This exists for SHA1. It's more powerful than a basic collision wheri you can't pick the prefix, but weaker than either type of pre-image.
Post reply on HN