Previously, we have used Zero-Knowledge Bounties (ZKB) to pay for a Sudoku solution on Bitcoin. In this series, we are going to use ZKB to solve a wide range of more practical problems.
In Part 1, we apply ZKB to pay for a decryption key. Suppose Alice encrypts her files with a symmetric key K. For safety, she contacts Bob, an online backup service, to keep of a copy of K. She does not want Bob to know K, so she splits K into N shares using a threshold secret-sharing scheme, so that any quorum of M shares can recover K. Bob generates a elliptic curve private/public key pair (sk, pk) and gives pk to Alice. Alice encrypts a share of K with pk with an asymmetric encryption algorithm. such as ElGamal or ECIES, and sends it to Bob. She does the same for other (M-1) backup servers.
In case Alice loses her local K, she asks Bob for the decryption key sk and Bob only delivers sk if he gets paid. This is the classic fair exchange problem that ZKB solves, as it guarantees that payment will result in disclosure of the right decryption key.
Implementation
Compared with pay for Sudoku, we only have to change the subcircuit C to verify the decryption key corresponds to the public key used to encrypt K, instead of verifying the Sudoku solution. Other parts of the circuit remain the same and can be reused.
Note that the private key used for decryption is passed as a private input to the circuit and thus is never revealed to the public. The public key gets passed as a public input so that the verifier smart contract can ensure that the correct private key was used when producing the proof.
This is different from Pay for Private Key, which exposes the private key on chain publicly.
Ransomware
It is not inconceivable the same approach to pay for a decryption key can be used by a malicious hacker.
The hacker infects a victim’s computer with a malware and encrypts his files, by, e.g., having the victim click on malicious content in a phishing email. The malware displays a ransom demand, to be paid in Bitcoin, with payment instructions on the victim’s computer.
The victim and the hacker do not trust each other. The victim wants to be guaranteed that he will be able to decrypt his files after paying the ransom.
The same ZK bounty can be used in this case, with one major difference. In the backup case, the user can be certain of the public key used for the encryption, since he performed the encryption himself. In the ransomware case, an additional proof is needed to convince the victim the public key used in the bounty smart contract is indeed the same one used to encrypt his files. A naive solution is to randomly select a few files for the hacker to decrypt.
How to alleviate this type of ransomware attacks is out of the scope of this article. Interested readers can find more information in, e.g., [1].
[1] The Ring of Gyges: Investigating the Future of Criminal Smart Contracts
