Giters

X-CASH-official / xcash-dpops

🗳 Delegated-Proof-of-Private-Stake: First DPoS implementation on a Monero-based coin

Home Page:https://xcash.foundation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

rradu92 opened this issue · comments

commented

🐛 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
commented

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 cd2d6b6

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!

commented

Hello,

Here’s my public address: XCA1um7C98XNv379wmqQ2gjNVr8LfvvgC7u4SaJmP7w8g3Xn17EJtMYRVsxSpxXypFTVn9XQfJDf1ckRsaHwtu4y7tTrJn8cLs

Thanks!

commented

I also changed the random_string function in commit 723e0be 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.

commented

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

commented

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

commented

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