rich1.0npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzhttps://nostr.ae/npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grznjumphttps://nostr.ae📅 Original date posted:2017-02-24 📝 Original message:Not sure that you really read deeply what I sent, because stating that hashing files continuously instead of hashing the intermediate steps just gives more latitude to the attacker can't be true when the attacker has absolutely no control over the past files I did not write this as a workaround to fix SHA1, which will be dead soon or later but as maybe some general concept that could possibly help whatever hash function you are using for objects that are not frozen but extending (ie the original email stating that trees might be some kind of worse candidates for collisions reminded me this), indeed it makes no sense to patch SHA1 or play around, but this kind of proposal could accompany the defunct The drawback is that you have to keep the hash state when you close the latest hash computation in order to start the next one Then the question is: knowing the hash state, is it as easy to find a collision between two files that will be computed in the next round than finding a collision between two files only? Knowing that you can probably modify the hash state with some unpredictable patterns Most likely the answer is: no, it's (astronomically?) more difficult Please take it as a suggestion that might be explored (ps: I have the code for this if needed) rather than an affirmation, still amazed as shown in the few links provided (among others) that each time I raise this subject nobody really pays attention (what's the use case?, etc) and by the fact that it's apparently used by only one project in the world and not supported by any library Le 24/02/2017 à 11:04, Tim Ruffing via bitcoin-dev a écrit : > On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote: >> 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 >> > You basically rely on the idea that specific collisions are more > difficult to find. This trick or similar tricks will not help. (And > actually, the more files you add to the hash, the more freedom you give > the attacker.) > > Even if certain collisions are more difficult to find today (which is > certainly true), the general rule is that someone will prove you wrong > in a year. > > Even if ignore security entirely, switching to new hash function is > much simpler trying to fix the usage of a broken hash function. > > Relying on SHA1 is hopeless. We have to get rid of it. > > Best, > Tim > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at 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