The Merkle hash root does not indicate the tree depth, enabling a second-preimage attack in which an attacker creates a document other than the original that has the same Merkle hash root. For the example above, an attacker can create a new document containing two data blocks, where the first is hash 0-0 + hash 0–1, and the second is hash 1-0 + hash 1-1.[13][14]

One simple fix is defined in Certificate Transparency: when computing leaf node hashes, a 0x00 byte is prepended to the hash data, while 0x01 is prepended when computing internal node hashes.[12] Limiting the hash tree size is a prerequisite of some formal security proofs, and helps in making some proofs tighter. Some implementations limit the tree depth using hash tree depth prefixes before hashes, so any extracted hash chain is defined to be valid only if the prefix decreases at each step and is still positive when the leaf is reached.

• https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack
• https://news.ycombinator.com/item?id=16572793

This raises the question of what effect starting with "salted member leaf nodes" has.

Hi,

I was following your post W3C's github discussion and read with interest the technical methods for Merkle Disclosure Proof.

In a related merkle disclosure project we had used Open attestation's with Merkle Disclosure proof based on user credentials.
More write up of the method here: https://github.com/Open-Attestation/adr/blob/master/signature-proof-spec/spec.md

Wonder if it will be of value to the W3C community to also integrate the methods in the work item?

Thanks

RFC9162 defines merkle trees with some assumptions which might not map well to selective disclosure.

This spec defines merkle trees based on basicaly the "bitcoin / bittorrent" construction + some deterministic salting algorithm.

The binary aspecs of merkle trees and paths are a blocker for all higher order constructs that rely on them.

We need to gain more confidence that a new structure needs to be defined (current path) or find an existing structure we can endorse (what we wish RFC9162 was).

Tracking w3id.org reservation here:

perma-id/w3id.org#2462

does salting members before construction prevent forgery attacks on unbalanced binary merkle trees?

Would be nice to cite a source regarding this.

rfc9162 seems unconcerned, but their tree compute algorithm is different than BTC and our proposal here.

https://datatracker.ietf.org/doc/html/rfc9162#section-2.1.1