Maybe not, unlike frozen objects (certificates, etc), trees are supposed to extend
Then you can perform progressive hash operations on the objects, ie instead of hashing the intermediate hash of the objects you do it continuously (ie instead of hashing the hash of hash file a + hash file b + hash file c, wait for file d and then do the same, instead hash(file a + file b + file c), when d comes compute the hash of (file a + file b + file c + file d), which implies each time to keep the intermediary hash state because you are not going to recompute everything from the beginning)
I have not worked on this since some time, so that's just
thoughts, but maybe it can render things much more difficult than
computing two files until the same hash is found
The only living example I know implementing this is the Tor
protocol, fact apparently unknown, this is probably why nobody
cares and nobody is willing to take it into account (please follow
bwd/fwd [1] and see [2]), this is not existing in any crypto
implementations, unless you hack into it, and this applies to
progressive encryption too
[1] https://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0018.html
[2] https://github.com/whatwg/streams/issues/33#issuecomment-28554151
On Thu, Feb 23, 2017 at 01:14:09PM -0500, Peter Todd via bitcoin-dev wrote:Worth noting: the impact of the SHA1 collison attack on Git is *not* limited only to maintainers making maliciously colliding Git commits, but also third-party's submitting pull-reqs containing commits, trees, and especially files for which collisions have been found. This is likely to be exploitable in practice with binary files, as reviewers aren't going to necessarily notice garbage at the end of a file needed for the attack; if the attack can be extended to constricted character sets like unicode or ASCII, we're in trouble in general. Concretely, I could prepare a pair of files with the same SHA1 hash, taking into account the header that Git prepends when hashing files. I'd then submit that pull-req to a project with the "clean" version of that file. Once the maintainer merges my pull-req, possibly PGP signing the git commit, I then take that signature and distribute the same repo, but with the "clean" version replaced by the malicious version of the file.Thinking about this a bit more, the most concerning avenue of attack is likely to be tree objects, as I'll bet you you can construct tree objs with garbage at the end that many review tools don't pick up on. :(
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-- Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms