Random numbers can be predicted

[Raz0r]

The current implementation can be predicted:

• block.blockhash(block.number) will always be zero, since block hash is not known until block is mined;
• seed can be looked up in the contract storage on the blockchain prior to the call, e.g. using web3.eth.getStorageAt();
• now is shared within internal messages in the same transaction, so we can make an exploit contract that will call target contract.

Consider switching to commit-reveal approach or using an externally updated seed.

[flockonus]

Thank you @Raz0r for the feedback!

Those are great points. Number 1 and 2 we had figured and are working on these now.

The 3rd point is great, and it's an interesting way to exploit that i didn't think of before. If i get it right, you are suggesting that there could be another contract that basically simulates random and decide whether or not to call it based on the result it gets?
Please correct me if I'm wrong, but i'm not sure this is possible since the seed would only be readable off the chain?

Ultimately, I ask you to consider the project goals. We are developing it because we need a simple and efficient way to generate a random as possible number in solidity many times per block (which is known to be impossible to do so perfectly), therefore we are compromising things here.

Also please refer to v1-candidate for the current branch

[Raz0r]

Please correct me if I'm wrong, but i'm not sure this is possible since the seed would only be readable off the chain?

Yes, that's true. All you need to do is just continuously observe the blockchain state, and call your exploit contract at desired moment with the externally obtained seed as an argument. See this post for a real world attack: http://martin.swende.se/blog/Breaking_the_house.html

Ultimately, I ask you to consider the project goals.

I would argue the following points:

The more people using the same contract the more the internal seed value becomes unpredictable, generating stronger results.

As you already pointed out, seed can be read off-chain, so it is totally predictable.

If security is a main focus, it may be best to look into purchasing an oracle solution such as oraclize

I would not recommend oraclize since it is centralized. A better solution is randao: https://github.com/randao/randao

Security alert should be emphasized since the code can be wrongly used in smart contracts that implement various roulettes, card games, lotteries, etc. Any RNG on Ethereum without commit-reveal approach should be considered as unsafe.

[flockonus]

Thanks again for the well thought comments. We have some of that in #1 issue #2 as well, making very clear that it is unsafe is a improvement point

[flockonus]

@Raz0r made a major rework of the repo and included a link to your talk. Could you please make sure it conforms to the points in your issue and your talk?

[Raz0r]

The description in README looks okay, but I would love to see the actual code, master branch is missing it.

[flockonus]

From a security researcher "looks ok" is a great start :D

I'll open another issue, hope we can get to that soon enough.