Undisclosed members are brute forceable without a per message nonce

[OR13]

Without a per message nonce, revealing a path gives the verifier the ability brute force other messages.

[OR13]

I think this issue is solvable be encoding the nonces in the first proof, and then discloses the nonces along side the disclosed paths in subsequent derivations.... this will definitely increase the proof size.

[OR13]

probably this PoC code here would need to be modified: https://github.com/transmute-industries/merkle-disclosure-proof-2021/blob/main/src/merkle/merkle.ts#L74

[quartzjer]

I'm not sure this paper exactly discusses this issue, though it does show requiring the nonce on each leaf value.

There's also a mention here about the need for nonces.

[OR13]

It would be preferable to deterministically generate nonces for each message, I wonder if there is a named algorithm for this process, that is already a standard.

A naive solution might look like:

const rootNonce = crypto.getRandomBytes(32);
  const messagesWithNonces = messages.map((m, i)=>{
  return { message: m, nonce: hash(m + i + rootNonce) }
});

Then so long as the rootNonce is not revealed, per message nonces can be recomputed during the derivation process.

[quartzjer]

It was many years ago, but if I recall correctly the that was almost exactly the pattern we used (in an IoT context). I never found a formal algorithm for it.

[tmarkovski]

It would be preferable to deterministically generate nonces for each message, I wonder if there is a named algorithm for this process, that is already a standard.

If you factor in your secret key in the process, then depending on key type, one could utilize hash_to_field standardized algorithms.

[OR13]

I believe this issue is now addressed as of: #7

the specific encoding remains subject to change.