Creating commits for values

[Jasleen1]

At the moment the values being committed in the tree for prototyping are all dummies. We would like to replace the value_to_bytes function in directory.rs to return actual commitments instead. This involves 3 main steps:

• Changing the function value_to_bytes to return a byte array derived from a digest instead.
• To make the commitment hiding, generating and storing a nonce for each committed value.
• Including the nonce in the proofs sent to the client, and having the client verify these nonces.

[slawlor]

This might be a naive question, but couldn't we say re-use the VRF functionality for this? If the value_to_bytes were to VRF the ValueState data, with even a different key`, then hash the result as the leaf hash value.

It'll be easier to manage than unique nonces in the long run (just a second private key needs to be stored), and won't require additional data-layer I/O for each leaf node.

[kevinlewi]

After some offline discussion with Jasleen, we will use a keyed hash (modeled as a random oracle) as a commitment here.

This means we need the server to hold a commitment_key server. The server needs to generate a proof for each label+value, and send this proof as a component of the lookup and update proofs. The client can then verify the proofs by supplying the raw value and checking that the commitment matches.

Construction:

proof = H(commitment_key, label, version, value)
commmitment = H(value, proof)

[eozturk1]

QQ: How do the clients verify the proof without the commitment key? In other words, how they verify that the proof is generated over the correct label, version and value?

[Jasleen1]

Originally, the commitment was hash(nonce || public_key). Now we are just computing the nonce using the server's secret commitment key, instead of randomly computing it and storing it for each PK of each user. The only thing needed to verify that some string commits to PK is nonce, which the client doesn't need to know how it's computed, just its value.

[eozturk1]

That clarifies it, thank you @Jasleen1!