Open MarkLee131 opened 6 months ago
it seems that Slither is raising a false alarm regarding the detection of a weak Pseudo-Random Number Generator (PRNG) in the code. Let's break down the key points:
Nature of False Alarm:
rpow
function of the Jug contract.n % 2
) in the switch
statement and in the subsequent loop.% 2
as a weak PRNG, but the provided code doesn't seem to have an inherent weakness.Frequency:
Code Example:
rpow
function from the Jug contract and a simple case for the add
function.switch mod(n, 2) case 0 { z := b } default { z := x }
in the rpow
function.Version and Relevant Log Output:
Reference:
Verification of False Positive:
% 2
), it's crucial to analyze whether it indeed poses a security risk in the context of the given code.In conclusion, to confirm the false positive, you should carefully review the code and assess whether the reported weak PRNG instances are genuinely problematic or if Slither's detection mechanism might be overly sensitive in this case. The provided information doesn't seem to indicate a clear weakness in the PRNG logic.
R u a bot, bro?@sriramsowmithri9807
Hi @0xalpharush, really appreciate what you guys have done with Slither for Solidity smart contracts. It's been super helpful in my work. I'm eager to contribute and make it even better, and would love your take on this issue I'm looking at. Any chance you could give some feedback? Thanks a ton! :)
Describe the false alarm that Slither raise and how you know it's inaccurate:
Slither reports
Weak PRNG
when it found there are some module usage%
, regardless of it depends theblock.timestamp
.Frequency
Very Frequently
Code example to reproduce the issue:
https://etherscan.io/address/0xc9fe6e1c76210be83dc1b5b20ec7fd010b0b1d15#code#F13
(jug.sol).In function rpow:
It got:
add
):It reported:
Version:
0.10.0
Relevant log output: