roblesjoel
commented
10 months ago After tinkering more with the code, wondering why it did not work i found out something more. The challenge check in CoreProofVerify was returning INVALID.
I looked at the objects and saw that init_res was different in the ProofVerify step than the ProofGen Step.
In the ProofGen we generate then number of messages + 1 number of generators.
In the ProofVerify we generate U (number of commitments) + number of disclosed indexes + 2.
The problem for me lies with:
1. proof_len_floor = 2 * octet_point_length + 3 * octet_scalar_length
The Proof had 5 Elements + msg scalars, but with the newest draft it was updated to 7 Elements + msg scalars. so the proof_len_floor value is incorrect, but that is also the value which is used to calculate U.
The correct version would be:
1. proof_len_floor = 3 * octet_point_length + 4 * octet_scalar_length
With that U would be correct and represent the number of msg scalars.
Now there is still an error.
R + U + 2 is not completely correct.
Remember in ProofGen we only generate total messages + 1 generators. R + U should represent the number of total messages (number of disclosed indexes + those messages which are not disclosed). So it should be R + U + 1
With that we generate the correct number of generators. So instead of changing L + 1 to L + 3, we need to change the proof_len_floor calc and the amount of generators to be generated.
In 3.5.4 Proof verification, U + R + 1 generators are created. R = number of disclosed index U = number of commitments + 2
Then in 3.7.3, a verification of the number of generators takes place:
11. if length(generators) != L + 1, return INVALIDwhere L = number of commitments + number of disclosed indexes.
This is incorrect. Assuming 0 commitments and 0 disclosed indexes: R = 0, U = 0 + 2, generators created (U + R + 1) = 3
L = 0 (as no commitments and no messages to be disclosed), generators checked (L + 1) = 1
My proposition:
Instead of checking L + 1, it should be L + 3.