Description:

The revealMove() function relies on a commit-reveal scheme where a player reveals their move by submitting the original move and a salt. The commitment is verified by checking the hash keccak256(abi.encodePacked(move, _salt)) against the stored commitment.
However, since _salt is entirely user-defined and not enforced to follow a secure or random pattern, an attacker could potentially brute-force or guess weak salts used by opponents, especially if the move is known or suspected (only 3 possible values: Rock, Paper, Scissors). This becomes critical in non-private mempool settings, where a malicious player could front-run a reveal transaction and submit a winning move right before it is confirmed.

Impact:

• Enables front-running if the opponent uses a weak or reused salt.

• Allows an attacker to predict or reveal the opponent's move in advance.

• Undermines the fairness of the commit-reveal mechanism.

Recommended Mitigation:

• Enforce a minimum entropy requirement on the salt (e.g., at least 128-bit random string).

• Use a provably random salt , e.g., via off-chain generation using Chainlink VRF or on-chain randomness with proper commitment logic.

• Provide a frontend-side helper to generate cryptographically secure salts.