4 ms·

Sort of. This is really tricky to achieve with text files (where the padding necessary to make the hashes line up looks completely out of place), but many binar

by pdpi 6y ago

Sort of. This is really tricky to achieve with text files (where the padding necessary to make the hashes line up looks completely out of place), but many binary formats allow arbitrary padding — e.g. zip files have an index at the end. Inversely, png files have a header and ignore meaningless data at the end. Both can be padded with arbitrary data (and, indeed, you can cat a png and a zip together as a janky steganography system)

hnedeotes 6y ago
I have thought about this in regards to Nix but as far as I could conceive, it seemed that: a) you can definitively generate content that will be hashed to the same value - this is a given since anything that compresses a source into a much shorter representation allows that by definition (lets ignore feasibility/time/cost) b) Making a) in a way that the contents are usable for a given purpose, doesn't introduce severe noticeable changes, and plays ball with the remaining stuff (OS, build chains, the context where it's included in, etc) seems to be the actual difficult part So my conclusion was at the time that in terms of feasibility it's probably easier to hack the chain itself replacing the hash. But again, if there's a master "hash" for whatever artefact is produced that relies on all those hashes it would also need to be replaced?
michaelt 6y ago
For text files, tools for brute forcing a git commit hash [1] work by messing with the author and committer timestamps. Of course, that only gives you about 40 bits to play with (assuming the further you move the timestamp, the easier it is to detect) so it wouldn't be completely sufficient on its own. [1] https://github.com/DesWurstes/VanityCommit#alternatives https://github.com/DesWurstes/VanityCommit#alternatives
zie 6y ago
I agree in binary formats, it's easier to accomplish, but it by no means is easy. Thankfully most source code is plain text. There are mostly trivial ways to encode information in whitespace/etc, but again, the ability to carry some useful information AND commit a SHA1 collision is currently non-trivial. Plus Git has specifically put in some hardening for the existing SHA1 hashes to make this even less feasible in the particular application of a git repo. A pipe wrench to the back of the head(or social engineering) of some random committer is probably a LOT easier to accomplish. That said, if your primary nemesis is one the giant nation states(US, China, Russia, Etc) AND you were very high target for them, then all bets are off, as they can pretty much accomplish whatever they want against any individual/small group on the planet. I would imagine most of us are not even remotely in this situation.

by pdpi 6y ago

hnedeotes 6y ago

I have thought about this in regards to Nix but as far as I could conceive, it seemed that: a) you can definitively generate content that will be hashed to the same value - this is a given since anything that compresses a source into a much shorter representation allows that by definition (lets ignore feasibility/time/cost) b) Making a) in a way that the contents are usable for a given purpose, doesn't introduce severe noticeable changes, and plays ball with the remaining stuff (OS, build chains, the context where it's included in, etc) seems to be the actual difficult part So my conclusion was at the time that in terms of feasibility it's probably easier to hack the chain itself replacing the hash. But again, if there's a master "hash" for whatever artefact is produced that relies on all those hashes it would also need to be replaced?

michaelt 6y ago

For text files, tools for brute forcing a git commit hash [1] work by messing with the author and committer timestamps. Of course, that only gives you about 40 bits to play with (assuming the further you move the timestamp, the easier it is to detect) so it wouldn't be completely sufficient on its own. [1] https://github.com/DesWurstes/VanityCommit#alternatives https://github.com/DesWurstes/VanityCommit#alternatives

zie 6y ago

I agree in binary formats, it's easier to accomplish, but it by no means is easy. Thankfully most source code is plain text. There are mostly trivial ways to encode information in whitespace/etc, but again, the ability to carry some useful information AND commit a SHA1 collision is currently non-trivial. Plus Git has specifically put in some hardening for the existing SHA1 hashes to make this even less feasible in the particular application of a git repo. A pipe wrench to the back of the head(or social engineering) of some random committer is probably a LOT easier to accomplish. That said, if your primary nemesis is one the giant nation states(US, China, Russia, Etc) AND you were very high target for them, then all bets are off, as they can pretty much accomplish whatever they want against any individual/small group on the planet. I would imagine most of us are not even remotely in this situation.