rich1.0npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grzhttps://nostr.ae/npub15fc36esk6dy2x4ptk2ner209rl9u0d736gr99edtu9knu9uny80s4g5grznjumphttps://nostr.ae📅 Original date posted:2017-02-24 📝 Original message:??? apparently we are not discussing the same thing Maybe I did not provide the right links (reading them again I myself don't find them so clear), see maybe again https://github.com/whatwg/streams/issues/33#issuecomment-28045860 a - b - c -d hash(a) hash(a+b) etc But you are not going to rehash from the beginning, then: update a --> keep the remaining bytes a_ (+ hash state 1) --> digest a=hash(a) update a_+b from hash state 1--> keep the remaining bytes b_ (+ hash state 2) --> digest a_+b=hash(a+b) etc Basically that's similar to a real time progressive hash of chunks of a file that you are streaming and therefore don't know what will come next (per opposition to hashing a file that you already have), this could apply to trees This is different from something like: hash(a) hash(hash(a) +hash(b)) etc There is no initial state, and the attacker can't modify what was already hashed, to make it more difficult you can probably modify the hash state N Le 24/02/2017 à 17:30, Tim Ruffing via bitcoin-dev a écrit : > On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote: >> 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 > What prevents the attacker to provide different past files when talking > to parties who are still in the initial state? > > 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? > With the original usage of the hash function, the hash state is always > the initial state. Now that the attacker has some control over the hash > state even. In other words, if the original use of the hash function > was vulnerable, then your scheme is vulnerable for the initial state. > > Concrete attack: If you can find x != y with H(x) = H(y), then you can > also find m, x != y, with H(m||x) = H(m||y), just by setting m = "". > > Not sure if this is the right place to discuss that issue though... > > 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