-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undisclosed members are brute forceable without a per message nonce #3
Comments
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. |
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 |
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. |
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. |
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. |
If you factor in your secret key in the process, then depending on key type, one could utilize |
I believe this issue is now addressed as of: #7 the specific encoding remains subject to change. |
Without a per message nonce, revealing a path gives the verifier the ability brute force other messages.
The text was updated successfully, but these errors were encountered: