{"type":"rich","version":"1.0","author_name":"npub1cmt6gqyfw3sdngkq0wadtpe3kmgyyeld6ad0g2h5tar3kpzcrmpqddwkls","author_url":"https://nostr.ae/npub1cmt6gqyfw3sdngkq0wadtpe3kmgyyeld6ad0g2h5tar3kpzcrmpqddwkls","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-02-24\n📝 Original message:On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:\n\u003e Not sure that you really read deeply what I sent, because stating\n\u003e that\n\u003e hashing files continuously instead of hashing the intermediate steps\n\u003e just gives more latitude to the attacker can't be true when the\n\u003e attacker\n\u003e has absolutely no control over the past files\nWhat prevents the attacker to provide different past files when talking\nto parties who are still in the initial state?\n\nThen the question is: knowing the hash state, is it as easy to find a\n\u003e collision between two files that will be computed in the next round\n\u003e than\n\u003e finding a collision between two files only?\nWith the original usage of the hash function, the hash state is always\nthe initial state. Now that the attacker has some control over the hash\nstate even. In other words, if the original use of the hash function\nwas vulnerable, then your scheme is vulnerable for the initial state.\n\nConcrete attack: If you can find x != y with H(x) = H(y), then you can\nalso find m, x != y, with H(m||x) = H(m||y), just by setting m = \"\". \n\nNot sure if this is the right place to discuss that issue though...\n\nBest,\nTim"}