21–30 of 75 posts
Earlier quoted context omitted.
Also, SHA-2 underpins Bitcoin; it's the ultimate billion dollar pot of gold. SHA-2 is perhaps the most exhaustively researched (both publicly and privately) cryptographic hash because of this.
deleted
Their attacks are based on previous chosen-prefix work from Marc Stevens, who tweeted this about the attack [1]: "Their $100K figure is based on as-of-yet undisclosed improvements. History shows many claims of low-cost SHA-1 attacks that have not stood up to peer review. I am very sceptical that their attack costs in total less than the $110K building block (SHAttered) that they use." [1]: https://twitter.com/realhas…
Marc Stevens quotes $500K, which is very much still a threat (even an order of magnitude more would be). Plenty of organizations would be willing to spend that much pocket change on a single attack. The game-changer is it's chosen-prefix. A vendor can produce a pair of entirely different binaries with the same hash, but most importantly, they look and behave sane except for the last few blocks of the file. This is ea…
Regardless, it's switching to SHA-256: https://stackoverflow.com/questions/28159071/why-doesnt-git-...
Earlier quoted context omitted.
Marc Stevens quotes $500K, which is very much still a threat (even an order of magnitude more would be). Plenty of organizations would be willing to spend that much pocket change on a single attack. The game-changer is it's chosen-prefix. A vendor can produce a pair of entirely different binaries with the same hash, but most importantly, they look and behave sane except for the last few blocks of the file. This is ea…
Git isn't really designed for cryptographic security, is it? I have heard that Linus wants it mostly secure so people can verify the integrity of linux source code, but it's not its core competency, so to speak. Though I suppose a project the size of the linux kernel could be a serious target for a collision attack. Regardless, it's switching to SHA-256: https://stackoverflow.com/questions/28159071/why-doesnt-git-...
When you're signing a commit (or a tag) you're just signing the commit (or tag) message which includes the SHA-1 hash of the relevant "root" tree object (or commit object). The tree object, in turn is (in effect) a list of SHA-1 hashes of the files directly in the directory, along with their file sizes and permissions, plus the hashes of the tree objects corresponding to any subdirectories.
Consequently, if you replaced a file with another having the same SHA-1 hash (and the same file size — a considerable complication), all the hashes would remain the same and the signature would still be valid.
Obviously, once git transitions to SHA-256, the problem will disappear.
Last night I was pondering about future "compression" schemes that relied on hyper-powerful quantum computers that can resolve hash collisions very, very quickly, so that rather than literally compressing the data, you'd just share a hash and then this hyper-powerful computer will enumerate possible strings of data that give that hash, and then check them against some secondary condition (another hash?) to find the r…
IIRC the best quantum attack against SHA256 clocked in at about 2^85 cost. It's still not practical for most modern hash functions.
Earlier quoted context omitted.
IIRC the best quantum attack against SHA256 clocked in at about 2^85 cost. It's still not practical for most modern hash functions.
2^85 is for finding a collision; finding a preimage of a specific hash would take 2^128 steps of Grover's algorithm. That's thought to be beyond any possible future computer system.
So perhaps, the easiest way to defend against a collision attack is to transmit the size of the data alongside the checksum. Like a checksum, it is extremely lightweight and easy to check.
In my data framework project (where I use sha1 to identify blocks), I've been looking for an excuse to do this, because knowing size of a block is incredibly useful for applying performance heuristics. I suspect it is also a significant defense against collision attacks. Am I wrong?
Earlier quoted context omitted.
The problem is that is a huge number of strings that becomes a hash. Each SHA-256 hash has 2^(8 * 1024 - 256) = 10^2389 possible 1KB inputs. So...perhaps it could be done, but the quantum computer would have programmed with a very good selection criteria.
No, there is no way this could be done, because there is no way to know which of multiple colliding inputs was the right one. Imagine a one-bit hash function. You start your “decompression” process and read in a 0. What input produced that bit? Literally fifty percent of all possible strings would produce that same output. Without more information, you cannot choose between them. And the information needed to choose…
The way compression algorithms get around that, is by abusing the fact that we rarely want to send around arbitrary data, real world data has lots of redundancy in it, so we can make algorithms where real world data gets mapped into compressed files smaller then they are (by finding the redundancies in the data), and purely random data gets mapped into files that are actually slightly longer than the data.
Earlier quoted context omitted.
Git isn't really designed for cryptographic security, is it? I have heard that Linus wants it mostly secure so people can verify the integrity of linux source code, but it's not its core competency, so to speak. Though I suppose a project the size of the linux kernel could be a serious target for a collision attack. Regardless, it's switching to SHA-256: https://stackoverflow.com/questions/28159071/why-doesnt-git-...
Git signatures are designed for cryptographic security, and they (currently) rely on the SHA-1 hashes. When you're signing a commit (or a tag) you're just signing the commit (or tag) message which includes the SHA-1 hash of the relevant "root" tree object (or commit object). The tree object, in turn is (in effect) a list of SHA-1 hashes of the files directly in the directory, along with their file sizes and permissio…
There's a complication with the few appended trailing blocks being invalid data, but the format might allow it, and git doesn't verify its integrity recursively.
You know, SHA-512/256 was a terrible name. For someone who’s not a cryptographer, it’s way too easy to confuse the single algorithm SHA-512/256, which resists length extension attacks, with the pair of algorithms SHA-512 / SHA-256, which do not.
Can collision attacks provide the same size of data? I suspect it would be dramatically more difficult to produce a collision of equal data-size as the original. So perhaps, the easiest way to defend against a collision attack is to transmit the size of the data alongside the checksum. Like a checksum, it is extremely lightweight and easy to check. In my data framework project (where I use sha1 to identify blocks), I…