Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR:
Explaination:
As part of the audit, a bug was caught where by generating the CiphertextCommitment proof in a certain way
the attacker can get the ValidateCiphertextCommitment to return true even though the Ciphertext and Commitment encrypt different values.
Specifically, the commitment must encrypt x * (c + k) * c_inv, where
k is any random scalar
x is the original value encrypted by the ciphertext
c is the challenge scalar of the proof, which can be independently generated using the params in the proof
The implication is that the attacker would be able to create a transfer/withdrawal for more than they have.
Eg:
Account state: AvailableBalance: 100
Withdraw {
WithdrawAmount: 150 (Exceeds AvailableBalance)
NewAvailableBalanceCommitment: (-50 * (c + k) * c_inv) - This is a specific value calculated by the attacker.
RangeProof that NewAvailableBalanceCommitment is > 0 - This will pass assuming the fake NewAvailableBalanceCommitment above is +ve
EqualityProof that NewAvailableBalance == Account.AvailableBalance - WithdrawAmount - This is the fake equality proof
}
This withdraw instruction will pass, since the range proof is valid and the equality proof is valid.
This can be mitigated by adding zero checks to the proof.
While this was only flagged for the proof above, this PR adds zero checks to all the parameters in the proof.
Zero values in the proof could suggest a lack of randomness when generating scalars and lead to degraded proofs, since the values may no longer be blinded, or the proof could be exploited in some edge case.
In all of the cases for our proofs, zero values arise when a random scalar we generate is 0 or specifically cancels out another value. Since we generate random scalars on a field of 2^255 points, the probability of generating such a scalar is 1/(2^255) and effectively negligible
Since we still want to eliminate random chance failures due to generating 0, also adds a method to make it impossible to generate the 0 value randomly when we generate random scalars, failing on the proof generation side if it happens instead of at validation time.