Cryptography
Many cryptographic primitives are used by protocols. These can often have implementation mistakes when a common library is not used or when key values are improperly set.
Other resources:
- None currently
1. Is the Merkle proof validation done properly?
Incorrect
No
Correct
Yes
Explanation
TODO and improve the focus of the question
Links
- OpenSea Merkle Audit Finding
- Binance bridge vulnerability
- OpenZeppelin merkle multiproof vulnerability in OZ >=4.7.0 <4.9.2
2. Is the Merkle root set to a non-zero value?
Incorrect
No
Correct
Yes
Explanation
The default value of an integer in solidity is zero. So if valid proofs are stored in a mapping that maps the proof to the root, then invalid proofs map to a value of zero, which is the same as the valid root if the root is set to zero. This allows invalid proofs to be accepted because there is inadequate differentiation between valid and invalid proofs.
Links
3. Is ECDSA recover malleable?
Incorrect
No
Correct
Yes
Explanation
TODO and improve the focus of the question
Links
- Deeper dive into ECDSA signature malleability
- Polygon $2 million bug bounty
- OpenZeppelin ECDSA recover vulnerability in OZ >= 4.1.0 < 4.7.3
- Signature malleability PoC
4. Is the result of solidity's ecrecover checked for a return value of 0?
Incorrect
No, the return value from ecrecover is not checked for a value of 0.
Correct
Yes, the code will revert if ecrecover returns a value of 0.
Explanation
The solidity docs explain that ecrecover will return zero on error. If there is an error, the code should revert instead of continuing with the assumption that the recovered value is zero.
Links
- Solidity docs describing ecrecover
- OpenZeppelin's ECDSA.sol
tryRecover()avoids this issue as the comments explain - Code4rena has many findings related to a missing zero check for ecrecover, including this one and this one.