Restarting the Semaphore random value generation process

In early March 2020, I announced a series of computational steps that would create a random value which we would use to start phase 2 of the multi-party setup ceremony for the Semaphore zk-SNARK circuit (read this blog post to learn more about it). Unfortunately, we did not do a thorough enough job with committing to key parameters and details about the process we would perform, which could raise doubts about its trustworthiness and security. As such, we have decided to re-run the random value generation and apply the lessons learned over the past week to ensure that we follow a water-tight process.

Timeline of events

March 4 2020: I posted in the README file of the appliedzkp/semaphore-phase2-setup repository that we would use response 0022 from Perpetual Powers of Tau as the starting point” for the ceremony.

Why this is problematic

The problem with the above timeline of events is that the change made on March 10 reduced the security of the random number generation. If we were malicious and extremely computationally resourceful, such that we had secretly completed the VDF and SHA256 iterations earlier than announced, we could have made that change because we favoured the random value generated using challenge 0024 over the random value generated using 0023.

Lessons learned

When we announce that we will restart the random value generation process, we will include all of the following information in the README located here, and more:

  1. The challenge file upon which we will apply the random value
  2. The number of VDF iterations we will use
  3. The fact that we will not perform iterated SHA256 hashes on the VDF output
  4. The exact commit hashes of the phase2-bn254 binaries we will use to apply the random value to the challenge file
  5. The exact steps we will take
  6. A cryptographic signature of all the above information

One more change to the process

In addition, we will make one change to the process, but for a reason unrelated to the challenge file. We realised that applying 242 SHA256 hash iterations to the VDF output slows down the verification of the random value from seconds to hours. Furthermore, applying a hash chain defeats the purpose of using a VDF in the first place. As such, we decided to only apply the VDF and skip the hash chain.

Conclusion

The Applied ZKP team, responsible for the development and release of Semaphore, takes security very seriously. If application developers are to use Semaphore for real-world applications, some of which will involve on-chain economic activity, it is imperative that our multi-party setup ceremony be unquestionably secure. Although re-running the random value generation process will delay the start of phase 2 of the ceremony, we believe that this is in the best interest of all.