Second preimage attack

[MBakhshi96]

As mentioned here Merkle trees are susceptible to the second preimage attack when a node can be presented as a leaf. To prevent this attack, OpenZeppelin typically uses double hashing for leaf values. However, in MerkleDistributor.sol, the leaf is constructed by hashing the value only once. Does this mean that the current implementation is not safe about these attacks? Is it assumed that they can't happen or are there other safeguards in the current contract?

[mocarram]

The 96-byte structure in this contract introduces a large search space, making it highly resistant to collisions and second pre-image attacks.

Solidity Claim function:

function claim( uint256 index, address account, uint256 amount, bytes32[] calldata merkleProof )

All elementary types (such as address, uint256, bool, etc.) are encoded as 32-byte values when passed as function arguments or used in hashing operations.

• index as uint256: 32 bytes
• account as address, padded to 32 bytes in Solidity
• amount as uint256: 32 bytes

The total input size is 96 bytes: 32+32+32 = 96

In the tree generation Script:

utils.solidityKeccak256(['uint256', 'address', 'uint256'], [index, account, amount])

• index as uint256: 32 bytes
• account as address, (padded to 32 bytes like it’ll be in Solidity by EthersJS)
• amount as uint256: 32 bytes

The total input size is 96 bytes: 32+32+32 = 96

Acknowledgment: Special thanks to @akterbabber for their guidance in understanding how this contract mitigates potential security vulnerabilities.

[DebianUser007]

While the 96 byte structure indeed provides a large search space, true second preimage resistance is determined by the security of keccak256 in this case. If you use keccak256, the risk of a second preimage attack is negligible in practice. Keccak256 is designed to be preimage resistant. That means a hash h which is computed over 96 bytes, it is infeasible to find any different input x that keccak256(x) equals h. Therefore, even though only a single hash is applied in the contract, the implementation using a single hash of the 96-byte value is safe in this contract.