{"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:??? apparently we are not discussing the same thing\n\nMaybe I did not provide the right links (reading them again I myself\ndon't find them so clear), see maybe again\nhttps://github.com/whatwg/streams/issues/33#issuecomment-28045860\n\na - b - c -d\n\nhash(a)\n\nhash(a+b)\n\netc\n\nBut you are not going to rehash from the beginning, then:\n\nupdate a --\u003e keep the remaining bytes a_ (+ hash state 1) --\u003e digest\na=hash(a)\n\nupdate a_+b from hash state 1--\u003e keep the remaining bytes b_ (+ hash\nstate 2) --\u003e digest a_+b=hash(a+b)\n\netc\n\nBasically that's similar to a real time progressive hash of chunks of a\nfile that you are streaming and therefore don't know what will come next\n(per opposition to hashing a file that you already have), this could\napply to trees\n\nThis is different from something like:\n\nhash(a)\n\nhash(hash(a) +hash(b))\n\netc\n\nThere is no initial state, and the attacker can't modify what was\nalready hashed, to make it more difficult you can probably modify the\nhash state N\n\n\nLe 24/02/2017 à 17:30, Tim Ruffing via bitcoin-dev a écrit :\n\u003e On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:\n\u003e\u003e Not sure that you really read deeply what I sent, because stating\n\u003e\u003e that\n\u003e\u003e hashing files continuously instead of hashing the intermediate steps\n\u003e\u003e just gives more latitude to the attacker can't be true when the\n\u003e\u003e attacker\n\u003e\u003e has absolutely no control over the past files\n\u003e What prevents the attacker to provide different past files when talking\n\u003e to parties who are still in the initial state?\n\u003e\n\u003e Then the question is: knowing the hash state, is it as easy to find a\n\u003e\u003e collision between two files that will be computed in the next round\n\u003e\u003e than\n\u003e\u003e finding a collision between two files only?\n\u003e With the original usage of the hash function, the hash state is always\n\u003e the initial state. Now that the attacker has some control over the hash\n\u003e state even. In other words, if the original use of the hash function\n\u003e was vulnerable, then your scheme is vulnerable for the initial state.\n\u003e\n\u003e Concrete attack: If you can find x != y with H(x) = H(y), then you can\n\u003e also find m, x != y, with H(m||x) = H(m||y), just by setting m = \"\". \n\u003e\n\u003e Not sure if this is the right place to discuss that issue though...\n\u003e\n\u003e Best,\n\u003e Tim\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"}