91–100 of 240 posts
I was interested in how fossil handled the SHA1 transition, and found this nicely explained as below: https://fossil-scm.org/home/doc/trunk/www/hashpolicy.wiki
Then it also has a similar looking-ish migration to SHA3-256.
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…
You can't change past commits to add that hash (without changing all commit hashes), so this method could only protect new commits. For any existing repo this would lead to a very weird security model: We admit that sha1 hashes are broken, and only guarantee that commits made by git versions newer than git x.x.x are safe from after-the-fact modification (or alternatively only commits made after date X).
I didn't get the argument against just converting? Sure some code bases are large and spread out, but any git repo needs to have one blessed central point, and everyone needs to be able to just re-clone from the central repository whenever history is rewritten for whatever reason (could be that a huge file is trimmed from the past etc). Why can't all commits in the Kernel history be rewritten to SHA256? (Other than t…
The Git team made the right choice: SHA2-256 is the best choice here; it has been around for 19 years and is still secure, in the sense that there are no known attacks against it.
Both BLAKE[2/3] and SHA-3 (Keccak) have been around for 12 years and are both secure; just as BLAKE2 and BLAKE3 are faster reduced round variants of BLAKE, Keccak/SHA-3 has the official faster reduced round Kangaroo12 and Marsupilami14 variants.
BLAKE is faster when using software to perform the hash; Keccak is faster when using hardware to perform the hash. I prefer the Keccak approach because it gives us more room for improved performance once CPU makers create specialized instructions to run it, while being fast enough in software. And, yes, SHA-3 has the advantage of being the official successor to SHA-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…
There is one for hashes: http://valerieaurora.org/hash.html
https://electriccoin.co/blog/lessons-from-the-history-of-att...
I didn't get the argument against just converting? Sure some code bases are large and spread out, but any git repo needs to have one blessed central point, and everyone needs to be able to just re-clone from the central repository whenever history is rewritten for whatever reason (could be that a huge file is trimmed from the past etc). Why can't all commits in the Kernel history be rewritten to SHA256? (Other than t…
The kernel doesn't really have the one central blessed point of which you speak. Sure you can grab mainline releases from Linus's repository, but that's not where the development actually happens. It really is a distributed project, and having to delete all those old repositories would really hurt.
I was interested in how fossil handled the SHA1 transition, and found this nicely explained as below: https://fossil-scm.org/home/doc/trunk/www/hashpolicy.wiki
Ah, so it uses "Hardened SHA1", which detects if you are trying to exploit SHA1, and then produces a longer, unambiguous hash. But otherwise Hardened SHA1 has the same output as SHA1, so it's a drop in replacement. Then it also has a similar looking-ish migration to SHA3-256.