I'm wondering if it would be possible to implement this functionality with a trusted but transparent third party (maybe an Ethereum smart contract?):

  • Bob has an encryption key. Alice has the encrypted data and wants to buy the key from Bob.

  • Bob sends the key to the smart contract (SC).

  • Alice sends some ether (and perhaps the encrypted data or some function on it) to the SC.

  • The SC verifies that the key decrypts the data properly. If it doesn't, it halts.

  • The SC sends Bob the ether, and Alice the key.

The main issues I'm finding when I'm trying to think of a solution are:

  • How does the third party verify a decryption is correct?
  • Is it possible for the third party to verify this decryption without revealing it, since it is transparent? I know of zero knowledge proofs, but am not sure of how they could apply here.

Thank you!

bumped to the homepage by Community 2 days ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

I'm not sure what you mean by transparent. With a trusted third party what you ask is trivial. But with etherium I believe you can't, the key would become public there is nothing secret on the blockchain.

If we wanted our own distributed third party this can be done. You can perform secret sharing and send part of the key to each member of the distributed escrow. They can then perform shared computing to verify the secret without revealing the secret.

  • 1
    By transparent, I meant that all of their activities would be viewable by the public (as you pointed out is the case with Ethereum). Also, when decrypting a file with a key (or even partially) via secret sharing, how could we know that the decryption is correct? – ModWilliam Dec 17 '17 at 0:45
  • 1
    You verify correct encryption im the usual fashion with a MAC of some sorts. – Meir Maor Dec 17 '17 at 5:28

Is it possible for the third party to verify this decryption without revealing it, since it is transparent? I know of zero knowledge proofs, but am not sure of how they could apply here.

Maybe there's an exotic zero knowledge way of doing this, but in general you can get pretty far by having the smart contract incentivize the players to play nicely together by holding money in escrow and allowing the players to report misbehavior to the contract. You can take a lot of inspiration from various off-chain scaling proposals for Ethereum and Bitcoin. They usually focus on getting the transactions to be off-chain for scalability/speed purposes, but they can also be useful for facilitating private data exchange.

A partial solution could look something like this: Alice pays the smart contract, then Bobs signs a value containing the key and the id/hash of the ciphertext it's for, and privately gives it to Alice. The smart contract holds Alice's payment for a week. If Alice finds that the key is invalid, then Alice publicly publishes a counterclaim including the signed value to the smart contract, which attempts to use the key to decrypt the ciphertext, and if that fails, it refunds Alice. (If the ciphertext is too large to store on the blockchain, then the ciphertext should be broken into small signed chunks that are available to and verifiable by anyone or at least Alice before she pays, and Alice includes the chunk of the ciphertext that failed to decrypt in her counterclaim to the smart contract.) Otherwise, after the week is up and no valid counterclaims from Alice have been received, the smart contract allows Bob to claim the payment.

However, there are open problems with this:

  • This smart contract as described wouldn't force Bob to actually give Alice the key. If the smart contract has a way for Alice to claim that Bob never gave her the key, then she could do so after receiving the key. I'm not convinced this is necessarily impossible to solve: maybe there's a solution where Alice and Bob both have money held in escrow by the smart contract and exchange many messages between themselves where Bob's messages incrementally reveal the key, and Alice's messages confirm the receipt of the pieces, and Bob can publish a certain amount of Alice's confirmation receipts to the smart contract to prove that Alice is lying if she claims that he didn't play his part correctly. If Bob only skipped out on the last few messages, then Alice can brute-force the rest of the key.

  • The smart contract can't know that the data Alice decrypts is actually what she wanted. It could turn out to be a text file made by Bob of just the letter 'A' repeated.

  • Alice could publish the decryption key after she receives it.

How about hash checksum? Bob sends the key and the hash checksum to SC SC decrypts the data and hash the result, see if it matches with the checksum

  • You would want to use a MAC, not a hash. – forest Sep 11 at 3:10

Interesting

To implement a decentralized system, I wrote a TLS like P2P net stack. The main idea is removing CA Cert from the whole system by using a DHT for Naming and Key Exchange. I am not a crypto expert, so if there's any flaw please point it out for me here or Github

First, I use an Elliptic Curve for asymmetric encryption and AES-256-CBC for symmetric encryption.

DH-RPC NodeID is generated by hash of Node PublicKey and an Uint256 Nonce:

NodeID := sha256(blake2b-512(NodePublicKey + Uint256Nonce))

I refer to S/Kademlia's idea to define the number of consecutive 0s in front of the NodeID as difficulty and to impose a minimum limit on the difficulty of the NodeID allowed to be stored on the DHT. DHT is used to hold the NodeID:PublicKey NodeID:Addr map. NodeID and Nonce are sent to do ECDH getting shared secret after TCP connection established.

GenECDHSharedSecret(APub, BPriv) == GenECDHSharedSecret(BPub, APriv)

The main procedure is described as sequence chart: enter image description here

Because in the decentralized system NodeID is the URI, not "Bob/Alice.com". So anyone tries to fake NodeB by overwriting the address or public key on DHT without the private key of NodeB will be failed to get the correct shared secret.

Github: https://github.com/CovenantSQL/CovenantSQL/tree/develop/rpc

Known issues:

  1. Add a random uint64 along with NodeID and Nonce sent to remote to add some random for the shared key.

you may check my question and discussion here: Is my way safe to remove SSL CA Cert by DHT and PoW NodeID for a decentralized system?

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.