{"type":"rich","version":"1.0","author_name":"npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz","author_url":"https://nostr.ae/npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grz","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-02-23\n📝 Original message:Maybe not, unlike frozen objects (certificates, etc), trees are supposed\nto extend\n\nThen you can perform progressive hash operations on the objects, ie\ninstead of hashing the intermediate hash of the objects you do it\ncontinuously (ie instead of hashing the hash of hash file a + hash file\nb + hash file c, wait for file d and then do the same, instead hash(file\na + file b + file c), when d comes compute the hash of (file a + file b\n+ file c + file d), which implies each time to keep the intermediary\nhash state because you are not going to recompute everything from the\nbeginning)\n\nI have not worked on this since some time, so that's just thoughts, but\nmaybe it can render things much more difficult than computing two files\nuntil the same hash is found\n\nThe only living example I know implementing this is the Tor protocol,\nfact apparently unknown, this is probably why nobody cares and nobody is\nwilling to take it into account (please follow bwd/fwd [1] and see [2]),\nthis is not existing in any crypto implementations, unless you hack into\nit, and this applies to progressive encryption too\n\n[1]\nhttps://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Feb/0018.html\n\n\n[2] https://github.com/whatwg/streams/issues/33#issuecomment-28554151\n\n\nLe 23/02/2017 à 22:28, Peter Todd via bitcoin-dev a écrit :\n\u003e On Thu, Feb 23, 2017 at 01:14:09PM -0500, Peter Todd via bitcoin-dev wrote:\n\u003e\u003e Worth noting: the impact of the SHA1 collison attack on Git is *not* limited\n\u003e\u003e only to maintainers making maliciously colliding Git commits, but also\n\u003e\u003e third-party's submitting pull-reqs containing commits, trees, and especially\n\u003e\u003e files for which collisions have been found. This is likely to be exploitable in\n\u003e\u003e practice with binary files, as reviewers aren't going to necessarily notice\n\u003e\u003e garbage at the end of a file needed for the attack; if the attack can be\n\u003e\u003e extended to constricted character sets like unicode or ASCII, we're in trouble\n\u003e\u003e in general.\n\u003e\u003e\n\u003e\u003e Concretely, I could prepare a pair of files with the same SHA1 hash, taking\n\u003e\u003e into account the header that Git prepends when hashing files. I'd then submit\n\u003e\u003e that pull-req to a project with the \"clean\" version of that file. Once the\n\u003e\u003e maintainer merges my pull-req, possibly PGP signing the git commit, I then take\n\u003e\u003e that signature and distribute the same repo, but with the \"clean\" version\n\u003e\u003e replaced by the malicious version of the file.\n\u003e Thinking about this a bit more, the most concerning avenue of attack is likely\n\u003e to be tree objects, as I'll bet you you can construct tree objs with garbage at\n\u003e the end that many review tools don't pick up on. :(\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nZcash wallets made simple: https://github.com/Ayms/zcash-wallets\nBitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets\nGet the torrent dynamic blocklist: http://peersm.com/getblocklist\nCheck the 10 M passwords list: http://peersm.com/findmyass\nAnti-spies and private torrents, dynamic blocklist: http://torrent-live.org\nPeersm : http://www.peersm.com\ntorrent-live: https://github.com/Ayms/torrent-live\nnode-Tor : https://www.github.com/Ayms/node-Tor\nGitHub : https://www.github.com/Ayms\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170224/7bfa2399/attachment.html\u003e"}