Surprising they didn't go with Blake3 instead since it has much higher performance and Git's performance-oriented ethos.
A new hash algorithm for Git
11–20 of 240 posts
Re: A new hash algorithm for Git
#12I 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...
That seems to be intended to be humour.
Re: A new hash algorithm for Git
#13I 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
This makes no sense. The collision manufacture algorithm of course produces the same length output in both the A and B documents. Doing otherwise would be considerably harder in fact.
Re: A new hash algorithm for Git
#14Is 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…
There is one for hashes:
Re: A new hash algorithm for Git
#15Is 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…
Preimage is really a whole different beast than collission.
It's also not particularly surprising. Just by its length SHA-1 has in its best case 80 bits of collission security and 160 bits of preimage security.
Now its important to understand that attacks usually don't cause full devastation, but they usually make attacks a bit better than optimal.
Attacks in the 60 bit range is what's possible, attacks in the 70 bit range is what's dangerous. It's easy to imagine that relatively small deviation from optimal security gets SHA-1 from 80 into the dangerous territorry (the attacks are in the low 60s range). However getting from 160 bit down to the 60/70 bit range would require massive improvements in attacks.
It's safe to say that SHA-1 is still very far from preimage attacks. Still to be clear I'd still recommend to get rid of it whereever you can. The far bigger risk is that you think you only need preimage security, while you actually need collission security for scenarios you haven't thought about.
Re: A new hash algorithm for Git
#16I 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...
I believe we have here an example of Poe's law [1]
Re: A new hash algorithm for Git
#17> 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
Git is a blockchain.
Being, as it is, a chain of signed blocks.
Re: A new hash algorithm for Git
#18Just in case: http://archive.is/omsjJ
Re: A new hash algorithm for Git
#19> 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
Git is a blockchain. Being, as it is, a chain of signed blocks.
Git is a Merkle tree as is a blockchain.
Re: A new hash algorithm for Git
#20Is 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?
To be fair for MD5 there is a known attack, it's just impractical. It's a real attack though because the whole point of a crypto hash is that you'd have to brute force it to win, and the paper shows a slightly quicker way because MD5 is broken. It's just not quick enough that you could actually do it.
Oh wait, perhaps you actually meant preimage as you said rather than I assumed second preimage. OK yes, that isn't ever going to be possible for non-trivial inputs.