{"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-24\n📝 Original message:Not sure that you really read deeply what I sent, because stating that\nhashing files continuously instead of hashing the intermediate steps\njust gives more latitude to the attacker can't be true when the attacker\nhas absolutely no control over the past files\n\nI did not write this as a workaround to fix SHA1, which will be dead\nsoon or later but as maybe some general concept that could possibly help\nwhatever hash function you are using for objects that are not frozen but\nextending (ie the original email stating that trees might be some kind\nof worse candidates for collisions reminded me this), indeed it makes no\nsense to patch SHA1 or play around, but this kind of proposal could\naccompany the defunct\n\nThe drawback is that you have to keep the hash state when you close the\nlatest hash computation in order to start the next one\n\nThen the question is: knowing the hash state, is it as easy to find a\ncollision between two files that will be computed in the next round than\nfinding a collision between two files only?\n\nKnowing that you can probably modify the hash state with some\nunpredictable patterns\n\nMost likely the answer is: no, it's (astronomically?) more difficult\n\nPlease take it as a suggestion that might be explored (ps: I have the\ncode for this if needed) rather than an affirmation, still amazed as\nshown in the few links provided (among others) that each time I raise\nthis subject nobody really pays attention (what's the use case?, etc)\nand by the fact that it's apparently used by only one project in the\nworld and not supported by any library\n\n\nLe 24/02/2017 à 11:04, Tim Ruffing via bitcoin-dev a écrit :\n\u003e On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote:\n\u003e\u003e I have not worked on this since some time, so that's just thoughts,\n\u003e\u003e but maybe it can render things much more difficult\n\u003e\u003e than       computing two files until the same hash is found\n\u003e\u003e\n\u003e You basically rely on the idea that specific collisions are more\n\u003e difficult to find. This trick or similar tricks will not help. (And\n\u003e actually, the more files you add to the hash, the more freedom you give\n\u003e the attacker.)\n\u003e\n\u003e Even if certain collisions are more difficult to find today (which is\n\u003e certainly true), the general rule is that someone will prove you wrong\n\u003e in a year.\n\u003e\n\u003e Even if ignore security entirely, switching to new hash function is\n\u003e much simpler trying to fix the usage of a broken hash function.\n\u003e\n\u003e Relying on SHA1 is hopeless. We have to get rid of it.\n\u003e\n\u003e Best,\n\u003e Tim\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"}