Attacking Merkle Trees with a second preimage attack
The authors of Keccak &#x2F; SHA-3 came up with Sakura[0], a hash tree construction that&#x27;s provably as collision-resistant as the underlying hash function and very flexible.<p>If you&#x27;re designing a new system using hash trees, you better use Sakura trees or have a good explanation for why not.<p>Edit: I also wrote some demo code[1] for this attack when arguing with one of the IPFS guys about why they really shouldn&#x27;t use Bittorrent BEP 30-style Merkle Trees.  In order to get security with Bittorrent-style trees, the [length, root] pair really needs to be your cryptographic identifier, and you need to make sure they&#x27;re always properly handled as a pair.  There are just too many caveats to usage and we have provably secure alternatives.<p>As a former LimeWire developer, it makes me sad that Gnutella&#x27;s TigerTrees avoided this vulnerability long before bittorrent&#x27;s BEP 30 was published, and yet Bittorrent got it wrong.  It was a well-known vulnerability, and was covered as part of my interview at LimeWire.<p>[0]<a href="https:&#x2F;&#x2F;keccak.team&#x2F;files&#x2F;Sakura.pdf" rel="nofollow">https:&#x2F;&#x2F;keccak.team&#x2F;files&#x2F;Sakura.pdf</a>
[1]<a href="https:&#x2F;&#x2F;github.com&#x2F;kmag&#x2F;bad_examples&#x2F;tree&#x2F;master&#x2F;bad_merkle_tree" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kmag&#x2F;bad_examples&#x2F;tree&#x2F;master&#x2F;bad_merkle_...</a>