[bug] --generate-key generates the same key in different servers

[rradu92]

🐛 BUG REPORT

bug: when you execute xcash-dpops --generate-keys to generate the key pairs for the node, you have a probability to get the same key pairs in different servers if you execute it at the same time.

Expected Behavior Generate a different key pair for each node

Current Behavior Sometimes you get the same keypair if you execute the command at the same in two or more different nodes

Steps to Reproduce (for bugs)

1. execute ./xcash-dpops --generate-key in more than one server at the same time with cssh for example
2. check the generated key pair

Your Environment

• Version used: xcash-dpops v1.0.0
• Operating System and version: Ubuntu 18.04 LTS

[zachhildreth]

Hi @rradu92 Thanks for checking this out

I found that I was using the rand systemcall to choose random delegates and other things in the code, but I was also using it to seed the bytes for the key generation algorithm.

After researching more rand is not a cryptographically secure pseudo random number generator (CSPRNG) but only a pseudo random number generator (PRNG)

The difference being that PRNG creates statistically "weaker" random data then a CSPRNG

Since VRF public and secret keys are meant to be generated once, and used for all signing a messages for a delegate, as long as the delegate is mining blocks in DPOPS, it would be not ideal to have a weaker key set for brute force attempts, espically for an important part of the DPOPS system.

I have changed rand to getrandom for generating VRF public and secret keys, as this is a CSPRNG, and is a systemcall that reads the data from /dev/urandom

I also did not include any flags, so the call will block if the OS was recently restarted, until enough seed bytes (32) have been created for the initialization of the VRF public and secret key creation.

The code has been fixed in commit cd2d6b69c28898623b59dadfb491864abcd51a8f

Thanks for finding this bug, and since this a larger security bug the team has decided to award 300 USD in xcash for finding this bug!

Please post a public address, so we can send the bug bounty.

Thanks!

[rradu92]

Hello,

Here’s my public address: XCA1um7C98XNv379wmqQ2gjNVr8LfvvgC7u4SaJmP7w8g3Xn17EJtMYRVsxSpxXypFTVn9XQfJDf1ckRsaHwtu4y7tTrJn8cLs

Thanks!

[zachhildreth]

I also changed the random_string function in commit 723e0be905ca1925e63ff139c3e0984084a5337a to the upgraded CSPRNG, as this function is used to create the random alpha string for the VRF data, and used to create the salt for each outgoing message from the delegates.

I am going to leave all other instances of rand in the code, since its quicker CPU wise, and its just selecting what delegate to sync from, or selecting what reserve proof to validate, and does not need a security level type of randomness.

[rradu92]

I think the issue can be closed since it was fixed with the last updates you made @zachhildreth

[zachhildreth]

Hi @rradu92 were waiting on @plbgnt to do the bounty, post the public tx and close the issue

[plbgnt]

Bounty Paid ✅

---

Date: 26/08/2020 Amount (USD): $300 Amount (XCASH): 9800718.72 XCASH Spot Price: 0.00003061 USD/XCASH XCASH Address: XCA1um7C98XNv379wmqQ2gjNVr8LfvvgC7u4SaJmP7w8g3Xn17EJtMYRVsxSpxXypFTVn9XQfJDf1ckRsaHwtu4y7tTrJn8cLs Tx Hash: 8bbcde947f1b7fc8dc6c6277b0ebf3c1905255f7e24e3c0d040f4c4463d06ec6 Link: https://explorer.x-cash.org/Transaction?data=8bbcde947f1b7fc8dc6c6277b0ebf3c1905255f7e24e3c0d040f4c4463d06ec6