Hash collision

[indeqs]

Related Issue

• Addresses issue#57

Checklist

• [✅] I have read and followed the style guide

Describe the changes you've made:

Addition of a vulnerability shading light on the dangers of using abi.encodePacked() with multiple variable-length arguments that could potentially led to a hash collision. This specific vulnerability can lead to security issues in smart contracts, particularly in signature verification scenarios, allowing attackers to bypass authorization mechanisms.

The added information includes:

• Description of the Vulnerability: Detailed explanation of how abi.encodePacked() can lead to hash collisions and the potential impact on smart contract security.
• Examples and Code Analysis: Concrete examples and analysis of vulnerable code, demonstrating how an attacker might exploit this vulnerability.
• Remediation Strategies: Clear guidance on how to fix the vulnerability, including using abi.encode() instead of abi.encodePacked() and using fixed-length arrays.
• References: Links to official Solidity documentation and relevant security resources.

Type of change

• [ ] Bug fix (fixing an issue with existing vulnerability data)
• [✅] New feature (adding a new vulnerability or category)
• [ ] Documentation update (improving existing information)

[indeqs]

Good one! If we wanna make the vuln focused on hash collisions I think would be good to include other possible ways for them to occur. Otherwise it could be good to just make the vuln focus on hash collisions due to variable length arguments with encodePacked

Regarding this @kadenzipfel, it would be better to just focus on a single instance of hash collisions and publish a new one when another instance of hash collision is found. Like what is done with DoS vulnerabilities. All situations that can lead to DoS are not in one file but rather separate. Cause I am thinking if we do what you suggest with hash collisions, then we have to do the same for DoS for consistency :)

[indeqs]

How is it looking now?