# Verifiable & Coordinated Vulnerability Disclosure into the Future

> **TL;DR:** generate proof of smart contract vulnerability and time-lock encrypt the exploit calldata to be released after a time sufficient to patch the issue. In the meantime, a smart contract owner can get that calldata earlier if they transfer ETH to a white hacker’s address.

This idea builds on top of [verifiable time-lock encryption](https://drand.love/docs/timelock-encryption) and [verifiable vulnerability disclosure](https://blog.trailofbits.com/2020/05/21/reinventing-vulnerability-disclosure-using-zero-knowledge-proofs/).

The notion of time-lock encryption (TLE) can be expressed simply: ciphertexts are guaranteed to be decryptable after a specified point in time. One can make it verifiable by running encryption procedure inside an arithmetic circuit.

[zkPoEX](https://github.com/zkoranges/zkPoEX) (zk proof of exploit) is a second key ingredient that lets white-hat hackers to prove that they found a vulnerability without revealing the actual exploit information right away. Its aim is to facilitate communication and trustless collaboration between vulnerability researchers and DeFi application developers.

The coordinated vulnerability disclosure (CVD, aka responsible disclosure) is a model in which a vulnerability is disclosed to the public only after the responsible parties have been allowed sufficient time to patch or remedy the vulnerability.

The aim of this project is to create an end-to-end verifiable cryptographic infrastructure that facilitates coordinated vulnerability disclosure and contingent transactions for trading exploit information for monetary reward.

## Problem

Bug bounty programs in the DeFi space can be hard to run and maintain, not always honored, and may not always offer sufficient compensation for white hats. This can lead to a lack of incentive for hackers to report vulnerabilities, which can ultimately result in a less secure DeFi ecosystem. Previous work had laid down basic tools for proving vulnerabilities via ZK proofs.

Without the conditional payment infrastructure, however, parties must trust an inherently trusted intermediary to exchange vulnerability information for reward which limits their usefulness.

From Vendors perspective it is often cheaper and easier to pay white hat to remain quite and drag patching the vulnerability as long as possible. All the while, black hats may find and exploit the vulnerability leveraging Vendor's slow response act. Public vulnerability disclosure acts as the only effective way of keeping Vendor's accountable and efficient in patching vulnerabilities.

## Solution

We solve the first issue by introducing contingent payment protocol. This allows to remove trusted intermediary by binding the release of bounty payment to the release of vulnerability details (at this point only a smart contract owner would be able to view vulnerability details).

### Contingent Bounty Protocol

1. White hat or Vendor deploys a bounty escrow contract $CE$ initializing it with the minimal bounty in ETH.
2. White hat sends Proof of Exploit ($PoEX$) to Vendor which:
- asserts that given the faulty contract $CF$ bytecode, some state of $CF$ and exploit calldata contract $CF$ runs with $\Delta$state demonstrating vulnerability.
- outputs the encryption of the vulnerability info with a randomly generated key $Enc(\text{state} | \text{calldata}, key)$
- outputs the hash of the randomly generated key $H(key)$
3. White hat publishes $H(key)$ to the bounty escrow contract.
4. If $PoEX$ is valid, the buyer will lock ETH in the contract $CE$;
5. White hat will generate an Encryption Proof (proof of encryption $PoE$) which:
- asserts that they have the preimage to the key hash stored on the contract $H(\text{preimage}) = H(key)$
- outputs the encryption of the pre-image with the buyer's public key $Enc(\text{preimage}, pk)$ if the proof is valid, the ETH is redeemed from the contract.
6. the buyer retrieves the encrypted key $Enc(key, pk)$ from the contract computes:
- $Dec(Enc(sk, pk), sk) => key$
- $Dec(Enc(\text{state} | \text{calldata}, key), key) => data$

### Coordinated Vulnerability Disclosure into the Future

White hat coordinate with Vendor on how much time $T$ it take them to patch vulnerability.

1. White hat generates TimeLock Encryption Proof ($PoTLE$) which:
- asserts well formedness of the identity based encryption $IBE(\text{state} | \text{calldata}, T)$ of the vulnerability info for the coordinated time $T$ as identity
- outputs the encryption of the time-locked vulnerability info under the previously chosen $key$ (this prevents vulnerability info to be eventually unlocked if the Vendor didn't payed thus not received info to perform the patch) $Enc(IBE(\text{state} | \text{calldata}, T), key)$
2. White hat publishes the ciphertext on IPFS and registers the IPFS URI on a smart contract
3. The $PoTLE$ proof is shared with Vendor along with $PoEX$ proof.